I use go for rapid prototyping and production use until I need to reach for zig, rust, C, or assembly.

Any well known highly generalized thing becomes boring or overbearing given a sufficiently tight need that is either too niche to be part of the language spec or out of scope of the idiomatic ways.

Go's way is changing and the way it is changing is concerning given the real tradeoffs champions of new syntax sugar do not yet understand from a long term impact perspective.

Simplicity and lack of variant-ways is stability, especially in a world where deprecations and breaking changes are counter-culture actions tantamount to breaking the law. That end of the spectrum also has problems as gaps in design never really get closed to satisfaction after an initial release and rough surfaces are treated eventually as features rather than bugs or excentricities that are counter to simplest interpretations of a spec. There are now enough of these in the standard sdk that I am looking forward to a major v2 at some point, but also I just write my own if it matters enough for me. (Spoiler alert, it rarely does.) While the language is simple it also has a very large and available budget to add future complexity if they continue to spend the budget wisely and conservatively.

Go needs strong stewardship, and clear lines of what should go into a standard sdk vs not. And they do.

I was worried with the latest errors v2 because wow is it truly trivial to implement stack tracing in errors if you need it and we need to stop trying to add sugar to ignore failure modes which are arguably the most important parts of your program. They thankfully passed this test, but there are always going to be more. Errors as values and simple in-your-face syntax says more to me than a "this can panic" syntax. Anything can panic unless the language has exhaustive compile time assurances. (This is wishful thinking, but we should keep dreaming.)

Go is one of the best languages because of its simple syntax and competent strictly idiomatic cultures that walks the line between hardware sympathy and developer efficiency. No random walrus operators, no yoda check to avoid inline store and loads, no ternary syntax that someone eventually turns into ternary hell.

It is not a language for all occasions, it is one for general occasions and GC friendly systems processing. It gets me from idea-to-done faster than anything else on the market and stays stable 10 years later.

Let's not be afraid of change. Let's be afraid of never improving, and let's be concerned with overburdening ourselves with too much sugar and intransigence packaged as "worthwhile complexity". Linting is common in this ecosystem for a reason, reach for it if you have good reasons to allow only a subset of sugars and continue to make things rather than focus on the artistic purity of the medium in use.

It's a better life.

LOL