Go 1.22 released

Of course. You're right, we should just replace it all with WASM or something right? </eyeroll>

Because it's ugly and unidiomatic, or it renders existing code unidiomatic. It means there are two ways of doing things where before they was just one. Either that creates inconsistency, or people pick one or the other as the "preferred" or "best practice" way of doing things - and then it means you separate the world into "old legacy" code and "new" code. This has lots of unfortunate flow-on effects. For example, it would encourage people to rewrite existing code to be more "modern" (for no good reason - the old code works fine). But it's also just distasteful. The nice thing about 'Go' is that code ages pretty gracefully compared to languages that constantly churn new syntactic sugar/library sugar into the language. C++ is notorious for this: you can pretty much tell what year some C++ code was written as soon as you look at it, once you know what to look for. 'Oh yeah, make_shared but it's still using make_unique, that's likely to be 2014ish'.

I think the worst part of it, though, is that it creates special-case syntax for what is should just be general programming. Go supports multiple return values and sometimes those return values include errors. Sometimes they don't. The nice thing about programming languages is that they are general. You use the same simple mechanisms for everything. Go is particularly good about this, almost as good as C. In C, almost _everything_ you do is arithmetic, dereferencing, taking the address of something, for/while/if/switch or calling a function. In Go you can add '<-' and 'go'.

Why add new syntax to do something that is so simply achieved with a simple 'if' statement? It reminds me of people suggesting that we all need to use 'map', 'filter' and 'reduce' functions and complicated iterator schemes. Do we? What's wrong with a 'for' loop with a nested 'if' structure controlling a line of code that modifies a variable? More than sufficient, I think. Just to save a few characters? Making code more dense isn't necessarily a good thing. Error handling in Go gives your code a nice bit of breathing room, I think. Code in more dense languages just needs more blank lines to space it out, IMO.

Basically, I think syntactic sugar is generally bad.

Fair! You might even say that the pattern encourages developers to raise errors as panics when implement chaining; an anti-pattern.

(It's also possible to embed errors instead and have explicit handling in chains, so they don't exactly *prevent* chaining, but I agree that it is reasonable to argue that this is not the ergonomic best implementation of chaining.)

So my complaint isn't related to your concerns, and I appreciate the clarification!

> the modern consensus is that exceptions are a bad idea

No it isn't. There's a small, vocal community that says so, but that doesn't make it right, and there are plenty of new exceptional systems being made.

> I'm talking about `if (err != nil) {return nil, err;}` statements that can easily take up half of all the code in functions that call a lot of other functions. They are unergonomic, and they prevent chaining.

This is bad anyways. Making sugar for bad idioms will only rot your teeth (same as blind `?` error bubbling in Rust). What is missing is the context that made the error happen. I find "file not found" from a high-level API useless. "Git repository expected; no .git found" is actually useful. Better as an enum so that code can inspect and adapt instead of low-level code assuming that a pre-baked string for user consumption is the only suitable representation.