> Ah, I see your point. But it could just as easily be made in nearly any language, the difference at the level of “is abstract-able” is meters rather than kilometers.
True, most languages could do it, but there are some hard stops to how easy it is to abstract in golang, and performance also knocks some languages out.
> The problem is that as soon as you need something more than a command line call the engineering burden explodes relative to languages that natively support greater abstraction at the lexical and logical level.
Agreed, once you're off the happy path things can be many times more painful in Rust than Go. I personally think Go will replace Java in most enterprise-y software shops within 5-10 years. Unless there's a specific reason to use the JVM, Go is more than good enough and it's goals align with industry very well.
I think go would be huge if they could ease their pain points. The average developer isn’t interested in why generics are actually not necessary, or “here’s how you can still use generics” stuff. Even if they’re wrong, you still need to work in that reality.
True, most languages could do it, but there are some hard stops to how easy it is to abstract in golang, and performance also knocks some languages out.
> The problem is that as soon as you need something more than a command line call the engineering burden explodes relative to languages that natively support greater abstraction at the lexical and logical level.
Agreed, once you're off the happy path things can be many times more painful in Rust than Go. I personally think Go will replace Java in most enterprise-y software shops within 5-10 years. Unless there's a specific reason to use the JVM, Go is more than good enough and it's goals align with industry very well.