[mbvisti]

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.

[umanwizard]

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.

[mbvisti]

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.

[umanwizard]

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.

[mbvisti]

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.