The try/throw/catch model is painful and Go opted for errors as values. It makes code more verbose but also much more predictable. Pick your pain.
Sorry but this is unacceptable. You post a generic comment hating on a popular language and then when asked for the specifics you bail out because you can't answer in detail for whatever reason. On top of that you then insult the language authors.
That's classic troll behavior, another commenter here asked you to stop, I'm going to do the same and flag your comments in this thread because they're strictly speaking completely off topic.
Calm down, this is just a forum.
I've said it another comment but I'll directly include it here: "I have picked 20 years specifically since it was around 2003-2005 when Java and C# got generics. Obviously, they were also more than 20 years late but I compared it to mainstream languages people are more likely to know about or more likely to compare it with." Generics are a feature Go has lacked for a very long time, and I think it's a bit misleading to claim that including them is some revolutionary thing which the article suggests. ("There are many reasons to be excited about generics in Go" or "The future of Go generics is bright")
Also, I don't see how it is insulting the language authors if I point out (what I think is) a bad design decision they made. They are not horrible human beings or anything for so, I am not attacking them.
I'd like to disagree with the trolling and off-topic assessments. I would understand if it was a tangential comment about some other problems of Go (like nilchecking for example), but I replied directly to the point the article was addressing. I see the argument that it could potentially invite hostile behaviour, but I'd like to believe in the civility of the forum.
Finally, to expand a bit on the "what features Go needs" question of GP, for example it doesn't support most unicode characters deliberately (only letters and digits), proper exceptions, unions, sum types, enums, and the language doesn't care about correctness at all, only about the "common use case" (see the nanotime/time.Time issue for example, they implemented it the worst possible way)
No problem, we can wait. When will you be able?
---
It does endlessly fascinate me how 20 years after the definitive wisdom against exceptions appeared [1], programmers still keep insisting that seeing all code paths laid out bare on the page is somehow worse than keeping them implicit and hidden.
[1] https://www.joelonsoftware.com/2003/10/13/13/
"I think the reason programmers in C/C++/Java style languages have been attracted to exceptions is simply because the syntax does not have a concise way to call a function that returns multiple values, so it’s hard to write a function that either produces a return value or returns an error."
Effortlessly predicting the direction of future languages like Go/Rust/Zig decades ahead of their time. Excellent taste.
One really good example though is error handling - they've pretty much looked at C and decided that that was the best we can do, so now every Go program is full of nilchecking boilerplate.
The whole design of the language generally feels like as if it was made for unthinking drones.