Not really, you can do great things without them. I've been summarizing hundreds of documents. I've added MCP servers to my internal business tools (Elixir apps) and can chat with the Nous Hermes agent over Telegram about pending orders, inventory level, historical product prices, etc., without having to click/dick around with a web UI.
Sure, it cannot replace SOTA models for agentic coding, except for small, well-scoped refactorings. But even a model like ministral-3:8b or qwen3.5:9b is a boon for so many smaller use cases!
The post explains why I don't want to use disksup. You have to start an extra application (os_mon) and configure disksup to update the starts more frequently than the default of every 30 minutes.
Do we really need to do all that instead of the equivalent of a df?
Agree about the C code, which is why the latest version (on GitHub, the HEAD, not yet released in Hex.pm) is now using Rust and Rustler.
I've been working on a kinda-sequel to my first technical book, Northwind Elixir Traders. This one (Phoenix Product Codex) is about developing and deploying a production-grade REST API with Elixir and Phoenix.
I'm working on my second self-published technical book related to Elixir. The first one has been a surprising success, but since it was about learning to use Ecto on the basis of an old pedagogical toy database (and tiny dataset), the new book is about the development of a production-grade REST API with Elixir and Phoenix.
I find that many books out there are focused on documenting the "happy path" for rather small and simplistic applications without boundary conditions or business thinking behind them.
So, I thought (as with the first books) that it mix things up by also documenting the business context, the questions, decisions, and the decision-making process itself, as well as all the gotchas and "side-quests", rather than showing "here's how you do it" and then expecting the reader to suddenly make the jump from tutorial hell to actually software engineering.
Overall, it's enormously enjoyable, and I hope it goes as far as the first book, and possibly even farther.
Sure, it cannot replace SOTA models for agentic coding, except for small, well-scoped refactorings. But even a model like ministral-3:8b or qwen3.5:9b is a boon for so many smaller use cases!