Paul is my favorite example of "brain gout." I learned what gout was as "a disease kings used to get by eating foods that were too rich." Paul's writing when he was closer to reality, in the early 2000's, was a lot more insightful, because he was closer to reality. But if you've spent 21 years never having a material concern, and increasingly interacting with other rich people (or young people who idolize them), it takes a toll on your grasp of things. It's a king eating rich foods for decades.
Like his "wealth tax" piece, he's very proud of doing elementary maths that ignore a major part of the reality at the start (in that case, he was assuming that their money wasn't growing, just being taxed, which... my man). It's sad to see, and I hope anyone who gets financially successful takes the lesson to try as hard as possible to keep living like normal people do. Buy your own groceries. Cook your own meals. Keep close to the friends you made before you were rich.
> What could an application do with Flash in 2005 that we can't do with a modern web application today
Show me the JavaScript framework (or tool that exports JS) that you can give it to a middle schooler and have them make a cartoon with audio and moving images that they can draw themselves, while responding to user input. Have the exported artifact be consistent across all major operating systems and browsers.
I think it's a bit like `rails generate`, where it massively speeds up getting a CRUD webapp 0 to 1, but once you get to GitHub or Shopify size, you need a lot more than that to add a new data model.
AIs are pushing many things forward, but due to training sets and context windows, I think meaningfully adding to actually valuable apps, at least as we currently write them (the kind with many DBs/caches/message queues, services) will take a fair bit longer.
Ramp is mostly their Python monolith. They have a blog post about their use of Elixir for one service but it's really not their core stack.
Brex was a lot more all-in on Elixir, including being one of the languages "stars," but moved to a more conventional stack (IIRC Java/Drop wizard microservices with Kafka to talk between them).
Every coder has parts of programming they love, and parts they hate. Additionally, they have a mental model of what is risky, and what isn't. Languages, by their design, will make some things easier and some things harder, and so when people "love a language," they typically mean "it maps to what gives me dopamine."
A good example is mutable state: for a bunch of people, functional languages that enforce immutability has this calming effect, since you know your data isn't mutating where you can't see it. You've been burned by C++ code that's passing references as arguments, and you don't know if the list you received as an argument will be the same list after you've passed it as an argument to a different function. You don't know if you can futz with that list and not make a problem for someone somewhere else.
But for most people, they much prefer how "intuitive" it is to have mutable state, where they just change the thing in front of them to be what they need. This is especially true in the context of for loops vs. recursion: "why can't I just use a for loop and increment a counter!" A lot of Golang folks love that it explicitly rejects functional mapping primitives and "all you need is a for loop."
It's a very personal decision, and while IMO it doesn't really matter for the ultimate business success (usually companies fail because of something that's not tech-related in the least), it does shape _how_ it feels to work on a tech stack, and I'd argue, what kinds of technical problems you run into.
I'm really torn -- you and your engineers should be excited to work on your codebase. You should enter it and be like "yes, I've made good choices and this is a codebase I appreciate, and it has promise." If you have a set of storylines that make this migration appropriate, and its still early in the company that you can even do this in 3 days, then by all means, do it! And good luck. It'll never be cheaper to do it, and you are going to be "wearing" it for your company's lifetime.
But a part of me is reading this and thinking "friend... if PostHog was able to do what they're doing on the stack you're abandoning, do you think that stack is actually going to limit your scalability in any way that matters?" Like, you have the counterexample right there! Other companies are making the "technically worse" choice but making it work.
I love coding and I recognize that human beings are made of narratives, but this feels like 3 days you could have spent on customer needs or feature dev or marketing, and instead you rolled around in the code mud for a bit. It's fine to do that every now and then, and if this was a more radical jump (e.g. a BEAM language like Elixir or Gleam, or hell, even Golang, which has that preemptive scheduler + fast compiles/binary deploys + designed around a type system...) than I'd buy it more. And I'm not in your shoes so it's easy to armchair quarterback. But it smells a bit like getting in your head on technical narratives that are more fun to apply your creativity to, instead of the ones your company really needs.
Similar topic explored in videos from a friend of mine I call the "Adventure Game sommelier," because he's played so many of them and can recommend you one for precisely your needs. The first
lmaoooooo buddy "oracle" implies they know something; the people brought in to fire people at Twitter spent almost no time in determining who was good or even how the company worked, completely undermining your thesis. It was madness: people were instructed to print paper copies of their code to bring into an office, like it was 1995. Remember geohot in a Spaces saying "the main problem with Twitter is that you can't run it locally?", as if any company of that size has run that way at any point in the last decade? Additionally, the horrible communication and chaos made it even harder for performers to perform. As others have pointed out, its stock lost a ton of value, it performs worse financially, and as a product by virtually every other metric has gone to hell (outages, CSAM safety, spam, bots...).
You tell a decent story at the start, but your choice of example couldn't be worse.
It's a thing tech (and tech-adjacent) people say when they rub their temples and decide to try to work out the solution to a problem from their existing ideas and biases instead of considering what anyone else has said about it.
He won the popular vote by less than Hillary won it in 2016, _when she lost the election._ Every time he's been candidate or president, he's the least popular of either in the history we've polled popularity or approval. Many pluralities who constitute "America" (felons, especially when you consider how many people we imprison; and immigrants) who are subject to US law don't get to vote. And many institutions (DC not having senators, Puerto Rico, and the Senate generally) are barely representational and serving the function of democracy.
So I know it makes you feel intelligent and cool to say "ah, but you see: this is what they wanted," but in every other way you can measure it besides the very narrow way you're focused on, it's as untrue as it could be.
It's not a panacea, and the way people talk about it drives me crazy. There are many different modalities, with very different levels of effectiveness for any given person. CBT is awful for me, for example, and it's the most popular modality. I also did ketamine-assisted therapy and it absolutely changed my life.
There are definitely people who won't get anything from it, but the reflexive "therapy is useless" is a weird thing to perform when it's obviously helped a ton of people.
Haha I was checking the comments precisely to see if this was the case. This happens nearly everywhere a language that isn't Java, Python, Ruby, Go, PHP, or JavaScript is used. IMO it has more to do with tech labor arbitrage[1] than anything technical. Even if a system is punching above its weight, over time, the Weird Language Choice spooks people enough that they get the rewrite bug.
Bleacher Report is a funny example: it used to be a darling example of Elixir, where a migration from Ruby -> Elixir claimed a move from "150 Ruby servers to 5 (probably overprovisioned) Elixir servers."[2] But then management and politics got scared, moved it all to more conventional tech, and the whole system suffered (see this legendary post[3]).
Fred Hebert describes a similar thing happening with a migration from Erlang deployments to Go/Docker/immutable, where you lose some pretty valuable capabilities by migrating to more conventional tech.[4]
I don't see this changing anytime soon -- we came of age when it was viable to attract investment with the promise of tech innovation. These days, those are liabilities because managers misunderstood the "Use Boring Technology" post the way consultants bartardized "Agile" (taking decent advice and misunderstanding it into something wholly different and horrifying). The result is you've got companies with customers in the 1000s using k8s, calling it "simple" and "Boring," whereas that same company would be called amateur if they did things like stateful deploys on-prem.[5]
> Repeat after me, "my creative energy should be spent on my customers"
"I should save my energy, so I won't exercise."
"I should save money, so I won't deploy it towards investments."
I don't think "creativity" is a zero-sum, finite resource; I think it's possible to generate more by spending it intelligently. And he pointed out how moving towards immutable infrastructure, while more "standard," directly hurt customers (the engineering team lost deployment velocity and functionality), so it's especially weird to end your comment the way you did.
To say "immutable infrastructure is just more straightforward" so definitively, from the limited information you have, is just you stating your biases. The stateful system he describes the company moving away from may also have been pretty "straightforward" and "boring," just with different fixed points. Beauty in the eye of the beholder and all that.
Sure! I find most responses (like the other one on this comment) talk about the social as it relates to the technical (what I call "atmosphere" in [this blog post][1]). I'll avoid that, since a) I think it's kind of obvious, and b) somewhat overblown. If Python has 20 CSV libraries and Elixir has 2, but they work, are you really worse off? I'll instead try to talk about "soil" and "surface" issues: the runtime, and assuming engineers know the languages already and what they allow for expressivity. Here we go!
---
Most of the BEAM isn't well-suited for trends in today's immutable architecture world (Docker deploys on something like Kubernetes or ECS). Bootup time on the VM can be long compared to running a Go or OCaml binary, or some Python applications (I find larger Python apps tend to spend a ton of time loading modules). Compile times aren't as fast as Go, so if a fresh deploy requires downloading modules and compile-from-scratch, that'll be longer than other stacks. Now, if you use stateful deploys and hot-code reloading, it's not so bad, but incorporating that involves a bit more risk and specific expertise that most companies don't want to roll into. Basically, the opposite of this article https://ferd.ca/a-pipeline-made-of-airbags.html
Macros are neat but they can really mess up your compile times, and they don't compose well (e.g. ExConstructor and typed_struct and Ecto Schemas all operate on Elixir Structs, but you can't use all three)
If your problem is CPU-bound, there are much better choices: C++, Rust, C. Python has a million libraries that use great FFI so you'll be fine using that too. Ditto memory-bound: there are better languages for this.
This is also not borne from direct experience, but: my understanding is the JVM has a lot more knobs to tune GC. The BEAM GC is IMO amazing, and did the right thing from the beginning to prevent stop-the-world pauses, but if you care about other metrics (good list in this article https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...) you're probably better off with a JVM language.
While the BEAM is great at distribution, "distributed Erlang" (using the VM's features instead of what most companies do, and ad-hoc it with containers and infra) makes assumptions that you can't break, like default k-clustering (one node must be connected to all other nodes). This means you can distribute to some number of nodes, but it's hard to use Distributed Erlang for hundreds or thousands of nodes.
Deployment can be mixed, depending on what you want. BEAM Releases are nice but the lack some of the niceness of direct binaries. Libraries can work around this (like Burrito https://github.com/burrito-elixir/burrito).
If you like static types, Dialyzer is the worst of the "bolted-on" type checkers. mypy/pyright/pyre, Sorbet, Typescript are all way better, since Dialyzer only does "success typing," and gives way worse messages.
Author here; I have a lot of other posts in my personal blog about this, but: the current trends in VC-backed tech companies are about minimizing risk and following fashion, rather than any technical merit or experimentation. Said another way: if an Elixir company dies, it's "damn, shouldn't have picked Elixir!" If a Python company dies, it's "startups are hard," with no investigation behind what Python cost you.
Elixir has real technical downsides too, but honestly they never come up when someone advocates against it. And this is fine, building companies and engineering culture is a social game at the end of the day.
Paul is my favorite example of "brain gout." I learned what gout was as "a disease kings used to get by eating foods that were too rich." Paul's writing when he was closer to reality, in the early 2000's, was a lot more insightful, because he was closer to reality. But if you've spent 21 years never having a material concern, and increasingly interacting with other rich people (or young people who idolize them), it takes a toll on your grasp of things. It's a king eating rich foods for decades.
Like his "wealth tax" piece, he's very proud of doing elementary maths that ignore a major part of the reality at the start (in that case, he was assuming that their money wasn't growing, just being taxed, which... my man). It's sad to see, and I hope anyone who gets financially successful takes the lesson to try as hard as possible to keep living like normal people do. Buy your own groceries. Cook your own meals. Keep close to the friends you made before you were rich.