[stpedgwdgfhgdd]

Worked with Go over 6 years; my biggest annoyance at the beginning, verbosity of error handling, has mostly gone away. In most cases the explicit error handling helped us hardening the code.

What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.

[dewey]

Fully agree with your points. In my experience if people flag error handling it almost always means they didn't spend enough time with the language yet, as in the day to day work it's a non-issue.

[za3faran]

Java now has records, record patterns, pattern matching, and switch expressions. Things that the golang author still don't seem to understand the need for (quite ironic for a language that claims it makes concurrency easy).

[Mawr]

Is that more or less ironic than Java copying Go's goroutines and still struggling to add value types?

[za3faran]

Java's designers have consistently mentioned the approach they're taking that Java has the last mover advantage. They cautiously see what features other languages applied, and take what gives them the highest value compared to the complexity introduced.

Java's virtual threads are already superior to golang's approach because they're working on structured concurrency from the start.

Value types are a huge proposition, but they seem to be coming along nicely. They have already baked in nullables/zero values into the design, something that is a pain in golang, and a big gotcha and source of bugs.

The interesting thing is that Java already beats golang because of its superior GCs, particularly in large programs, so it will be interesting to see what sort of performance improvements come out of value types.

[Mawr]

> Java's designers have consistently mentioned the approach they're taking that Java has the last mover advantage.

There's nothing one can do to wiggle away from designing something. You can only make tradeoffs. In this case, Java's sacrificing time. Is that a good call? I don't know.

> They cautiously see what features other languages applied, and take what gives them the highest value compared to the complexity introduced.

They've historically shown poor taste in the features they've chosen, so this strategy doesn't seem to have worked out all that well. Waiting longer doesn't help if you don't know what you're doing.

> Java's virtual threads are already superior to golang's approach because they're working on structured concurrency from the start.

Already? Ten years later! Time matters.

We'll see how much actual adoption there'll be, Go was built with its concurrency solution in mind, so not only are the primitives ergonomic to use, but the entire ecosystem has grown around it. You can't match it in a day.

> Value types are a huge proposition, [...]

"Value types" is a misnomer anyway, it's just "types". We've had those since at least C, some 50 years ago.

> [...] but they seem to be coming along nicely.

I've been hearing this for a while, has it been a decade yet?

> They have already baked in nullables/zero values into the design, something that is a pain in golang, and a big gotcha and source of bugs.

You can't be serious. Complaining about another language's null problems from the perspective of Java?

> The interesting thing is that Java already beats golang because of its superior GCs, particularly in large programs, so it will be interesting to see what sort of performance improvements come out of value types.

It's a wash most of the time AFAIK. Unless we do the classic Java benchmark trick of ignoring memory usage.

[za3faran]

> You can only make tradeoffs. In this case, Java's sacrificing time.

When you have billions of LOC, and take backward compatibility seriously, then that's a very valid approach. Furthermore, we've seen the Java team pick up cadence recently since switching to twice a year releases.

> They've historically shown poor taste in the features they've chosen,

Quite disagree. Which features are you talking about? They've shown very good taste in how records and pattern matching have been implemented for example. An also not jumping on the async bandwagon and opting for virtual threads instead.

> Already? Ten years later! Time matters.

Java had other approaches for dealing with heavyily asynchronous code, but it wasn't as ergonomic. And honestly speaking, the JVM already gives you access to native threads (something that neither golang (only "goroutines") nor python (GIL) for example offer), that unless you're doing heavy IO bound work, it's a non-issue to begin with.

> Go was built with its concurrency solution in mind

That is the claim, but in practice it is quite error prone. I was following golang from pre-release, and I voiced concerns about not having a way to declare immutable values (or at least something similar to C++'s const), but they didn't seem to care. Of course it came to bite them back[1]. Passing channels everywhere is tedious and verbose, and doesn't make it clear what the code is doing at first glance. Futures/Tasks are an easier abstraction to deal with, but of course golang didn't have generics until recently, and they still don't offer a future package.

> I've been hearing this for a while, has it been a decade yet?

You can follow the valhalla project to see what they're up to. It's sufficient to say that the pace picked up significantly on these large projects since switching to a twice a year cadence.

> You can't be serious. Complaining about another language's null problems from the perspective of Java?

Having worked on large golang codebases, I've seen first hand the issues that zero types cause in practice. At least a nullable in Java would throw an NPE instead of silently passing through the system and ending up with completely arbitrary behavior that is challenging to track down. Not to mention that you can use annotations to denote @NotNull in Java, something that golang doesn't have.

> It's a wash most of the time AFAIK. Unless we do the classic Java benchmark trick of ignoring memory usage.

Memory usage should improve with value types, but it also seems that people don't configure their JVMs properly (things like Xmx). In any case, they've also modified G1GC (and probably one or two more) to more aggressively release unused memory back to the OS).

[1] https://www.uber.com/blog/data-race-patterns-in-go/

[nateb2022]

While not perfect, there are ways to generate enums automatically using go:generate, e.g. https://github.com/abice/go-enum

[earthboundkid]

I almost included a section on enums in the post, but I figured it was long enough, and I don't really have strong opinions about it. Probably a normal enum system would be better than iota, but it's not worth switching.