6 ms·

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 th

by shijie 4y ago

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?

ctvo 4y ago
Or it's the way upvotes work for the most part?
bluehatbrit 4y ago
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.
hazn 4y ago
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.
kitplummer 4y ago
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.
- kirushik 4y ago
  Well, `mix release` (https://hexdocs.pm/mix/Mix.Tasks.Release.html 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.
  - kitplummer 4y ago
    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.
    - bongobingo1 4y ago
      > 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-optimizes-your-elixir-compilation 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?
  - throwawaymaths 4y ago
    Burrito is supposed to close the gap even further, though I've never used it.
- quaunaut 4y ago
  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.
amalgamated_inc 4y ago
Both. Best of Ruby (community, docs, pleasant to use) and Erlang (functional, value oriented, BEAM).

by shijie 4y ago

ctvo 4y ago

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

bluehatbrit 4y ago

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.

hazn 4y ago

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.

kitplummer 4y ago

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.

kirushik 4y ago
Well, `mix release` (https://hexdocs.pm/mix/Mix.Tasks.Release.html 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.
- kitplummer 4y ago
  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.
  - bongobingo1 4y ago
    > 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-optimizes-your-elixir-compilation 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?
- throwawaymaths 4y ago
  Burrito is supposed to close the gap even further, though I've never used it.
quaunaut 4y ago
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.

amalgamated_inc 4y ago

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