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.

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

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.

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.

https://www.youtube.com/watch?v=xOPiSYUSrQ0

and the second, which is one of my favorite videos of all time (if you only watch one, I'd pick this one)

https://www.youtube.com/watch?v=tMVl5U3SlS0

I think he mentions Old Man Murray's piece in the second!

You tell a decent story at the start, but your choice of example couldn't be worse.

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.

[1]: https://morepablo.com/2023/12/therapy-and-wellness.html

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]

At least we'll always have WhatsApp.

[1]: https://www.baldurbjarnason.com/2024/react-electron-llms-lab... [2]: https://web.archive.org/web/20170204160005/http://www.techwo... [3]: https://www.reddit.com/r/erlang/comments/18f3kl3/comment/kct... [4]: https://ferd.ca/a-pipeline-made-of-airbags.html [5]: https://morepablo.com/2023/05/where-have-all-the-hackers-gon...

[1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...

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

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

   [1]: https://morepablo.com/2023/05/where-have-all-the-hackers-gone.html

I go into it a bit here https://morepablo.com/2023/05/where-have-all-the-hackers-gon... and here https://morepablo.com/2023/06/creatives-industries.html

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.

You might be interested in a "making of" post I wrote on my personal blog, going into the intentions and crafting of this https://morepablo.com/2023/03/technical-storytelling-making-...

I like this framing, thanks for it. Typically, when something is suboptimal, there's one argument that says "go back to before we [X]-ed" and another that says "no, we need to [X] smarter."

Illustrating this, [on another post of mine, I discuss how Alex Russell effectively says "SPAs/React are terrible" and Laurie Voss has a rebuttal of "no, we need better frameworks, smarter frameworks!"][1] Another example is when FB was in trouble of Cambridge Analytica stuff, it seemed like the answer to Bad Facebook was always More Facebook.

I'll look over it again, but I didn't get a giant message from Kellan's posts of "we need to be smarter moving forward," more about "how we got here." And I certainly don't remember how we're supposed to be "smarter moving forward."

But I also don't think Kellan and I disagree too hard on anything actually concrete. From [the footnote][2]: I think we both want technical decision-making to be grounded in business reality. I think a lot of scared leaders took the "Boring Technology" slogan to mean "something that doesn't scare me," which is IMO in practice was variations of "we won't innovate" / "we'll operate like money will always be free" / "we will use the most popular things I see in the blogosphere."

---

Said it in another comment, repeating here: I'm regretting that "rockstars" is in the title . It was meant to support the idea that tech was more of a "creatives" industry (because the organic use of "rockstars" to mean "great talent" is indicative of this); but I think my "break playbook and embrace creativity" is being read as "let's go back to rockstars/ninjas! Genius hackers who don't sleep and just HACKHACKHACK!!!!" which is not how I feel. What I'd like to go back to is taking some technical risk when there's a good justification for it, even if it's not what Uber did for their problems.

---

> That is to say, you can't point at the general market downturn to say that deploying a CRUD app is not a solved problem.

Well, many developers who were around in the Heroku era think it's harder to deploy a simple CRUD app than it felt like it was then :-p

But I'm also not talking about CRUD apps, I was talking about building a cost-efficient technology org for a better business. That's why the examples I used (deployment pipelines that costs tons of money and entire teams of developers to build and run) tended to be expensive. Many in the industry called these things "solved," but mostly ran giant bills. Your initial comment said "you could throw money at it," and I never thought that was the way, but especially now that money isn't free.

---

> And this gets to my main point (which I think the author of the 3-part series would agree with): returning to the "rockstar" era will absolutely not bring software companies back to the crazy valuations and money. The "rockstar" era was the result and not the cause of the crazy valuations of the past.

Again (and it's on me that this isn't more clear): I'm not saying "RETVRN TO ROCKSTAR," it's more "I think we should move the slider a little back to the "creatives" era." But while I don't know if it will create crazy valuations, I think it _can_ lead to happier developers, doing better work, and probably more profitable businesses, even if their market caps are lower.

  [1]: https://morepablo.com/2023/02/little-piece-on-the-great-divide-of-javascript.html
  [2]: https://morepablo.com/2023/06/creatives-industries.html#footnote1