Hacker News Reader

Comment by boothead | Hacker News Reader

This sounds very much like two little pigs arguing about the merits of straw vs twigs when they should be building in brick to me.

View on HN

Probably, the news article is not a technical article, focusing on what is the actual stack, because, (http://stackshare.io/uber/uber) shows that there are other layers in the stack of Uber.

By brick, which language would you want to use?

the best one for the job, I am assuming that is what Pham has been brought in to identify.

At that scale my choice would be Java. Proven, reliable, plenty of devs, vendor support, good type system, and plenty of open source code to leverage. Plus it's it's a mature ecosystem.

Java the language or any language that compiles to the JVM and can leverage existing Java libraries?

I'd go with Java itself. It's the most mature and stable. Uber is not a startup. It needs an enterprise solution.

Scala, Go, Python, Haskell, Erlang.

Instagram seems to be doing OK with python.

Personally, for infrastructure level stuff like that and if I was starting from scratch, I would chose Haskell.

At the scale of Uber and given that there would be a lot of legacy hanging around, I would probably chose to build on top of the kind of scala libraries that twitter has been putting out (which it sounds like from the other article about uber's micro services currently on HN they are doing).

The serious statement behind my slightly tongue in cheek remark earlier, was that I don't think either python or node are suitable for building infrastructure type applications that will form the backbone of a constelation of SOA type applications. Round the edges, it's slightly more defensible. However for central infrastructure, I'd rather have rather more foot-bullet barriers than those offer.

Good luck hiring Haskell programmers.

If you're really serious you go C or C++, not interpreted languages at all. But that said, plenty of big scale stuff is running on PHP, Python and Ruby. The language matters less than the people using it and the architecture design.

Actually, that Haskell developers are hard to hire is one of the biggest myths going. Supply of Haskell developers massively outstrips demand at the moment.

In my experience Haskell also neatly address the other two points of people and architecture: the average [0] level of skill of developers in the Haskell community is higher, as is their average level of grit and determination (because of the learning curve). Haskell almost encourages constructing your applications as operations over streams of events (a la event sourcing, unified log etc), which for my money is the best way to think about designing most platform type apps right now.

[0] Note: I'm not claiming that all Haskell developers are coding ubermensch, just that the average level of the pool of talent is higher.

Maybe it's the other way around. You have to be extremely serious when your goal is safe C/C++.

Perhaps part of the problem is that these interpreted languages have made programmers lazy.

Perhaps part of the problem is that a lot of people still don't understand that developer time is one of the biggest costs in developing and maintaining software.

Given that you have a lot of NodeJS and Python developers I would look at Vert.x.

You could then let both sides continue to write the code in the language they are comfortable with but still work on a common platform. Plus being on the JVM it is fast and scalable.

It is not sensible to just stop what you are doing whilst you retrain and rehire your engineering team to learn a new language. Especially in a competitive hiring market like San Francisco.

Reply on news.ycombinator.com