5 ms·

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

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.

shazow 15y ago
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.
div 15y ago
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.
j_baker 15y ago
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.
- deleted 15y ago
  [deleted]
- cppsnob 15y ago
  > 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. All you're solving with the JVM is runtime object compatibility in a vertical stack. But if this is for a distributed system, you would probably do some sort of SOA anyway. Write services in several languages that easily communicate with each other. Great, so now that you've done that, you have a bunch of services written in languages based on whatever criteria each team decided on. Now your problem isn't code compatibility, it's maintenance and training. All this exercise did was simply trade short term code writing problems for long term support problems. Writing code is never the problem. That's the easy part.
jrockway 15y ago
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.
- andrewflnr 15y ago
  I thought Arc was based on scheme. Maybe that was my imagination, though.
  - pjscott 15y ago
    The implementation is written in Scheme, but Arc itself is not Scheme-based.
  - jrockway 15y ago
    I was referring to the software running on my side.

shazow 15y ago

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.

div 15y ago

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.

j_baker 15y ago

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.

deleted 15y ago
[deleted]
cppsnob 15y ago
> 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. All you're solving with the JVM is runtime object compatibility in a vertical stack. But if this is for a distributed system, you would probably do some sort of SOA anyway. Write services in several languages that easily communicate with each other. Great, so now that you've done that, you have a bunch of services written in languages based on whatever criteria each team decided on. Now your problem isn't code compatibility, it's maintenance and training. All this exercise did was simply trade short term code writing problems for long term support problems. Writing code is never the problem. That's the easy part.

jrockway 15y ago

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.

andrewflnr 15y ago
I thought Arc was based on scheme. Maybe that was my imagination, though.
- pjscott 15y ago
  The implementation is written in Scheme, but Arc itself is not Scheme-based.
- jrockway 15y ago
  I was referring to the software running on my side.