Hacker News Reader

Comment by shijie | Hacker News Reader

It seems that every ShowHN that features an Elixir project is well-polished, has a sensical API, and has friendly, solid documentation. Is this a function of the nature of the language, the community, or a mix of both?

View on HN

I use Elixir as my primary language in my day job and I'd say it's a mix of the community and the ecosystem. Most modules seem to have great documentation, so if you're producing one you also put in the effort. However, ExDoc (the documentation module) is also really solid with loads of great features, including the ability to run your examples as unit tests.

That said, it's not all that uncommon to be searching for something like an implementation of a SaaS API and find a totally undocumented module. It's not the norm by any stretch though.

Absolutely both.

But...the issue is packaging/distributing a CLI built with Elixir. Comparatively to building a CLI in something like Rust, there is a lot of overhead that comes with a VM-based language and framework. Especially if you want to target multiple OS and processor architectures (or distributions). Not to say that it is impossible, just maybe not as simple. It is one thing to run Mix tasks, or access the Owl API from REPL, it is another to run an Owl-based app on macOS, Linux and Windows and get it there.

Well, `mix release` (https://hexdocs.pm/mix/Mix.Tasks.Release.html) exists to address this very issue.

It still has limitations (the biggest one is the requirement for the os&architecture to match between the builder and the deployment target) — but the result is a standalone binary which not only embeds the VM and preloads the app's bytecode, but even "trims" the stdlib to only ship the required functions.

Right, so the moral of the story centers on the target user of the CLI tool. If you're building something for the Elixir community - game on I suppose, though there is still the complexity of build-env per OS/arch.

I wonder where WASM/container enters the discussion.

> Firefly compiles Elixir applications faster and more efficiently than the BEAM can, and introduces WASI targeting to run applications in resource-constrained environments.

https://dockyard.com/blog/2022/09/01/dockyard-r-d-firefly-op...

Containers are already solved, its trivial to build and boot a mix release - but whether that's appropriate for a CLI tool depends on the complexity of the tool I guess, but not too far from flatpaks etc no?

Burrito is supposed to close the gap even further, though I've never used it.

Undeniably it's not going to be as convenient, but the divide isn't what it used to be. BEAM apps can be compiled to a binary, and as long as that binary was compiled for the platform, that should be good enough.

I'm doubtful I'll see it used much outside the BEAM community, but then again it's been a "successful despite a lack of mass usage" community for awhile.

The Elixir community has good internal (and official!) tooling around libraries and documentation. I would say it's a positive feedback loop. The nice community resources attract good programmers, good programmers make nice community resources.

Or it's the way upvotes work for the most part?

Both. Best of Ruby (community, docs, pleasant to use) and Erlang (functional, value oriented, BEAM).

Reply on news.ycombinator.com