Go 1.18 Released With Generics, Fully Integrated Fuzzing, ~20% Performance Improvements

[squash]

Guys, if Go was "more like java" or "more like rust" then what would be the point of Go?

Go programmers don't care that you prefer how Java's exceptions work vs checking and handling errors immediately, in fact most of us think Java's exceptions (and classes!) are a glaring example of how not to do it. If we liked the way Java did things, we'd use Java.

If it's not your thing, if you really just want to create Factory Factories all day and throw exceptions for things that aren't exceptional, your needs are well covered and keep on keeping on.

[bug77]

Guys, if Go was "more like java" or "more like rust" then what would be the point of Go?

Go programmers don't care that you prefer how Java's exceptions work vs checking and handling errors immediately, in fact most of us think Java's exceptions (and classes!) are a glaring example of how not to do it. If we liked the way Java did things, we'd use Java.

If it's not your thing, if you really just want to create Factory Factories all day and throw exceptions for things that aren't exceptional, your needs are well covered and keep on keeping on.

This guy gets it.

[fazalmajid]

The "up to 20% performance improvement" due to the calling convention change (using registers instead of the stack) is for non-amd64 platforms like ARM64. That change was already implemented for amd64 in Go 1.17:

https://go.dev/blog/go1.17

[aksdb]

Guys, if Go was "more like java" or "more like rust" then what would be the point of Go?

Go programmers don't care that you prefer how Java's exceptions work vs checking and handling errors immediately, in fact most of us think Java's exceptions (and classes!) are a glaring example of how not to do it. If we liked the way Java did things, we'd use Java.

If it's not your thing, if you really just want to create Factory Factories all day and throw exceptions for things that aren't exceptional, your needs are well covered and keep on keeping on.

Thanks. That's exactly the point. Unfortunately with every language the same shit happens over and over ... "but language X has Y, why don't you?! please implement it!". Then we end up with the next language X. Great. In the end no one uses it because it's just the same as the existing language but with a smaller community, less support and less contributions.

I want alternatives, not copies. Go is a great alternative. So is Rust. So is Haskell. They all serve their purposes.

[Luke_Wolf]

bug77 it's still a mich less elegant solution than exceptions, even if exceptions have their issues. And sure, very trivial code is mostly fine, but put together a couple of these functions and suddenly your code will become anything but clean.

Rust and other similar ML derived languages' Result<T> and Option<T> are just the right way to do it vs Exceptions or the C or Go way of error handling. It expresses to the caller that an Error may occur or that a result may not exist (which is different from an error) and forces you to handle the case when it comes up. No weird excessive handling, no jumping around in code.

Also when it comes to Generics in modern actively developed languages: Those who fail to implement Generics from the start of a language are doomed to implement it poorly in the future

[squash]

Rust and other similar ML derived languages' Result<T> and Option<T> are just the right way to do it vs Exceptions or the C or Go way of error handling. It expresses to the caller that an Error may occur or that a result may not exist (which is different from an error) and forces you to handle the case when it comes up. No weird excessive handling, no jumping around in code.

Also when it comes to Generics in modern actively developed languages: Those who fail to implement Generics from the start of a language are doomed to implement it poorly in the future

Honestly these sorts of posts are like.. "Hey look at those guys over there having fun. I'm not having fun which means they shouldn't either! I'll tell them what they're doing is wrong."

Somehow Go manages to be a successful and popular language despite vocal objections from people who have their own favorite languages.

[andrebrait]

I'm not saying every language should be the same and all that and I get the point of being different.

But discussing things and criticizing what you don't like about a given thing is never something bad if done for the right reasons and in a civil and constructive manner.

That's what forums are for, not just flame wars :-)

[kenjitamura]

As someone who learned programming concepts with Go as the first language I've got to say I really like the error handling. I thought it made sense to read the documentation, or more realistically look at the intellisense tooltips, for every function that could return an error. Then you read the description of the error possibilities and decide how to handle it immediately after calling the function.

It's also why I had a vscode snippet where all I had to do was type "terr" and tab, short for terror, to get

if err != nil {
}

That is my novice way to handle it but I've only done code challenges as a hobby and I'm positive people must have engineered better ways to make it more convenient. As far as hurting the readability of code, I never personally thought it had much of an impact. You just get in the habit of recognizing there's an error being handled after some functions in code and glance past it.

When I learned about Try/Catch as the standard for error handling my first thought was "I don't think I'd be able to trust anyone not to screw this up".

Going to try my hand at learning some C# since my current workplace is a Windows shop and they're trying to use powershell as a programming language there and coming from Go I feel like it's missing the powerful intellisense features I was spoiled on. Using Rider with C# is a big step up from trying to work with powershell in vscode.

[Ironmask]

Honestly these sorts of posts are like.. "Hey look at those guys over there having fun. I'm not having fun which means they shouldn't either! I'll tell them what they're doing is wrong."

Somehow Go manages to be a successful and popular language despite vocal objections from people who have their own favorite languages.

... And many companies have had to rewrite their Go services in Rust because Go underperforms so badly that they can't keep up with their workload anymore.
So, no, it's not a matter of taste, it's a matter of wasting time, money and, most importantly, energy.
Go is a plight on the world just like Java and Python are, bogging down systems and wasting energy while people rush to get funding and resources to invent ways out of the hole they dug themselves in by making the mistake of naively choosing those technologies.
You want to write a toy as a hobbyist, go ahead, use whatever esoteric language you want. But don't think it's just a matter of personal taste if you're talking about creating actual business software. Simply assuming people are just "bitter" or "not having fun" is extremely ignorant.

[aksdb]

Also when it comes to Generics in modern actively developed languages: Those who fail to implement Generics from the start of a language are doomed to implement it poorly in the future

Same can be said about async. That's why Go is one of the few languages where async programming doesn't suck balls, because it's part of the language from the start and roots deep into the stdlib. _everything_ you do in Go works fluently with async programming, while for example in Java (and also Rust) you have to take care to either not exhaust OS-level threads or to not call code that blocks your executor in an unexpected way.