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

[bug77]

Optional <T> is not really comparable to the standard error handling paths for other languages, so I left that out of the discussion. With minor language tweaks it is feasible to reduce the verbosity and there has been multiple proposals including one that was widely expected to be part of Go 2 but unfortunately wasn't adopted. I am still hoping this will improve in a future release. Result<T> is still superior IMO because it is a stronger type but Go in general has adopted a more weakly typed system so it won't be a large knock once they address the verbosity with some sort of syntax sugar.

Fair enough. Just like generics*, I'm all for doing it right rather than doing it fast.
At the same time, I realize that some missing features is the price we pay for Go's pretty impressive compile speeds. So I really don't have a problem living with a few kinks. After all, I've been living with Java since its 1.1 release

* Go's generics were also supposed to land in Go 2, but it turned out they could be implemented without breaking backwards compatibility and landed in 1.18 instead.

[mether]

That's correct, for Result<T> and Rust. But Optional<T>(and Java) is still just as verbose as a tuple. Come to think of it, it's actually worse than a tuple, because Optional<T> doen't actually return the error.

Optional <T> is not really comparable to the standard error handling paths for other languages, so I left that out of the discussion. With minor language tweaks it is feasible to reduce the verbosity and there has been multiple proposals including one that was widely expected to be part of Go 2 but unfortunately wasn't adopted. I am still hoping this will improve in a future release. Result<T> is still superior IMO because it is a stronger type but Go in general has adopted a more weakly typed system so it won't be a large knock once they address the verbosity with some sort of syntax sugar.

[bug77]

Rust has other differences in error handling that is better ergonomically (? operator) or more powerful (thiserror, anyhow etc). Go is not bad, just very verbose.

That's correct, for Result<T> and Rust. But Optional<T>(and Java) is still just as verbose as a tuple. Come to think of it, it's actually worse than a tuple, because Optional<T> doen't actually return the error.

Just to be clear: Go's error handling is verbose. When naively writing code, I ended up with half of the lines of code dealing with errors. But I still found the language productive despite that.

[Luke_Wolf]

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.

No you don't. The honest truth is that developers don't want the mental overhead of having to deal with multiple languages, however they tolerate it because that's the reality of the situation. Every developer would prefer if all applications were written in his favorite programming language, regardless of whether it's because it's the only one he's learned and thus is clinging to or if he actually does have strong preferences on languages.

This is why languages which are not designed to be general purpose get abused into eventually becoming general purpose languages, such as Javascript, despite being completely unfit for that. What that means is that if new languages are introduced by large companies and then adopted solely for the sake of being the child of said company such as Go, and the language has not learned from the past important principles like generics being perhaps the single most important feature of any language (even if you aren't directly writing generic code, for the code you're relying upon) then it forces harmful programming practices which other developers will be forced to deal with the consequences of with this having been obvious for decades. It becomes especially difficult when everything in a domain is written in a particular language Scala is honestly a terrible language that is a giant ball of duct tape and chewing gum barely holding everything together, but it's probably going to dominate the big data space for another decade still because of Apache Spark.

If you don't want convergence then your only choice is to limit and get others to make the purposeful choice of limiting what they write in what particular language rather than believing that YourFavoriteLanguage works great for everything, when that is only really arguably true of languages that started from the stance of being general purpose.

[mether]

Doesn't the compiler err if you assign a value and don't use it?

Yes, if you foo = bar(zoo), you can ignore the error in Go accidentally but if you do. foo, err = bar(zoo) and then you don't use it, the compile will warn. There are two issues with that, 1) err is often reused as a variable, so you may accidentally not check an earlier assigned error, lots of people get into the habit of using _ for the second variable which bypasses the compiler check, this is in part of how repetitive this gets, sometimes you want to do this temporarily, focus on the core logic and get back to handling error but then never get around to doing it.

[sinepgib]

How is returning a tuple different from returning a Result<T> or Optional<T>?

Because:
1. It gets embedded into the type system.
2. The program doesn't type if you don't check both cases.

With a tuple you can still ignore the second value by accident. With a Result<T> or Optional<T>, if you really want to ignore it, you need to do so explicitly.

it IS error prone because one can simply "forget" checking errors and this is exactly because errors are NOT explicit.

Doesn't the compiler err if you assign a value and don't use it?

[mether]

But the problem is, that it is not a good language for people who already do have programming experience and have grown accustomed to language features that other languages have and Go doesn't.

This is certainly too broad a statement, there are programmers for instance in Scale which has a ton of the more "advanced features" and moved away to Go precisely because these features have a high cost to them. Now there might be domains where the features are worth the cost but this is certainly not the case for everyone. It is perfectly good language for a lot of the domains that it is highly used already, it is popular there for very good reasons.

[mether]

How is returning a tuple different from returning a Result<T> or Optional<T>?

Rust has other differences in error handling that is better ergonomically (? operator) or more powerful (thiserror, anyhow etc). Go is not bad, just very verbose.

[bug77]

Agree. Go is a good first or second language ... i.e. a language for people who still don't know how to program very well.
Because it is so simple.

But the problem is, that it is not a good language for people who already do have programming experience and have grown accustomed to language features that other languages have and Go doesn't.

I beg to disagree. I've been a software programmer for over 15 years (and started programming way earlier than that). I've seen languages with all sorts of features, yet I still appreciate Go's simplicity and rather rich runtime.
It's still a tool you must use for the right purpose, but if you don't stop to bitch about missing this and missing that, Go is a surprisingly productive beast.

With these people, even after 2 years of programming in Go, every other conversation starts with "I'm searching for some sane way of how I could do in Go something that I used to do easily in XXX language before"

This is a toxic mindset, stay away from these developers. That's the type of developer that have learned one language and will not really learn anything ever again. They just take a superficial look at alternatives, try to use them the one and only way they know of and conclude the alternative is not up to par.
When learning a new language, you have to take Yoda's advice and "unlearn what you have learned". Treat it as your first language, understand why it does things the way it does. Only after you have done all that can you start comparing.

[aksdb]

Agree. Go is a good first or second language ... i.e. a language for people who still don't know how to program very well.
Because it is so simple.

But the problem is, that it is not a good language for people who already do have programming experience and have grown accustomed to language features that other languages have and Go doesn't.
With these people, even after 2 years of programming in Go, every other conversation starts with "I'm searching for some sane way of how I could do in Go something that I used to do easily in XXX language before"

Bullshit. I have over 15 years of development experience and I and other senior developers around me enjoy Go simply because it heavily reduces the mental burden and allows us to concentrate on solving business problems. We don't have to constantly research about the new features that get introduced every few month (because Go keeps that to a minimum), the documentation is great and the low amount of variety in language features causes all libraries we work with to be understandable. There isn't suddenly a library where the author thought "hey, let's do this 100% functional" or "why not use inheritance all the way to the bottom".

Same cannot be said about Java, C++, Rust, etc. Every library you encounter there follows completely different patterns and paradigms. Good look understanding them. You also can't write the simplest of services or tools without pulling in a shitload of dependencies. Hell, in Java or C++ I wouldn't even write and execute unit tests without a third party lib. In Rust that particular point is better, but writing anything more than Hello World still requires third party libs and then it's completely random if the libs use or don't use macros, use or don't use functional programming aspects, and how much of the available syntax sugar they apply.

So I stand by my opinion that Go serves its purpose. So do the other languages; everyone is free to choose what they prefer.