6 ms·

> We have repositories for the PHP backend, our database schemas, our iOS (Swift/Obj-C) and Android (Java/Kotlin) mobile apps, infrastructure projects written i

> We have repositories for the PHP backend, our database schemas, our iOS (Swift/Obj-C) and Android (Java/Kotlin) mobile apps, infrastructure projects written in Go, C/C++, Lua, Ruby, Perl, and many other projects written in Scala, Node.js, Python, and more Why do organizations allow this? I realize that some platforms require their own languages (iOS, Android), but outside of that, just pick one or two and hold the line.

dboreham 9y ago
Well there's a can of worms! Thoughts based on experience: Asymmetric information situation: newly hired smart engineer says that new subsystem should be written in <language-du-jour>. He says it is so much better than <dinosaur-languages>. Everyone on HN says it is so much better. You however, haven't had the time to try it out on a medium sized project to determine if this is true or the usual new language hype. New Engineer seems to know plenty about it and is insistent. Do you tell them no, or do you let them run? Well now you have N+1 languages. Iterate. Some engineer in your organization develops something that turns out to be useful, as a back-burner project without official approval. They do that in whatever language they think will look good on their resume. Do you pay to have that thing re-written in one of the house languages or do you let it ride and add it to the mix. N+1 languages. Iterate. And...in general good luck with not "allowing this" in the context of software developers. Cat herding and all that.
- cobbzilla 9y ago
  The answer to both situations is "No" and "No". Many engineering managers have a difficult time saying "no", to the detriment of the business. We are building a product for customers, not a playground or post-graduate program. There are legitimate reasons to add another language but they must be evaluated with the needs of the business in mind, these include long-term maintenance costs and hiring/training costs regarding new/esoteric skill sets, among others.
  - volkk 9y ago
    Surely there's a middle ground? Plenty of good companies allow for fun experimentation. However, I also wouldn't say that switching to a new language or frame work that may boost long term productivity and hiring effectiveness is considered a playground
    - cobbzilla 9y ago
      If I read "good companies" to mean those that have enough excess resources to make lots of foolish mistakes, then yes, totally agree. "Keeping devs happy" by itself is a terrible reason to introduce a new language. If your developers cannot find happiness by working together and building something great, you have bigger problems.
      - news_to_me 9y ago
        > If your developers cannot find happiness by working together and building something great Just a friendly reminder that there are lots of different kinds of people who approach their work differently. Not being "business-driven" isn't necessarily a bad thing.
        cobbzilla 9y ago
        sure but wouldn't you agree that being in business at all, and not unemployed, is a bigger thing, and that the luxury to play is earned by success. if you can't pay people including yourself, I suppose you can always stay at home and play/experiment all you want.
        news_to_me 9y ago
        It depends on your perspective. Different people are motivated by different aspects of engineering – lots of folks simply like "playing" as you put it, and the business's bottom line isn't important (except insofar as the business can employ them). From the business's perspective, they want the best engineers they can get, regardless of the engineer's motivations — as long as they can get them to provide enough value to the business, it can be worth some trade-offs like having hackweeks, etc. It's the business's job to align the incentives of their workers, and sometimes this includes throwing them a bone in choosing a preferred language, even though it may not be the most efficient.
- bluesnowmonkey 9y ago
  Or you acquire a company that had a different set of approved languages. Do you throw their tech away and rebuild from scratch? No. N+M languages.
Sir_Cmpwn 9y ago
Why?
- virmundi 9y ago
  The more languages you have the more you have to know just to know what the software knows. This makes things hard. Heck jumping from what I call back end languages like Go to Java to C# requires a mental switch if you've been doing one for a week or more. I'm using Go now, but I've got 13 years of Java experience with a Java Ring (https://images.techhive.com/images/idge/imported/article/jvw/1998/04/jw-04-javaring-100158141-orig.gif https://images.techhive.com/images/idge/imported/article/jvw...) on my hand. When I switch back to Java I mutter the phrase, "Nope. Nope. Nope. That's Go, not Java." You should use the right tool for the job. Python is good for AI stuff. Java is good for performance and maintainability. Go is interesting any might give Java a run for its money. You should limit adding tools because they're cool. Do that for bow ties not code.
  - Sir_Cmpwn 9y ago
    Big enough companies may have lots of different projects and many individuals won't work on more than two or three languages max on the daily, though.
    - virmundi 9y ago
      Give then context of the conversation I think the company was limited to one team or perhaps a few. Even within a larger company multiple languages limits the effectiveness of Human Resources. You can't as easily move people between teams.
      - Sir_Cmpwn 9y ago
        The context? Tumblr? They have over 400 employees.
        virmundi 9y ago
stctgion 9y ago
Totally agree with this. I've had to pick up the pieces on more than one occasion when some key piece of code was written in the flavour of the month and the writer shortly left. I've heard other Devs say you should pick the right language for the job but I think there should be a heavy bias to what the rest of the code base already is using
- megous 9y ago
  None of those, except perhaps for the golang are a flavor of the month languages. Using "Right tool for the job" is also important.
  - jrs95 9y ago
    And golang is a relativley "safe" FOTM language in that basically anybody ought to be able to learn enough about it to work with it in a short amount of time. When Scala was a FOTM, it probably did a lot more damage.
jsjohnst 9y ago
> Why do organizations allow this? While I generally agree with you on principle, I also feel you need to be pragmatic too. It’s important to also use the right tool for the job as long as you have sufficient engineers who can support that alternative language/framework/platform. Sometimes a language can also be favored at one point, but lose favor later, and in some cases it doesn’t make sense priority wise to rewrite it because it still works.
athenot 9y ago
Why? Having many languages allows to pick the sweetspot for each subsystem. Each language has special strengths and weaknesses, there is no silver bullet that excels at everything. Go, C/C++, Lua, Ruby, Perl, Scala, Node.js, Python... each of these are THE best choice for certain classes of problems (and terrible for others). It may be because of language features that elegantly express a solution, or particular efficiency considerations (speed, latency or memory footprint), or integrations with specific libraries (if language X has a lib that does 90% of the requirement, use it instead of reimplementing from scratch in language Y). Also, it may be a team consideration: the talent pool for front-end engineers has different preferences than the talent pool for some back-end systems. In a large system like Tumblr, they are likely highly distributed with many different subsystems running in different parts of their infrastructure, each with their own SLA and resilience requirements. Their team is probably large enough that most engineers focus on only some of the subsystems, and communication between them is via defined interfaces. Though having a diverse ecosystem fosters an openess of mind, instead of enforcing "One Metaphore To Rule Them All". You find yourself borrowing efficient patterns from other environments, as they eventually start cross-pollinating.
- pencilhappen 9y ago
  > Each language has special strengths and weaknesses, there is no silver bullet that excels at everything. Go, C/C++, Lua, Ruby, Perl, Scala, Node.js, Python... each of these are THE best choice for certain classes of problems (and terrible for others). Not quite true... not all languages have a sweet spot in a production environment. Node.js isn't particularly excellent at anything, the attraction is mainly "I know JS, and I don't want to learn anything else right now", which is a terrible attitude for someone who wants to have a career in tech. Knowing more than one tool in the toolbox is a key skill, since there is no one-size-fits-all. Jury is still out on Scala. It's a big language, but unclear if there's a production sweet spot or not compared to other JVM hosted languages. The rest of the ones you listed have their definite sweet spots. There are tons of languages though, and most don't have one.
  - 0xCMP 9y ago
    Ruby, Python, Perl, PHP, and (maybe) Lua aren't amazing at handling async operations like Node.JS can. Go is, in many respects, a great replacement for Python and Node in that it's simple and handles concurrency well. Scala and other JVM languages fall here too, but come with their assoc complexity. Python, Node, and Ruby have tons of battle-tested code which often makes the language the "strongest" if for nothing else than there is code that works and it's not critical enough we rewrite it ourselves. There are definitely sweet spots for each of these languages.
grimjack00 9y ago
In the case of my current org, we've used Ruby/Rails and Elixir/Phoenix, but we just go bought by a bigger org that has been mainly Microsoft for years. We can either drop everything (ignoring current paying customers) and rewrite it all in C#, or we can have a mix of MS/Ruby/Elixir.

dboreham 9y ago

Well there's a can of worms! Thoughts based on experience: Asymmetric information situation: newly hired smart engineer says that new subsystem should be written in <language-du-jour>. He says it is so much better than <dinosaur-languages>. Everyone on HN says it is so much better. You however, haven't had the time to try it out on a medium sized project to determine if this is true or the usual new language hype. New Engineer seems to know plenty about it and is insistent. Do you tell them no, or do you let them run? Well now you have N+1 languages. Iterate. Some engineer in your organization develops something that turns out to be useful, as a back-burner project without official approval. They do that in whatever language they think will look good on their resume. Do you pay to have that thing re-written in one of the house languages or do you let it ride and add it to the mix. N+1 languages. Iterate. And...in general good luck with not "allowing this" in the context of software developers. Cat herding and all that.

cobbzilla 9y ago
The answer to both situations is "No" and "No". Many engineering managers have a difficult time saying "no", to the detriment of the business. We are building a product for customers, not a playground or post-graduate program. There are legitimate reasons to add another language but they must be evaluated with the needs of the business in mind, these include long-term maintenance costs and hiring/training costs regarding new/esoteric skill sets, among others.
- volkk 9y ago
  Surely there's a middle ground? Plenty of good companies allow for fun experimentation. However, I also wouldn't say that switching to a new language or frame work that may boost long term productivity and hiring effectiveness is considered a playground
  - cobbzilla 9y ago
    If I read "good companies" to mean those that have enough excess resources to make lots of foolish mistakes, then yes, totally agree. "Keeping devs happy" by itself is a terrible reason to introduce a new language. If your developers cannot find happiness by working together and building something great, you have bigger problems.
    - news_to_me 9y ago
      > If your developers cannot find happiness by working together and building something great Just a friendly reminder that there are lots of different kinds of people who approach their work differently. Not being "business-driven" isn't necessarily a bad thing.
      - cobbzilla 9y ago
        sure but wouldn't you agree that being in business at all, and not unemployed, is a bigger thing, and that the luxury to play is earned by success. if you can't pay people including yourself, I suppose you can always stay at home and play/experiment all you want.
        news_to_me 9y ago
        It depends on your perspective. Different people are motivated by different aspects of engineering – lots of folks simply like "playing" as you put it, and the business's bottom line isn't important (except insofar as the business can employ them). From the business's perspective, they want the best engineers they can get, regardless of the engineer's motivations — as long as they can get them to provide enough value to the business, it can be worth some trade-offs like having hackweeks, etc. It's the business's job to align the incentives of their workers, and sometimes this includes throwing them a bone in choosing a preferred language, even though it may not be the most efficient.
bluesnowmonkey 9y ago
Or you acquire a company that had a different set of approved languages. Do you throw their tech away and rebuild from scratch? No. N+M languages.

Sir_Cmpwn 9y ago

Why?

virmundi 9y ago
The more languages you have the more you have to know just to know what the software knows. This makes things hard. Heck jumping from what I call back end languages like Go to Java to C# requires a mental switch if you've been doing one for a week or more. I'm using Go now, but I've got 13 years of Java experience with a Java Ring (https://images.techhive.com/images/idge/imported/article/jvw/1998/04/jw-04-javaring-100158141-orig.gif https://images.techhive.com/images/idge/imported/article/jvw...) on my hand. When I switch back to Java I mutter the phrase, "Nope. Nope. Nope. That's Go, not Java." You should use the right tool for the job. Python is good for AI stuff. Java is good for performance and maintainability. Go is interesting any might give Java a run for its money. You should limit adding tools because they're cool. Do that for bow ties not code.
- Sir_Cmpwn 9y ago
  Big enough companies may have lots of different projects and many individuals won't work on more than two or three languages max on the daily, though.
  - virmundi 9y ago
    Give then context of the conversation I think the company was limited to one team or perhaps a few. Even within a larger company multiple languages limits the effectiveness of Human Resources. You can't as easily move people between teams.
    - Sir_Cmpwn 9y ago
      The context? Tumblr? They have over 400 employees.
      - virmundi 9y ago

stctgion 9y ago

Totally agree with this. I've had to pick up the pieces on more than one occasion when some key piece of code was written in the flavour of the month and the writer shortly left. I've heard other Devs say you should pick the right language for the job but I think there should be a heavy bias to what the rest of the code base already is using

megous 9y ago
None of those, except perhaps for the golang are a flavor of the month languages. Using "Right tool for the job" is also important.
- jrs95 9y ago
  And golang is a relativley "safe" FOTM language in that basically anybody ought to be able to learn enough about it to work with it in a short amount of time. When Scala was a FOTM, it probably did a lot more damage.

jsjohnst 9y ago

> Why do organizations allow this? While I generally agree with you on principle, I also feel you need to be pragmatic too. It’s important to also use the right tool for the job as long as you have sufficient engineers who can support that alternative language/framework/platform. Sometimes a language can also be favored at one point, but lose favor later, and in some cases it doesn’t make sense priority wise to rewrite it because it still works.

athenot 9y ago

Why? Having many languages allows to pick the sweetspot for each subsystem. Each language has special strengths and weaknesses, there is no silver bullet that excels at everything. Go, C/C++, Lua, Ruby, Perl, Scala, Node.js, Python... each of these are THE best choice for certain classes of problems (and terrible for others). It may be because of language features that elegantly express a solution, or particular efficiency considerations (speed, latency or memory footprint), or integrations with specific libraries (if language X has a lib that does 90% of the requirement, use it instead of reimplementing from scratch in language Y). Also, it may be a team consideration: the talent pool for front-end engineers has different preferences than the talent pool for some back-end systems. In a large system like Tumblr, they are likely highly distributed with many different subsystems running in different parts of their infrastructure, each with their own SLA and resilience requirements. Their team is probably large enough that most engineers focus on only some of the subsystems, and communication between them is via defined interfaces. Though having a diverse ecosystem fosters an openess of mind, instead of enforcing "One Metaphore To Rule Them All". You find yourself borrowing efficient patterns from other environments, as they eventually start cross-pollinating.

pencilhappen 9y ago
> Each language has special strengths and weaknesses, there is no silver bullet that excels at everything. Go, C/C++, Lua, Ruby, Perl, Scala, Node.js, Python... each of these are THE best choice for certain classes of problems (and terrible for others). Not quite true... not all languages have a sweet spot in a production environment. Node.js isn't particularly excellent at anything, the attraction is mainly "I know JS, and I don't want to learn anything else right now", which is a terrible attitude for someone who wants to have a career in tech. Knowing more than one tool in the toolbox is a key skill, since there is no one-size-fits-all. Jury is still out on Scala. It's a big language, but unclear if there's a production sweet spot or not compared to other JVM hosted languages. The rest of the ones you listed have their definite sweet spots. There are tons of languages though, and most don't have one.
- 0xCMP 9y ago
  Ruby, Python, Perl, PHP, and (maybe) Lua aren't amazing at handling async operations like Node.JS can. Go is, in many respects, a great replacement for Python and Node in that it's simple and handles concurrency well. Scala and other JVM languages fall here too, but come with their assoc complexity. Python, Node, and Ruby have tons of battle-tested code which often makes the language the "strongest" if for nothing else than there is code that works and it's not critical enough we rewrite it ourselves. There are definitely sweet spots for each of these languages.

grimjack00 9y ago

In the case of my current org, we've used Ruby/Rails and Elixir/Phoenix, but we just go bought by a bigger org that has been mainly Microsoft for years. We can either drop everything (ignoring current paying customers) and rewrite it all in C#, or we can have a mix of MS/Ruby/Elixir.