srpablo

Disco Stu meme

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.

Yeah, Flash was never replaced

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.

lmao Google him

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

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!

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 made my life way, way better

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

My favorite thing said about Ev Williams: with Twitter then Medium, he managed to kill blogging _twice._

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]

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

I often joke that every startup job post Series A is you playing Viscera Cleanup Detail[1] for the "heroes" of the pre-PMF stage

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

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.

Here's a video I liked that's both more informative and less sensationalist on frozen treats like this https://www.youtube.com/watch?v=itbtOepN5Bw

I happen to agree with you, but I'll note one _very_ celebrated CEO loved tweeting-while-inebriated so much he bought Twitter

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.

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

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.

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.

Thanks for the kind words! Another comment mentions it, but last I checked Elixir is still powering the Authorization service.

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 some ways, I think the 3-part series and your article are basically saying the opposite. The 3-part series acknowledges the market conditions and overabundance in the past, and says that in order to get the same results, we need to be smarter moving forward. Whereas your post is (in general) saying that it use to be really good in the past when we were treated like rockstars, we should return to that.

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

If you want to be as profitable as Google or Facebook, you probably do need some rockstars, but you also need to be developing a technology or business that produces tremendous amounts of value.

Definitely agree on this.

You can’t just hire rockstars to work on something low margin or without significant demand and expect because they’re amazing engineers that you’ll make a lot of money.

This isn't what I'm trying to argue though — I think when you reach for the ceiling instead of avoid a floor, you're more likely to find those tremendous business value opportunities. Consider what Google shipped/built under Schmidt, "20% time," "Don't be evil," and "we're a different kind of company" vs… the last 10 years?

I'm not saying "being wild and creative makes a bad business good," I'm saying "embracing some narratives of a creative industry may increase output and be more cost-effective, even if playing "outside the playbook of the 0% era" is scary."

---

On another note, I'm regretting that "rockstars" is in the title . It was meant to support the idea that tech was more of a "creatives" industry (and the organic use of that to mean "great talent" is a symptom of that); 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 don't care about HR!!!!" which is… not how I feel haha.

Hi! Author here :)

It really comes down to what you prioritize. Do you prioritize the output and the value added? Or do you prioritize making your engineers feel like "rockstars"? If you don't care about your end product, then yeah sure let your engineers break prod using untested technologies.

First, the post is about sentiment. It's a response to a piece called "Software and its Discontents," about how people feel. So it's going to focus on that.

But I also think the narrative of people working on a project does impact its success. I don't think you pick EITHER "make developers feel like they're doing great, innovative work" OR "do you care about the end product for customers"; the key is to find a way to achieve both, because they feed off each other and are related.

It's as if I asked "do you want company growth, or customer happiness?" Try both!

The reason playbooks have sprung up, is because 99% of use-cases for businesses are for the most part "solved." We're not in the era of renting colos and manually setting up MySQL anymore (which the author advocates for in order to return to "creatives," btw). We have managed solutions that you can throw money at.

I disagree they're solved! Again, this is in response to a 3-part series basically saying "everything is expensive and everyone is miserable and fewer businesses are succeeding." From a profitability perspective, when was the last Google or Facebook made?

And good riddance to all that too. I don't need to work with any more software engineers who think it's okay to be a massive dick to everyone just because they can implement a CRUD app.

To be 1000% clear: I also hate(d) the machismo/showboating we got from the rockstar/ninjas era. I'm a former theatre artist and I'm mostly about embracing people and creativity.

Author here.

Well, sure, but to the contrary: DC has had a much harder time imitating Marvel's success, even with great IP. Universal tried to create the "Dark Universe." And even Marvel is having trouble cranking out the hits with the middling success of Ant-Man Quantumania, Thor: Love and Thunder, and Wakanda Forever.

I suspect making these things more streamlined and more of a flat cultural paste through the Disney Machine is a part of the lower outcomes.

Thanks for the feedback. I updated the language a bit to better reflect how that whole interaction went down, which was a playful chat between two seasoned devs with ~12 companies between them. I also removed the language that was being perceived as judgemental.

Hi, I'm the author, and LOOOOOL Thanks for the laugh.

Hi! Thanks for posting this, it and the replies pointed out an error. I've since corrected the article.

Hey, thanks for letting me know! I'll correct the article

Hi! Have we met?

Elixir has been great for our Authorization server. I really believe in the BEAM for high-uptime cases, and love a lot about Ecto's design as an ORM. That said, I only felt comfortable bringing Elixir to Ramp because I'd already built ~3 Pheonix projects before joining, and had a decade on other Erlang projects. I make a light reference to it in a few places in the article, but I think introducing Weird Tech is very, very easy to mess up and most people would be better off not doing it.

I lead with that in my other article that made it to HN, on strategies for learning exotic tech https://morepablo.com/2022/09/so-you-re-using-a-weird-langua...

More on BEAM at Ramp and why I like it https://engineering.ramp.com/elixir-at-ramp

Me comparing/opining Ecto and SQLAlchemy, the two ORMs at Ramp https://www.youtube.com/watch?v=5Ep9CDXUHNU

It's been running Authorizations for 4 years and had remarkable good mileage.