> nothing else to do than to write concrete code to solve the problem

And by that you mean "invent ad-hoc code generators instead of using built-in language features from the 21st century", right?

Not to diss on Haskell, but to illustrate the difference: There's an entire HaskellX 2022 talk about "language extensions we use, extensions we are cautious about, extensions we never use". There are many ways to solve problems in Haskell; and mostly only one or two ways to do things in Elm. The most choice I can think of is in context of parent-child communication (Config pattern, OutMsg, flat Msg type). Most everything else has a single obvious solution.

Yes, sometimes the simplicity of the language leaves you wanting a bit more power (typeclasses, macros) but the code quality seems (to me) better with the constrained language than with the unconstrained one.

Well, one is a research language with the explicit goal of trying out new language features, so the comparison falls flat imo.

Also, doing only GUIs is quite a bit more restrictive than general purpose programming and not every fancy feature may make sense there.

That's an unfortunate problem that Go has, admittedly; it's far from a perfect language. I'm just glad they resist adding language features for isolated use cases.

One example of code generators is enums, I'd love for Go to add that as a feature, I frequently use them in other languages. Go's equivalent is a list of consts with a shared prefix, e.g. StatusOK, StatusBadRequest etc for HTTP error codes [0], then functions to do anything with them (like getting a status text for the aforementioned HTTP status codes; see [0] and scroll down a bit).

I mean it's not difficult code; nobody has to learn any new syntax or methodologies to understand enums if they already know consts / variables, functions and switch/case statements. It's just inelegant and it feels unsafe - you need a linter [1] to check for exhaustiveness of the aforementioned switch/case, on top of a ton of other linters [2] that IMO should be language features or compiler checks.

My personal gripe is struct tags that are just strings that no tooling or compile-time checks will check, they're left up to a library (or the standard library) to interpret at runtime. In other languages like e.g. Java they introduced annotations to add metadata to properties.

[0] https://go.dev/src/net/http/status.go

[1] https://pkg.go.dev/github.com/nishanths/exhaustive

[2] https://github.com/golangci/awesome-go-linters

Regarding Go, it didn't have generics until recently, partly because some of the community didn't think it was beneficial. They've been nothing but positive in our project as we've been able cut down on substantial amounts of boilerplate in some areas.

Isn't that the grandparent's point though? Features that other languages have are first considered "not beneficial" and are in fact mocked as being useless or extravagant. Then, once said feature is introduced to one's favourite language, the feature is considered useful and it turns out that maybe those other languages had a reason for including them beyond mere extravagance.

edit: gp, not p

Also known as "the Blub paradox". https://wiki.c2.com/?BlubParadox

> partly because some of the community didn't think it was beneficial

And partly because it needed more thought. I'm all for more well thought out features, but there's also value in a language that doesn't move fast and doesn't break things. And I say that while Python is my main work horse, so I understand what breaking things mean.

This post from Russ Cox was really insightful to explain that Go's generics and the delay in implementing them were a technical issue, not a political or opinion based one:

https://news.ycombinator.com/item?id=9622417

> We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make.

The Go team does their homework, and they do it thoroughly. I respect that more than anything about the language. Compare with Java, that had been stagnant in committees for nearly a decade, or with Javascript, that has been bolting on features left and right; I'm mainly thinking of the half-baked OOP addition.

The Go developers, many years before implementing generics, made it clear they were open to the idea. It was more about how it would fit into the language and them agreeing on it.

To their credit, they don't just throw things into the language because it's trendy or "cool" at the moment. Even if people disagree with their decisions, they are well considered and thought about decisions.

It’s funny you call out Java, when it is exactly the language famous for taking advantage of being the last mover — even its original intros mentioned it!

Also, languages don’t start in a vacuum, they shouldn’t have to go through the whole process from zero each time — Go absolutely failed by not incorporating it from the first version.

In my experience, real-world Go can be just as complicated as real-world Python or C++. The lack of abstractions is making the problem worse, if anything.

Do you think the new go Generics solve this in some part?

It thankfully removes the need for code generators or large swathes of copy / pasted code with all the risks and maintenance overhead that incurs.