3 ms·

Interesting how the Go team is the utmost example of thinking through and bikeshedding ad infinitum even the tiniest angles of each proposal (something that I l

by j1elo 10mo ago

Interesting how the Go team is the utmost example of thinking through and bikeshedding ad infinitum even the tiniest angles of each proposal (something that I like a lot by the way), which is part of the reason that popular feature requests take years to come, and others such as the `Set` type are binned because of not providing enough added value. But an implementation change that will for sure baloon the memory usage of everybody's code making heavy use of Hashmap-as-set (a popular idiom)? Yeah no problem, change shipped.

9rx 10mo ago
It's called marketing. If Go quietly made something perfect, nobody would know of its existence. Do stupid things that gets people talking and everyone soon learns about you.
voidfunc 10mo ago
The Go team has a lot of old school nerd cred thats why it gets away with a lot of stupid shit. Then a fan base of nerd hero worshippers beat down any discussion about doing things a better way with: SIMPLICITY. Its frustrating and I say this as someone who has been writing Go for around a decade.
- yomismoaqui 10mo ago
  Go is the worst programming language except for all those others that I have tried from time to time
avianlyric 10mo ago
There’s a big difference between a change which modifies the languages API, and one that just modifies the implementation of the API. Given GoLangs compatibility guarantee, any mistake in the design of a language API has to be preserved forever, and is very difficult to improve. But implementations of the GoLang spec and language APIs are much easier to evolve. There’s nothing preventing the Go team rolling out future improvements to deal with this issue, without having to worry about long term consequences. There’s also nothing preventing other implementations of the GoLang spec choosing a different approach.
- Someone 10mo ago
  I think all language definitions have lots of implicit non-functional requirements. When the main implementation of a language changes one of them, that technically isn’t a breaking change, but it still is one, as existing programs mays have to be changed in order to keep satisfying their own non-functional requirements.

by j1elo 10mo ago

9rx 10mo ago

It's called marketing. If Go quietly made something perfect, nobody would know of its existence. Do stupid things that gets people talking and everyone soon learns about you.

voidfunc 10mo ago

The Go team has a lot of old school nerd cred thats why it gets away with a lot of stupid shit. Then a fan base of nerd hero worshippers beat down any discussion about doing things a better way with: SIMPLICITY. Its frustrating and I say this as someone who has been writing Go for around a decade.

yomismoaqui 10mo ago
Go is the worst programming language except for all those others that I have tried from time to time

avianlyric 10mo ago

There’s a big difference between a change which modifies the languages API, and one that just modifies the implementation of the API. Given GoLangs compatibility guarantee, any mistake in the design of a language API has to be preserved forever, and is very difficult to improve. But implementations of the GoLang spec and language APIs are much easier to evolve. There’s nothing preventing the Go team rolling out future improvements to deal with this issue, without having to worry about long term consequences. There’s also nothing preventing other implementations of the GoLang spec choosing a different approach.

Someone 10mo ago
I think all language definitions have lots of implicit non-functional requirements. When the main implementation of a language changes one of them, that technically isn’t a breaking change, but it still is one, as existing programs mays have to be changed in order to keep satisfying their own non-functional requirements.