I was a Rails, Sinatra, Ruby dev for years and I’ve been work with Go for years too. I’m struggling to understand your perspective because I’m no less happy coding in Go.

I've only done a bit of Go. I liked some of the ideas that were present, but ultimately (and I believe explicitly) Go has computer-sciencey-correctness goals (hence all the kerfluffle over generics) that, now and again, trip things up.

Sometimes that's really nice - we had a handful of tiny utilities written in Go, like a format converter for use in a datastream - other times it gets in the way. I don't think I'd want to code up something large in Go, although it's not something I've had the opportunity to try.

AFAICT, Go believes in preventing you from making certain mistakes. And usually, within it's context and paradigm, it's correct to do so. The problems arise when your problem domain doesn't line up well with that context and/or paradigm, which sometimes just comes down to the time you can spend on the issue.

Another example: IMHO, all the weird issues Go was having working out how to do package management stems from some (admittedly very cool) ideas about Correct And Proper Package Management. I can't remember the last time I had an issue with gem management / bundler (except for the perennially awkward PG gem issue).

It's a 85% vs 95% thing, and IMO that straight-up comes from having other priorities. There's a lot of overlap between "developer happiness" and "computational correctness", but it's not exact, and that comes up in few, but enough, places.

Maybe another good example is Ruby array arithmetic. It makes no bloody sense from a math/CS perspective, but goddamn it is handy in applications. So if your language is aiming for computational correctness, you're not going to get that tiny bit of joy.

> Go has computer-sciencey-correctness goals (hence all the kerfluffle over generics)

I really don't understand this. The debate over generics had nothing to do with "computer sciencey correctness" goals, they had to do with ergonomics. Of course, from Ruby, the idea of typing your code is completely foreign, but imagine if a function only allowed one type of parameter, and if you wanted another you had to define it again with a different name.

Basically like allowing flexible parameters makes function definitions more flexible, a lot like all the metaprogramming business in Ruby

> the idea of typing your code is completely foreign

I don't understand this?

> I really don't understand [Go has computer-sciencey-correctness goals]

My impression (way back when, TBH when Go was first announced and discussed) was that the language creators had some Very Strong Ideas about how to do various things 'much more correctly', and/or to avoid specific pain-points they'd had in other languages, and that those things informed a lot of the decisions about Golang; in particular the module system, generics, and error handling.

I'm calling that "computer-sciencey-correctness goals", perhaps incorrectly, as I also got the impression their goals and methods were heavily informed by CS research into computer languages.

No I don't necessarily disagree about Go, I just don't understand what generics have to do with that.

Are you suggesting generics were divisive because computer science-y people didn't want them or wanted them the best way?

Every language has goals. Many of them explicitly state those goals.

1. https://the-zen-of-go.netlify.app/ 2. https://peps.python.org/pep-0020/ 3. https://thethreevirtues.com/ (perl, arguably) 4. https://rubyonrails.org/doctrine

You will end up sacrificing other things in favor of your principles. Other languages sacrifice developer happiness for theirs. Ruby sacrifices other things in favor of developer happiness.

That's it. Everything else is [my] speculation about why people chose their particular principles.

Citation note: I've always heard that "Developer Happiness" is a thing from Matz (Ruby's language creator), but the only place I'm finding it explicitly stated is in the Rails doctrine.