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.
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.