3 ms·
From what I've seen, the people who complain about go's design are people who are more concerned about the ways in which it is not correct (by some definition)
by cdent 2y ago
From what I've seen, the people who complain about go's design are people who are more concerned about the ways in which it is not correct (by some definition) and less concerned about just getting stuff done.
I don't "like" go (or any other programming language), but I'm able to get more done in it in a shorter amount of time than any other language, the created thing consumes tiny amounts of resources, and most importantly when I _or anyone else_ goes back to change something weeks, months, years later it's easy to re-establish or gain contextual understanding.
- taberiand 2y agoI like go, and I use it to get stuff done. I'd be able to get stuff even more done with sum types and pattern matching and better generics and iterator tools and it's a shame Go doesn't have these things.
- alkonaut 2y agoThese were the first lines of Go I ever wrote 15 minutes ago, as a response to the claim that Go had working enums. This is the kind of thing that makes me itch. https://go.dev/play/p/MMPMh7_U81- https://go.dev/play/p/MMPMh7_U81- I think "being simple" doesn't necessarily mean "must have subtle sharp edges and papercuts everywhere". Just like javascript I think it falls into a pit of being superficially "low complexity" or "simple", but all the subtle gotchas and unhelpful tooling (The fact a compiler can't help me realize I had added an entry to the enum, but forgotten to update a name list just means the whole feature is no better than just plain ints that we had in C since before I was born).
- guappa 2y ago> I'm able to get more done in it in a shorter amount of time That's because you know it better than other languages. It's certainly not a universal experience.
- kerkeslager 2y agoI mean everything you just said about Go applies to Python except the "consumes tiny amounts of resources"--it's certainly my most productive language, and the code looks a lot like the pseudocode people write when they're trying to descrbe an algorithm so it's pretty dang easy to read. But you don't hear me going around claiming it's well-designed. Taking async design cues from f-ing JavaScript, leaning harder into the GIL, was a horrific mistake, for example.