The author here, thanks for posting this. I can see a lot of people not agreeing with Go, that’s fine, I still love writing it everyday. Taking choices away from you in terms of language features enables you to focus on the problem you’re solving. That makes it a great choice to me.
> Taking choices away from you in terms of language features enables you to focus on the problem you’re solving.
As someone that worked with Kotlin for a couple of years, I can agree with this. I actually enjoyed the language but there were so many, I'd say, obscure things or multiple ways you could do the same thing that I'd feel lost sometimes. As someone once said - Kotlin is easy to write, but somewhat hard to read. In the end I just wanted to solve problems and ship my product and I felt the language was getting in my way a lot of the times.
Anyway, in the end I guess it's about personal feeling and conformity with the language of choice.
This is a false dichotomy though. Not wanting to end up as a kitchen-sink language like C++ doesn't mean that you have to swing completely to the other extreme and refuse to add any modern feature (except possibly after years of fighting), even the ones that exist in every other modern language and have proven to have no real downsides and be hugely useful (like sum types).
There is no false dichotomy in my comment. I'm quite happy using Go. It was easy to pick up, the executables work fast and flawlessly and as a language it delivers the required results in what I do so far. Time will tell, but its simplicity does work great for me, and I've tried quite a lot of languages in the past 2 decades.
Yeah, personal feelings towards a language are a big factor.
I once did a short gig with a start-up that used Kotlin and the CTO was very enthusiastic about Kotlin. He showed all the things you could do in the languages like adding behavior to an integer that would be applied throughout the program. He was excited and I was a little horrified haha. But huge companies have been built using Kotlin so who am I to judge?
I'm in the same boat as you, I want to solve problems and build products.
It's very arrogant to imply that people who prefer other languages don't want to "solve problems and build products".
That's what everyone wants to do. They just think Go is not the best tool for doing it.
Again, you seem to think everyone else is some kind of academic egghead who enjoys other languages because they let them solve intellectual puzzles. That's not true, they prefer other languages because those other languages are better than Go for practical reasons.
Mate, come on. I've implied none of that. Just said that the simplicity of Go tends to shift my focus, at least, to the problem and product, not as much the implementation.
You like Rust and hate Go, that is very clear. But maybe before you call me arrogant and put words in my mouth, read back my comments. I haven't trashed other languages or told people that what they like is shit. Simply that I like Go, and that I don't agree with your arguments.
It's entirely understandable that you have a different opinion from me; I just don't like the implication that "caring about solving problems" makes one appreciate Go, since that is what nearly all professionals care about.
Btw, my opinion isn't just "liking Rust" -- Rust has plenty of problems. My opinion is that Go is uniquely bad among modern programming languages. Most of the major flaws in Go are fixed in every other modern mainstream language, of which Rust is merely one example.
But I'm not saying that. I'm not saying that professionals don't care about solving problems. I'm saying that by removing features from a language you tend to shift your focus more to solving a problem vs _how_ to solve a problem (in language space).
When you have lots of options you always have lots of opinions, just human nature. When working with low-level problems I get how having lots of options is good since you need to be precise. But, most people work on web-related problems. These have most likely been solved in one way or another before. I don't want to discuss in PRs if you should use x/y/z language feature, I don't think that's relevant for a lot of technical solutions.
No, because I'm not the only person writing code. If someone else chooses to use this feature, I will eventually have to interact with it and/or maintain it.
