[sdegutis]

The "Capitalization feature" is actually objectively worse because of the reason OP mentioned, of having to rename all semi-local usages when visibility changes. But good IDEs can help mitigate the difficulty of this.

But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, Class, CONSTANT convention.

It reminds me of people who want everyone to use CE and BCE instead of AD and BC, ignoring the inertia and relevance of the latter and almost seeming like we live in a vacuum where fresh ideas have as equal weight as old ones, and history doesn't matter at all.

I don't know how to explain this better, but this is basically the core reason I don't like Go, above and beyond any specific features or lack of features.

I once heard Go described as "what if we took the good ideas of C and started from scratch?" But it feels like they take that very literally, as if they were saying, "what if it was actually 1970 right now, and we didn't have C, and the next 49 years never happened?"

(This is a separate reply than my other one because someone already upvoted that.)

[jayd16]

WRT renaming, I find that refactoring code is often such an oversight from language designers. I consider C# to be an elegant language in this way. Public fields and properties look the same in C# so you can effortlessly refactor between them, for example. I wish more languages thought about this stuff.

[pjmlp]

A design introduced by Eiffel, copied by Delphi, before Anders went to Microsoft designed J++ and then C#, with the said feature.

[sdegutis]

I liked a similar aspect of Ruby: attributes and 0-args methods had the same syntax, so you could easily refactor a static field into a method that returns a dynamically calculated value. Overall I don't like that feature, but that was a very handy aspect of it.

[ben-schaaf]

Ruby actually went one step beyond: there are no attributes. `attr_reader` just generates a 0-arg method, while `attr_writer` just generates a 1 argument `name=` method.

[masklinn]

TBF that's pretty directly inherited from the Smalltalk ancestry: just like Smalltalk, Ruby simply doesn't have public (data) fields. Although it does provide shortcuts for automatically generating accessors which I don't think Smalltalk did / does.

Funnily enough, Self opted for the opposite tack of not having private data fields (although it does have readonly and read/write slots), but you can trivially swap "data" slots and "method" slots: http://handbook.selflanguage.org/2017.1/langref.html#constru...

[scroot]

> Although it does provide shortcuts for automatically generating accessors which I don't think Smalltalk did / does.

Most Smalltalk browsers do actually offer this capability

[masklinn]

The tooling does provide that yes, as it does in e.g. Java. But Ruby does it without tooling, the feature is a runtime message to the class object.

[throwaway34241]

For both C# and Go I use editors that understand the language and can rename all references to a variable with one keyboard shortcut. C# has at least 3-4 of these editors available, and Go has at least 2.

I realize that not everyone's preferred editor may support every language yet, but still I think the solution to this problem is probably just having the language designers provide libraries that editors can use for these refactoring features, instead of through specific capitalization conventions.

[kbp]

It doesn't matter when you're making the edit, it matters when you're looking at the diff and skimming through a hundred identical changes for the things that are actually different.

[amp108]

> But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, Class, CONSTANT convention.

What "pre-existing conventions" do you see in the Go code that you've had to refactor? The fact that conventions from Java or C++ aren't the same simply reinforces the fact that Go is a different language, and that's A Good Thing.