If you don't care about field access just always write fields with uppercase. Any APIs you're using only expose uppercased variables as well, so it'll stay consistent.

The public/private stuff is mostly useful for publishing modules with sound APIs.

you don't Go is explicit about things.

maybe caps for export is ugly, it's not much different from how python hides with _

I find both the golang uppercase lowercase naming scheme and python underscores for private (and __ for *extra* private) to be terrible design choices.

They are hidden functionality, a set of rules which must be remembered. “Make sure to do <weird trick> because that mean <X> in <PL>”

Leave identifier names alone. Packing extra info inside is unnecessary mental burden

Also, I recently learned that only leading __ are considered special, whereas both sets of __ go back to being a public method due to the dunder magic methods such as __add__, __eq__, etc

Oh yeah, I didn’t even notice. Much worse than I thought!

Imagine explaining these rules to a beginner learning programming.

It should be mentioned that within the python community using __ for extra private is widely seen as a misfeature that shouldn't've been added and shouldn't be used.

> and __ for extra private

That was never its purpose and using it that way is in fact misuse.

Name mangling was added to avoid unintentional conflicts in inheritance scenarios. That’s why it’s static, simple, and well documented.

the other option seems worse, i dunno if i can use this identifier unless i have an IDE or i look up the definition every time

"_" does not hide anything in Python. It's just a convention that says "use at your own risk".