[Pannoniae]

I would love to answer in detail but right now I cannot.

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.

[jacquesm]

> I would love to answer in detail but right now I cannot.

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.

[Pannoniae]

Hi. Sorry, I couldn't reply yesterday properly due to personal reasons, I am very sorry about that. It's not a generic comment, it directly reacted to the article. The article was about providing a speedup not because they innovated something new, but because they've finally fixed a wart which should never have been in the language in the first place.

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)

[Mawr]

Seems to me they've rightly figured that exceptions were a mistake and C had the right overall idea about error handling all along. Go essentially took C's error handling, such at is is, and improved it one step further, taking it from ~20% complete to ~80%. In contrast, e.g. Rust is probably at ~95%.

---

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.

[ARandomerDude]

> now every Go program is full of nilchecking boilerplate

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.

[bushbaba]

Makes developers need to at least think about error handling compared to say python. However I find Java’s error handling to be superior, but Java coding generally requires an IDE.

[duckmysick]

> I would love to answer in detail but right now I cannot.

No problem, we can wait. When will you be able?