Disallow bespoke abstractions and use the industry standard ones instead. People who make abstractions inflate how productive they’re making everyone else. Your user base is much smaller than popular libs, so your docs and abstractions are not as battle tested and easy to use as much as you think.
The trade offs are though that patterns and behind the scenes source code generation is another layer that the devs who have to follow need to deal with when debugging and understanding why something isn’t working. They either spend more time understanding the bespoke things or are bottle necked relying on a team or person to help them get through those moments. It’s a trade off and one that has bit me and others before
I think that’s a bit of a stretch to say go will implement all the features of c# and Java because of a few new features. Go isn’t a frozen language, they just take a lot of time and discussion before committing to a major change.
I have a feeling that in the future developers are still going to be needed, but in an architecture and debugging/optimization fashion. Not in a writing boilerplate code aspect. There is also an issue with validating the output before it gets released to production.
I think this one difficult subject does not take away from the common feeling that overall Go is simple. This is like looking at a small scratch on the car and claiming the entire car is damaged.
I think that's very extreme. Products grow at a gradual pace. I don't think there are defining moments when a product no longer supports something, or is no longer used in a way that it was intended to.
I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.
To me this reads as a positive to the default handlers, as it shows how easy it was to make it work into a format that works for the programmer's preference. I appreciated the solution to the complaint
I don't think it's always as simple as that. Some wrongs are more important than others. The little wrongs, wouldn't be worth that mark on your career as being seen as unreliable, other wrongs would be worth it.
I would love to self host, but the time and effort I would have to put into doing, maintaining, and convincing my spouse (which is a whole effort by itself) is so significant it will take away from my other goals in life.
It's a stable and well proven technology that still has a lot of developer activity. Businesses are trying to make money, not explore technology, so a lot of them don't want to bother risking deliverables on something they may not have experience with.
Valid points about FFI. That makes me think if Go devs cared enough about Desktop GUI, then they would try to make that weak point stronger. Their focus is elsewhere (networking, cli tools, web) which doesn't rely on FFI as much.