The sane middle ground is libraries that give you nicer ergonomics around SQL without hiding it (like Golangs sqlx https://github.com/jmoiron/sqlx). Engineers should be writing SQL, period.
The sane middle ground is libraries that give you nicer ergonomics around SQL without hiding it (like Golangs sqlx https://github.com/jmoiron/sqlx). Engineers should be writing SQL, period.
Elixir promotes a "do it all in one place" model—concurrency, distribution, fault tolerance—which can be powerful, but when you try to shoehorn that into a world built around ephemeral containers and orchestration, it starts to crack. The abstractions don’t always translate cleanly.
This opinion comes from experience: we’ve been migrating a fairly complex Elixir codebase to Go. It’s a language our team knows well and scales reliably in modern infra. At the end of the day, don’t get too attached to any language. Choose what aligns with your team’s strengths and your production reality.
Sure, it can be frustrating that they don’t adapt to a user’s personal style. But for those of us who haven’t fully developed that stylistic sense (which is common among non-native speakers), it’s still a huge leap forward.
What happens if someone's retirement coincides with a market crash? Younger investors have time on their side for recovery, but as retirement approaches, blindly following market-based strategies without carefully considering your required rate of return could be problematic. Age-appropriate risk management becomes increasingly important as your investment horizon shortens.
Framing this as a hard-scaling problem (tudum seems mostly static, please cmiiw if thats not the case) feels like pure resume-driven engineering. Makes me wonder: what stage was this system at that they felt the need to build this?
[1] https://hollow.how/raw-hollow-sigmod.pdf