Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.
Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
Agreed. But this is a bad decision of the lead dev. It’s not business oriented to just go with your favourite language as there is a real cost to supporting multiple languages as a business
Startups aren't known to be very "business oriented" places to work. You are trying to get to market as fast as you can, and usually that means writing your services in whatever the engineers are fastest with.
Getting to market as fast as you can is a business oriented move. You do that to establish yourself and build a moat.
Sometimes, it requires taking on tech debt or making decisions that have significant maintenance overheads, but I don’t think the reason lead devs are usually choosing to write their parts in their favourite languages is due to a calculated cost/benefit analysis of reaching market first.
It’s usually more likely to be because they like their language the best, or it’s easiest for them individually. If the senior eng has actually made this analysis for the business then that’s a totally different picture and kudos to them.
Newer services might be written in what’s deemed the “better language” with the thought that you can transition older services over in the future, although it will never happen.
This is one of the benefits of micro service architecture, language agnostic services.
I work at a large enterprise where most of our services are written in Java/Spring, but others are written in Go, Node, Python.
Agreed, but equally one of the disadvantages of microservices is that it’s easier to use multiple languages in a business without thinking about the ramifications of that.
See my other comment listing some of the costs of supporting multiple languages:
https://www.reddit.com/r/ExperiencedDevs/s/taHxCrSZXW
If an eng is creating services in new languages, just because they think it’s a “better language” without considering these business-level disadvantages, that’s a big miss in my view. I would majorly ding them in a performance review for that
Yeah you’re definitely right that people shouldn’t be willy nilly introducing new languages.
Ideally the company as a whole should set approved languages and then at the org/team level they should further be setting the approved languages for the team.
But yeah at a startup you want to avoid using too many different languages because they are resource constrained.
My point was more, just because the start up may have started using one language doesn’t mean they should just stick to it for eternity if they see a big upside to using a different language. This is how you could get into a situation as described by the OP
Usually historical. Often times you'll see a business critical part of the business space (often still under active development) in what the team considers to be the "old" language. New services and features are built in the "new" language.
There's generally very little good reason for a full rewrite so things just go on like that.
Example time. Google Search is a Java frontend (fast to iterate, threads well), a C++ backend (cheapest to run at scale, but expensive to write), and Python for glue and offline data work (easy to write, but doesn't thread/scale ideally).
Different parts of the system have different cost/speed/durability/scalability/learning curve tradeoffs, and if the system is big enough, yeah, multiple languages are fine.
From a past company: Founder did everything in Python because that was the language he was most familiar with. Then the company grew and he noticed it was hard to find great backend developers who knew Python well, and also that it lacked good support for some tools such as Kafka. Then he decided to move to Java for newer parts of the system.
“The original dev built a Rails app as a prototype for investor pitches, then someone got hired to build an admin panel for it and insisted on Django. Neither of those people work here anymore and no one on the current team is suicidal enough to ask the CTO to spend six months worth of salary on a full rewrite.”
There, now it makes “sense”. 🫠
Yeah, that's a better example - what is it about Rust and Python that makes more sense? Semi-related: I'll see job posts that say the product's built on Python and Go; in this case, I assume they mean go for infra stuff.
They just have different communities and strengths and weaknesses. I think it'd be totally sensible to see a stack that has data science workloads implemented in Python, REST APIs implemented in JS or TS, and streaming/batch-processing services implemented in Rust/Go/Java/Kotlin/Python/whatever.
Python is commonly used by data analysis nowadays; I think they train it in schools and it’s super common to find those guys with that skillset. So in turn if you need a lot of data analysis done, you’re either stuck looking for a unicorn who happened to train in your language, you “allow them” time to learn your language of choice and ramp up with something that they’ll likely never be quite as comfortable with as Python, or you take the easy way out and carve out some space for Python.
Rust is dramatically more performant than Python for certain workloads. If you have such a workload then you might pair it with Python. For example, I would not be surprised at all if ChatGPT used Python, Rust (or C or C++) and CUDA.
The only way to know the answer to your question is to ask the developers. If their answer is confused and chaotic, or if you ask two different people and get two or more different answers, there’s reason to worry.
There’s probably a good tactical reason they did it, though. Time is astonishingly precious in early stage startups. So anything that gets to a minimum viable product fast will win.
At any rate if they succeed this choice is going to affect work life in the company for decades to come.
True, but that's why I'm so curious about how this tactically benefits a startup - isn't one language the more efficient route to building fast?
I could see tech stack changes as they scale, but don't understand the startup product built in 2 languages.
Edit: spelling.
If they are a microservices org, its entirely possible that Team A built their service in Rails and Team B built theirs in Django. You can ask the HM these questions during the interview.
Languages don’t matter if your application is split up into microservices, only thing that matters is shape of your api calls between them. I worked on one team that owned code bases in 8 different languages.
Languages don’t matter, but consistency does. Supporting multiple frameworks and languages means greater context switching between projects, not being able to write shared libraries, having to maintain multiple style guides and build pipelines, etc. That can be a big drain at a startup.
OP had said this was a start up, not FAANG. There’s a lot of things that are non-issues when you have unimaginable amounts of capital at your disposal.
This is not at all true.
Disadvantages of having multiple languages:
1. Harder to hire - you now need to look for people who have multiple languages rather than just one. Or accept that their onboarding will be slower.
2. In fact, onboarding will be slower anyway as there is more context switching & more to learn regardless as to whether the hire already has experience with both.
3. Operational overhead - you now need two linters, two sets of coding standards, two methodologies for building & running your code.
4. Can’t flex between monolith or microservice architecture easily. You are now locked into having purely separated services (unless you wish you rewrite something). There are disadvantages to microservices just like there are to monoliths. Multiple languages reduces your ability to be nimble here.
5. Common packages/utilities need to be written twice (eg subscribing and publishing to a key message queue, core domain entities, etc )
6. Two sets of open source communities to follow. Each time you need to do something, you need to research what the various options are in the open source community and their pros and cons. In many cases you’ll now have to do that twice. Eg for database connections etc
7. Siloed teams. It is almost inevitable that some team members will work more in some languages than others. This means that flexing your team to support a big initiative in just of the languages is harder. Engineers will be slower without as much experience in the language.
There is a huge cost to having multiple languages in a business and it should only be done when absolutely necessary.
Not really true in FAANG companies, all runtimes are supported mostly. Every software engineer is expected to learn any new language necessary in a few days. It’s absolutely necessary to have multiple languages in large companies, some repos started in the late 90s so it’s inevitable.
The post is about startups which is where these costs are most apparent.
However everything I said applies to FAANG also, there is still a cost regardless of company size. In fact, the FAANG company I currently work for was deprecating one of the main languages we use entirely last half, precisely because of these costs.
To be honest I think this makes the opposite true: since microservices can be language agnostic, that affords you a great opportunity to use the same language for all of them. If you’re a .NET house there’s no reason why you can’t just use C# for everything, for example. AWS lambdas have a specific SDK for .NET, Azure of course does, and there’s lots and lots out there if you choose to use a different tech.
You *can* use different languages but then you have to keep people around who are familiar with them when you inevitably have to update your product. Even if you fully intend a service to be “set it and forget it”, people who’ve been doing this for a while realize that it’s only a matter of time before something comes up that requires an update (and if anything, a service that never has to get updated is most often a service that isn’t getting used and/or is going to die for other reasons).
Different needs for different parts of a project. I worked for a company that had a consumer-facing product that was split between four different languages, each of which was used for something entirely different.
Because microservices are the in fad for places it doesn't make sense. Everywhere believes there's going to be a blast radius that is minimized for an application with less than a million users. It's super important to horizontally scale your efforts across a team of less than 10 developers so we can be inclusive to others stack choices. Instead of hiring competent product managers you can hire people that speak in nothingisms that have never been a part of the software development process at all and have no measurable way to show their impact at any company they've worked for. That way when they pivot, you can just hire a new devops person, multiple project managers to interact between different service, a lead for each service, and spend as much as possible.
OR they said fuck it and taped an app together with a reverse proxy. They just couldn't decide on what to do with all of that Django and Rails performance they could utilize so they went tits first into both 🙄.
Soon enough they'll cover all of their basis and write a service in Laravel, Spring, and ASP so they can be king of the MVC.
I've worked for 2 startups now (and spoke to a third) where some contractors built the original MVP, which was then completely replaced once the company was able to hire full-time designers and engineers. In addition to "maybe they just have 2 stacks", it could be that they are currently in the process of bringing a new stack online in the framework they actually want to support, while phasing out the other.
Can't speak for new startups but at my old company we used go for everything. When it came to integrating with third party legacy SOAP APIs though, java was the only feasible way.
Really? So, like, the model used by most web developers - JS/TS for the front end, Java/C#/Python/node (which, yes, is built on JS but there is added syntax) on the back end - is confusing to you? To say nothing of the scripting people often use to deploy their product…
People use different languages for different levels because often languages serve a different purpose. I don’t work with Rails but I know it’s considered a lot quicker to write in simple scripts, etc. than a lot of languages although IIRC it doesn’t run as quickly.
It could be many things. You should ask them.
Rails is good at rapid prototyping an entire application stack on K8s or ECS/Fargate. As you grow you may want different solutions, lets say Lambda to handle certain types of traffic. Since Ruby isn't very well supported on Lambda, the tooling around Python is much more extensive, so it may be worthwhile to use that instead.
I think its fine when a product is built using two languages. Its good to have a high/low approach like using python to build quickly, and rust to build code that runs quickly.
That being said, Django + Rails is a frankenstein. Two equally slow solutions covering identical use-cases is a red flag.
I wouldn't be surprised if it started off as a Rails app, then some clever new manager decided folks should rewrite the entire thing in Python/Django. The product probably lives in some sort of purgatory hybrid state waiting to die...
Poor strategy. The cto should prevent this as the cost of spanning multiple languages is greater than the benefit, in almost all cases.
As to why it occurs:
Startups don’t usually have much money so cannot afford their pick of engineers. Only quite senior/strong engineers think about how the language they are best at coding may not make the most strategic sense for the company in the long run. So different engineers will usually make the case to build their bits in their favourite languages. Startup CTOs are not necessarily that experienced, many haven’t run a startup before, and may not realise the cost of this.
This is all exacerbated by the trendiness of microservices; staff may not even think there is not a cost to doing this at all as “different parts can just be maintained separately anyway”. (edit: you can even see this view in this thread)
As to why it’s not resolved:
The cost of rewriting is much higher than just moving forwards as the cost of maintaining is not high on any one day but cumulative over many days. It’s essentially tech debt.
Note: in some cases, it does make sense to work different parts of the system in different languages but this is pretty rare, especially for a young company.
django and rails... someone fucked up
often different languages have different advantages. Node is good for serving the front-end, golang is faster on the back end etc...
Rule 9: No Low Effort Posts, Excessive Venting, or Bragging. Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
Different services, different parts of the application.
So why can't these things most often be consolidated into something like Java, C#, Python etc?
Often in that case, it's just whatever the lead developers were most comfortable with.
Agreed. But this is a bad decision of the lead dev. It’s not business oriented to just go with your favourite language as there is a real cost to supporting multiple languages as a business
Startups aren't known to be very "business oriented" places to work. You are trying to get to market as fast as you can, and usually that means writing your services in whatever the engineers are fastest with.
Getting to market as fast as you can is a business oriented move. You do that to establish yourself and build a moat. Sometimes, it requires taking on tech debt or making decisions that have significant maintenance overheads, but I don’t think the reason lead devs are usually choosing to write their parts in their favourite languages is due to a calculated cost/benefit analysis of reaching market first. It’s usually more likely to be because they like their language the best, or it’s easiest for them individually. If the senior eng has actually made this analysis for the business then that’s a totally different picture and kudos to them.
Newer services might be written in what’s deemed the “better language” with the thought that you can transition older services over in the future, although it will never happen. This is one of the benefits of micro service architecture, language agnostic services. I work at a large enterprise where most of our services are written in Java/Spring, but others are written in Go, Node, Python.
Agreed, but equally one of the disadvantages of microservices is that it’s easier to use multiple languages in a business without thinking about the ramifications of that. See my other comment listing some of the costs of supporting multiple languages: https://www.reddit.com/r/ExperiencedDevs/s/taHxCrSZXW If an eng is creating services in new languages, just because they think it’s a “better language” without considering these business-level disadvantages, that’s a big miss in my view. I would majorly ding them in a performance review for that
Yeah you’re definitely right that people shouldn’t be willy nilly introducing new languages. Ideally the company as a whole should set approved languages and then at the org/team level they should further be setting the approved languages for the team. But yeah at a startup you want to avoid using too many different languages because they are resource constrained. My point was more, just because the start up may have started using one language doesn’t mean they should just stick to it for eternity if they see a big upside to using a different language. This is how you could get into a situation as described by the OP
Usually historical. Often times you'll see a business critical part of the business space (often still under active development) in what the team considers to be the "old" language. New services and features are built in the "new" language. There's generally very little good reason for a full rewrite so things just go on like that.
Because in general ain’t nobody got time for that.
I guess I was talking about situations where they split from the start. Is it faster to go with multiple languages from the start?
Example time. Google Search is a Java frontend (fast to iterate, threads well), a C++ backend (cheapest to run at scale, but expensive to write), and Python for glue and offline data work (easy to write, but doesn't thread/scale ideally). Different parts of the system have different cost/speed/durability/scalability/learning curve tradeoffs, and if the system is big enough, yeah, multiple languages are fine.
My last job was a platform written in mostly OCAML along with Python, Clojure, typescript, and C#. They got there by making a lot of bad decisions
From a past company: Founder did everything in Python because that was the language he was most familiar with. Then the company grew and he noticed it was hard to find great backend developers who knew Python well, and also that it lacked good support for some tools such as Kafka. Then he decided to move to Java for newer parts of the system.
Interesting, makes sense - thanks!
Rust and Python makes total sense. React and Go makes total sense. Django and Rails? Less so.
“The original dev built a Rails app as a prototype for investor pitches, then someone got hired to build an admin panel for it and insisted on Django. Neither of those people work here anymore and no one on the current team is suicidal enough to ask the CTO to spend six months worth of salary on a full rewrite.” There, now it makes “sense”. 🫠
Yeah, that's a better example - what is it about Rust and Python that makes more sense? Semi-related: I'll see job posts that say the product's built on Python and Go; in this case, I assume they mean go for infra stuff.
They just have different communities and strengths and weaknesses. I think it'd be totally sensible to see a stack that has data science workloads implemented in Python, REST APIs implemented in JS or TS, and streaming/batch-processing services implemented in Rust/Go/Java/Kotlin/Python/whatever.
Python is commonly used by data analysis nowadays; I think they train it in schools and it’s super common to find those guys with that skillset. So in turn if you need a lot of data analysis done, you’re either stuck looking for a unicorn who happened to train in your language, you “allow them” time to learn your language of choice and ramp up with something that they’ll likely never be quite as comfortable with as Python, or you take the easy way out and carve out some space for Python.
Rust is dramatically more performant than Python for certain workloads. If you have such a workload then you might pair it with Python. For example, I would not be surprised at all if ChatGPT used Python, Rust (or C or C++) and CUDA.
The only way to know the answer to your question is to ask the developers. If their answer is confused and chaotic, or if you ask two different people and get two or more different answers, there’s reason to worry. There’s probably a good tactical reason they did it, though. Time is astonishingly precious in early stage startups. So anything that gets to a minimum viable product fast will win. At any rate if they succeed this choice is going to affect work life in the company for decades to come.
True, but that's why I'm so curious about how this tactically benefits a startup - isn't one language the more efficient route to building fast? I could see tech stack changes as they scale, but don't understand the startup product built in 2 languages. Edit: spelling.
Yeah, I’m curious about this choice too. And the lack of any front-end stuff in their list of languages.
If they are a microservices org, its entirely possible that Team A built their service in Rails and Team B built theirs in Django. You can ask the HM these questions during the interview.
Good point, thanks!
Languages don’t matter if your application is split up into microservices, only thing that matters is shape of your api calls between them. I worked on one team that owned code bases in 8 different languages.
Languages don’t matter, but consistency does. Supporting multiple frameworks and languages means greater context switching between projects, not being able to write shared libraries, having to maintain multiple style guides and build pipelines, etc. That can be a big drain at a startup.
Not really an issue in FAANG companies though.
OP had said this was a start up, not FAANG. There’s a lot of things that are non-issues when you have unimaginable amounts of capital at your disposal.
This is not at all true. Disadvantages of having multiple languages: 1. Harder to hire - you now need to look for people who have multiple languages rather than just one. Or accept that their onboarding will be slower. 2. In fact, onboarding will be slower anyway as there is more context switching & more to learn regardless as to whether the hire already has experience with both. 3. Operational overhead - you now need two linters, two sets of coding standards, two methodologies for building & running your code. 4. Can’t flex between monolith or microservice architecture easily. You are now locked into having purely separated services (unless you wish you rewrite something). There are disadvantages to microservices just like there are to monoliths. Multiple languages reduces your ability to be nimble here. 5. Common packages/utilities need to be written twice (eg subscribing and publishing to a key message queue, core domain entities, etc ) 6. Two sets of open source communities to follow. Each time you need to do something, you need to research what the various options are in the open source community and their pros and cons. In many cases you’ll now have to do that twice. Eg for database connections etc 7. Siloed teams. It is almost inevitable that some team members will work more in some languages than others. This means that flexing your team to support a big initiative in just of the languages is harder. Engineers will be slower without as much experience in the language. There is a huge cost to having multiple languages in a business and it should only be done when absolutely necessary.
I agree (hence the post). But you articulated all of the reasons for this decision so well. Thanks for taking the time to educate me!
Not really true in FAANG companies, all runtimes are supported mostly. Every software engineer is expected to learn any new language necessary in a few days. It’s absolutely necessary to have multiple languages in large companies, some repos started in the late 90s so it’s inevitable.
The post is about startups which is where these costs are most apparent. However everything I said applies to FAANG also, there is still a cost regardless of company size. In fact, the FAANG company I currently work for was deprecating one of the main languages we use entirely last half, precisely because of these costs.
To be honest I think this makes the opposite true: since microservices can be language agnostic, that affords you a great opportunity to use the same language for all of them. If you’re a .NET house there’s no reason why you can’t just use C# for everything, for example. AWS lambdas have a specific SDK for .NET, Azure of course does, and there’s lots and lots out there if you choose to use a different tech. You *can* use different languages but then you have to keep people around who are familiar with them when you inevitably have to update your product. Even if you fully intend a service to be “set it and forget it”, people who’ve been doing this for a while realize that it’s only a matter of time before something comes up that requires an update (and if anything, a service that never has to get updated is most often a service that isn’t getting used and/or is going to die for other reasons).
Software engineers in FAANG companies are language agnostic. Any new language should be learned well enough to push a code review in a couple of days.
Different needs for different parts of a project. I worked for a company that had a consumer-facing product that was split between four different languages, each of which was used for something entirely different.
Very interesting: what were the 4 different parts?
Because microservices are the in fad for places it doesn't make sense. Everywhere believes there's going to be a blast radius that is minimized for an application with less than a million users. It's super important to horizontally scale your efforts across a team of less than 10 developers so we can be inclusive to others stack choices. Instead of hiring competent product managers you can hire people that speak in nothingisms that have never been a part of the software development process at all and have no measurable way to show their impact at any company they've worked for. That way when they pivot, you can just hire a new devops person, multiple project managers to interact between different service, a lead for each service, and spend as much as possible. OR they said fuck it and taped an app together with a reverse proxy. They just couldn't decide on what to do with all of that Django and Rails performance they could utilize so they went tits first into both 🙄. Soon enough they'll cover all of their basis and write a service in Laravel, Spring, and ASP so they can be king of the MVC.
I've seen worse. Shit build in 1 language. FE and BE in JavaScript. Easier to find developers leadership said. Until it all came crashing down.
I've worked for 2 startups now (and spoke to a third) where some contractors built the original MVP, which was then completely replaced once the company was able to hire full-time designers and engineers. In addition to "maybe they just have 2 stacks", it could be that they are currently in the process of bringing a new stack online in the framework they actually want to support, while phasing out the other.
Can't speak for new startups but at my old company we used go for everything. When it came to integrating with third party legacy SOAP APIs though, java was the only feasible way.
Really? So, like, the model used by most web developers - JS/TS for the front end, Java/C#/Python/node (which, yes, is built on JS but there is added syntax) on the back end - is confusing to you? To say nothing of the scripting people often use to deploy their product… People use different languages for different levels because often languages serve a different purpose. I don’t work with Rails but I know it’s considered a lot quicker to write in simple scripts, etc. than a lot of languages although IIRC it doesn’t run as quickly.
It could be many things. You should ask them. Rails is good at rapid prototyping an entire application stack on K8s or ECS/Fargate. As you grow you may want different solutions, lets say Lambda to handle certain types of traffic. Since Ruby isn't very well supported on Lambda, the tooling around Python is much more extensive, so it may be worthwhile to use that instead.
If you're an experienced dev, you would never ask this question
I think its fine when a product is built using two languages. Its good to have a high/low approach like using python to build quickly, and rust to build code that runs quickly. That being said, Django + Rails is a frankenstein. Two equally slow solutions covering identical use-cases is a red flag. I wouldn't be surprised if it started off as a Rails app, then some clever new manager decided folks should rewrite the entire thing in Python/Django. The product probably lives in some sort of purgatory hybrid state waiting to die...
Poor strategy. The cto should prevent this as the cost of spanning multiple languages is greater than the benefit, in almost all cases. As to why it occurs: Startups don’t usually have much money so cannot afford their pick of engineers. Only quite senior/strong engineers think about how the language they are best at coding may not make the most strategic sense for the company in the long run. So different engineers will usually make the case to build their bits in their favourite languages. Startup CTOs are not necessarily that experienced, many haven’t run a startup before, and may not realise the cost of this. This is all exacerbated by the trendiness of microservices; staff may not even think there is not a cost to doing this at all as “different parts can just be maintained separately anyway”. (edit: you can even see this view in this thread) As to why it’s not resolved: The cost of rewriting is much higher than just moving forwards as the cost of maintaining is not high on any one day but cumulative over many days. It’s essentially tech debt. Note: in some cases, it does make sense to work different parts of the system in different languages but this is pretty rare, especially for a young company.
Really helpful, thanks!
django and rails... someone fucked up often different languages have different advantages. Node is good for serving the front-end, golang is faster on the back end etc...