[blandflakes]

> I pick tools by the problem, not loyalty.

Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though).

What did you move onto for those next things you started building?

[lowenbjer]

I know that feeling. Just because a tool is good doesn't mean you enjoy using it. I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me. Today it's mostly TypeScript, Go, and Lua.

[blandflakes]

Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.

[lowenbjer]

Ha, same. I wrote a VOD transcoding orchestrator in Elixir that triggered libav transcodes and custom packaging code in Python. Loved the syntax, and in particular the pattern matching in function headers. It was so clean for recursive branching that I ended up favoring recursion over conditionals and loops everywhere. Whether that was overuse or just good taste is subjective. We did hit a real scaling problem with the BEAM though. Distributed Erlang uses a full mesh, every node connects to every other node. When we got close to 50 nodes the inter-node communication overhead was eating a significant chunk of our CPU. Adding more nodes started giving diminishing returns because the mesh traffic grew faster than the compute we gained. Interesting constraint that I haven't hit in any other runtime since.