For me it's a language I always wanted to have: essentially C with a GC, small enough you can carry it in your head with most of the footguns removed.
I honestly also have no idea why Rust always makes an appearance in a Go thread, I can't think of two languages with such a diametrically opposite learning complexity.
> I honestly also have no idea why Rust always makes an appearance in a Go thread
Both Rust and Go people are very vocal about their languages.
Ok, I get it that there are developers that can't live with languages that don't have tons of shiny features to play with, but please don't disparage the others as "inexperienced"! If you have ever gone back to some "expressive" code you wrote months/years ago while feeling very productive and were left wondering "WTF was I thinking when I wrote that? Can someone explain it to me?", then you start to understand the reasoning behind Go's simplicity.
Also, I'm not "disparaging" anyone here. Please read it again and notice that I was simply saying that golang is good if you are inexperienced. That does not mean that every golang dev is inexperienced. If you interpreted my post in that way, I think you should probably ask yourself why that is.
> Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck.
which implies that people who use Go have not grown and become as productive as people that use more expressive languages (because such languages are a "must" to grow in this way). At the very least, you are obviously disparaging Go programmers' productivity.
That's not what it says, or at least not what I meant.
People are different and can accept a different amounts of repetitive work. Heck, there are even people who really like it and want to think as little as possible. So all I'm saying is that there exist people in Go that grow and then want to improve their productivity but are now restricted by the language.
And I think I have a point in the sense that Go is already adapting to those people by e.g. adding generics. So the number of those people can't be that small, otherwise I don't think they would follow their requests.
> because such languages are a "must" to grow in this way
And yeah, there are of course different ways to become more productive, e.g. through other kind of tooling, better organization etc. But the language is definitely one of our most important tools so if the language limits you then switching it is the only way to improve in this regards.
In fact, English is not my native language and I often feel limited in both my mother tongue and English. Sometimes I'd love to just mix the two but obviously I can't. It's the same thing, but natural languages are much closer to each in terms of expressivenes than programming languages are.
> At the very least, you are obviously disparaging Go programmers' productivity.
I'm saying that a developer who feels limited by golang can and will become more productive with a less restrictive language, all other things being equal(!).
For golang there's certainly devs how just don't mind a certain amount of repetitive work and are happy to use Go until retirement. And I don't think that's a problem at all. People are different and I think we should embrace that. If you think being called a "factory worker" is not flattering, then that's more your personal judgement than me being objectively disregarding factory workers.
Again: Try to read my response in the right context. I'm explaining why some people dislike (or even hate) the language. It was a response. Please try to keep that in mind when you reply.
I've never been "stuck" with Go in the sense that I wasn't able to do something I wanted.
I've programmed in plenty of more expressive languages over the years, and I don't think there's much difference in terms of productivity. Sure, some more expressive languages allow you to do something very quickly and concisely, but it also increases cognitive load when writing and reading and in the end it seems to balances out. Sometimes I do find myself thinking "gosh, I wish I had $feature_x from $language_y" at times, but I have that with every language.
It's a "dumb" languages in that sense, I guess. Which is also why it's nice: you don't have to focus on the mechanics of what you're implementing, you just implement what you want, as per the "Zen of Python"; "There should be one – and preferably only one – obvious way to do it."