Hacker News new | ask | show | jobs
by hu3 2446 days ago
Interesting how developer views can differ.

Someone describes Go as "unacceptably crippled" while Uber engineering has 1500 microservices written in Go, making it their primary language.

https://news.ycombinator.com/item?id=21226347

4 comments

Businesses often prefer poor languages with lots of cheap programmers readily available to the opposite, because this lets them easily trade off quality against price. Want it done cheap and fast? Get a freshman intern to write it in PHP or JavaScript; if you later want quality, you can then hire some more expensive seniors to fix it up. If you pick Haskell instead, it may be more reliable upfront, but you also have to pay the full price upfront.

Go was explicitly designed to be a poor language of this sort, as evidenced by the infamous Rob Pike quote:

> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

In other words: a language that makes programmers fungible. And how did they accomplish this? By omitting features and barely going for the lowest-common denominator of the languages listed, disregarding any reasons other languages may have for their more ‘advanced’ features like generics. Hence, crippled.

(Frankly, I object more to describing Scala as ‘the most complex edifice’.)

I'm a big fan of scala and really enjoy the language. That being said, the scala community does sometimes advocate an approach that's pretty over-engineered.
These are orthogonal points. Linux Kernel is all in C and possibly drives the world. Doesn't mean it's safe and amazing.
C was the only sensible choice back then.

Uber on the other hand has many languages available yet picked Go. So they certainly don't think it is "unacceptably crippled".

There is an implicit "for my use-case" following "unacceptably crippled". So, go is not "unacceptably crippled" for the use case of creating a ton of small, simple, easily maintainable services at Uber, but it might be "unacceptably crippled" for the use case of having fun with type systems, or whatever the author was interested in at the time they were considering go as an option.
The paragraph starts with "The beauty of programming language design".

Even the most charitable interpretation would conclude it's speaking in broad terms and not just "for my use case".

Full paragraph:

> The beauty of programming language design is not building the most complex edifice like Scala or making the language unacceptably crippled like Go - but giving the programmer the ability to represent complex ideas elegantly and safely. Rust really shines in that regard.

Many teams just start with what they know and then that sets the tone. It no way means that the language is better. Amazon uses Java. Does that mean it's better than Go ? Popularity paints an incomplete picture at best.
Except that Uber started with JavaScript and Python.

Switching to Go was an educated decision. Not a continuation of what was there.

https://www.quora.com/What-is-the-technology-stack-behind-Ub...

I can speak as someone who is building a microservice application in Go and was actually part of the decision to use Go, rather than Java or C# which we traditionally used.

I also find Go-the-language unacceptably crippled. Unfortunately, Go-the-runtime is the only best runtime for microservice-based applications, if you want a GC, especially if you want to run the system on limited hardware.

All the other options are either too bloated to comfortably spawn in large numbers (Java, C#, Node, Python, Ruby take too long to start, use too much RAM , and/or give you too large containers), or are too new and unproven (Nim).

So, we chose to use the inferior language and line with a small hit to productivity (language choice has little impact on productivity after the learning stage anyway) for the superior runtime system.

Popularity ≠ Quality.