Hacker News Reader

Comment by clintjhill | Hacker News Reader

In my opinion, the best part of their infrastructure is their willingness to specialize in languages within each stack. It isn't simply "Java everywhere".

"To allow developers to choose the best language for the job, Twitter has invested a lot of effort in writing internal frameworks which encapsulate common concerns."

The single best investment companies can make is to allow developers to choose their specialty, and their language. Otherwise you have a huge overhead of skill set mismatch. And your talent pool can be bigger if you're open to more than one language.

It's a refreshing view.

View on HN

Twitter can afford the to have multiple languages in their stack but most start-ups simple don't have that luxury. If you have a early stage start up with about 10 developers and you need to quickly build a set of server side component or services for your product, would you want to use multiple languages to develop that or use one programming language ? Having developers choose best languages for the job would be disastrous if you end up with your stack written in 5 different languages. I would not discount the importance keeping codebase easy to manage.

It depends on how much effort it would take to rewrite any of said components.

In my personal experience, for reasonably isolated and small components, 80% of time spent creating a component of code is spent on making decisions. By the end of it, when all the decisions have been made, I could probably rewrite the entire thing from scratch in 20% of the time—and it would likely be better in every way.

It would seem that the first iteration is largely prototyping. If you can save a significant multiplier of time by choosing a different language than the rest of the stack for the prototype and potentially rewrite it later if necessary, why not? Perhaps by the end of it all, you'd break even on time but end up with multiple implementations and better code.

I think it's important to look at how twitter got there though. They'd been using just Rails for a long time before introducing Scala. At that point, it's fair to say they weren't a 10 dev startup anymore.

This, imo, is part of having developers choose the best language for the job. They chose ruby to get their mvp out quickly and be able to grow their userbase. After that, they pinpointed trouble areas in their architecture and made pragmatic choices in fixing up those areas.

While I suppose it's possible to "let developers pick the best tool for the job" and end up with 5 different languages in your stack, most good developers are likely to steer clear of such an endgame, unless the trade-offs are very, very clear.

In my experience, languages don't make a codebase more complex. What makes a codebase complex is how many subcodebases you have. In particular, I avoid touching my company's JavaScript code not because I can't do JavaScript but because it's difficult to learn an entirely new set of APIs.

If you can allow multiple languages to share common code like you can on the JVM, then I say it's ok to go crazy.

I doubt this would be disastrous. For example, to post this message, I'm currently using a "stack" that's written in at least assembly, C, C++, Javascript, and Emacs Lisp. And, it's all written by people who aren't even getting paid to do it.

It seems unlikely that 10 developers in a startup wouldn't be able to maintain code written in a few different languages.

The way you keep a codebase easy to manage is to divide it up into small projects that you can "finish". When was the last time you hacked on glibc? Never? That's how parts of your infrastructure should work: get them right, then forget about them. Using the best language for the job makes this significantly easier.

I thought Arc was based on scheme. Maybe that was my imagination, though.

The implementation is written in Scheme, but Arc itself is not Scheme-based.

I was referring to the software running on my side.

Reply on news.ycombinator.com