It's fair to switch away from a technology your team doesn't know well and doesn't want to learn. Maybe that should have been the title.
It's a favorite pet peeve of mine too that people often try to rationalize either their lack of experience with a platform or a broken architecture as a problem with the language in question. Though sometimes it's done because it helps paper over internal politics (e.g. lack of clout to be perceived to criticize past decisions) by blaming something external like a language or framework to justify architectural changes, so it's not always that these teams don't know what the actual problem is.
(Twitter's transition from Rails back in the day, always springs to mind as my goto example of this, because as much as the transition might well have been appropriate, as much as they claimed otherwise, the real problem was never Rails, but the fact they'd written a monolith instead of building a system where the message delivery was designed to be sharded; no language or framework choice could have saved them from a rewrite)
Well yeah, because you avoid me like I am an obsessive ex-girlfriend. :D
You're the last person I expected to reply! Very pleasant surprise.
> It's a favorite pet peeve of mine too that people often try to rationalize either their lack of experience with a platform or a broken architecture as a problem with the language in question.
I am the same. I get it, I understand the mechanisms leading to that but I still get irritated sometimes that people pretend their motivation is something more. I am quite OK with admitting: "No I don't want to learn Rust right now; I use Go and OCaml when I need fast(ish) native code and I am quite OK with Elixir doing everything else". I don't pretend that Rust is bad; I know it's very good but I am openly admitting that currently I am working on deepening my skills and not widening them.
> Though sometimes it's done because it helps paper over internal politics
Yep, doesn't help when the CEO and the CTO are old friends back from their Perl and bash and Slackware days and they don't want any newer technologies. I also get that motivation and maybe I'll become that conservative one day myself but in the meantime it's really weird to pretend that we had everything we ever needed in the older languages / OSes / frameworks. We definitely didn't. And things definitely improved hugely in the last several years. (We might need a new OS though, Linux feels kind of stuck.)
As for monoliths, it's a 50/50, we know it. There are many projects (I'd say most) that are served quite well as a monolith. And most projects never grow that big that they need the horizontal scaling anyway. But yeah, let's all pretend we're Google, it's kind of how it goes these days.
Hah. I'm equally slow to reply to most e-mails :-P
> and they don't want any newer technologies.
I don't think it's necessarily that often that it is that they don't want any newer technologies per se, but that it's easy to avoid technologies you don't personally see the benefits of, even if that is because you don't know them.
But I also see the reverse relatively regularly: People who push the new hotness because they want to play with them rather than for any real business reason, but who try to pretend otherwise. It's fine, if you want to try to rewrite something in a new language because you want to see if it brings benefits, cool, justify it as research.
I'd focus on the endless pretence of many people in HN and Reddit; they really love to downplay the clearly documented and unique advantages various pieces of tech have: Erlang's OTP and BEAM's preemptive scheduling and soft-real-time guarantees, Go's goroutines and channel primitives (which I dislike but I admit they are often useful), OCaml's amazing typing system that can and does prevent a ton of bugs by the mere virtue of your program compiling, Racket's ability to make a fully functioning DSL for practically every business need you might have, etc. ad infinitum.
What often rubs me the wrong way is the really strong maintenance of the illusion that "we can do what Erlang OTP does in C++" (yes you can, but do you have 20 years to reinvent that particular wheel?), or "Go can have as strong a typing as OCaml and Haskell" (not when most Go devs reach for the interface{} escape hatch every day, and not when you don't have algebraic data types with variants and maybes), or "C can be an extremely safe language if you know what you're doing" (lol don't even get me started on that one!).
People in the tech communities should know better -- that's my argument. People cannot just pretend Python is God's gospel while we all know they just don't want to learn anything else but Python.
This is a serious problem in most technical discussions which very quickly get hijacked away from the objective technical merits and into the murky territory of beliefs and prejudice.
Pretty sad. We the techies should be better than that.
Back in the day not many organizations survived on Ruby/Rails and many of them moved over to Erlang or Java just to deal with resource issues.
https://blog.chef.io/2013/02/15/the-making-of-erchef-the-che...
Not sure what is up with Ruby nowadays. JRuby was always an interesting option though.
It's really not productive when even minor version bumps of Rails back in the days of v3.2 all the way to v4.2 were a nightmare to execute, often impossible. You were stuck with a ton of quirks for years, likely all the way to your next job.
Rails was productive, but only compared to a ton of other lame half-frameworks at the time. Nowadays it isn't special by any measure.
---
So TL;DR: it doesn't really matter what Ruby or Rails are up to these days. Many people have moved on, the free lunch is over and the hype is gone. Which is a good thing: hype more often than not kills technology and doesn't enable it.
Do some languages handle this differently?
Isnt this based on how the code was written rather than a language natively sharding?
I used "system" and "program" there specifically. One of the key things erlang "forces".
Languages do matter.
When they were rewriting anyways, it's very much possibly that moving off Rails was the right choice anyway, but that was incidental to the far bigger problem of their broken architecture.
There are however, frameworks that enforce some level of "shardability". The Datastore (now Firestore) in AppEngine/Firebase comes to mind, in that your data is shared all over the place (the details are hidden from you), and you can't write un-indexed queries that don't scale well. The Datastore has some limitations that definitely seem awkward if you're coming from a relational DB world (e.g. no joins, limits on the kinds of inequality queries you can do, etc.), but these limitations are there specifically so Datastore can guarantee performant distributed queries.
Erlang encourages shardable solutions from OTP concepts being so strongly integrated into Erlang.
I didn't see anywhere in the article blaming Erlang as a language - it just said Python was better for mixpanel.
From the article: "After two years of iteration, the code has become difficult to maintain. No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems. So, we decided to rewrite it in Python, the de-facto language at Mixpanel."
The impression I got from the article was that they only wanted similar performance (hence intern), and that they got a suitable result.
I think that recently a similar service GetSentry changed their ingress code from Python to rust presumably for performance and security (although I might be utterly incorrect, I can't remember why I think they are using rust).