Your thoughts on advancing the Elixir ecosystem

community
speculation
ecosystem

#21

Not sure what you mean exactly as this already exists and is written by the same guy @JakeBecker (who does amazing work) that Elixir LS is. However, I agree with your sentiment and I would say that editor/debugging support for the language would be my number one priority for improving ecosystem.

Elixir works great from the command line with basic text editor features and some better ones from the language server stuff. However, the language server and other editor support features could really use as much support as we can get. That’s going to drive adoption a lot and make development easier for more people. Editor integration is essential these days.


#22

I use the VSCode extension and love it (thanks @JakeBecker). My comment is about supporting additional editors and environments (e.g. vim, emacs, Atom) with an easy on-ramp for those new to Elixir. If VS Code is the de facto way of doing it and that’s what the community encourages for newcomers, that’s fine too.

I would hope that the VS Code extension and other extensions could be formally adopted/sponsored by the community or a sponsoring org (similar to Phoenix with DockYard or Elixir as a whole with Plataformatec). I would also hope for extensions supporting deeper debugability.

Broadly speaking, any editor integrations that help newcomers get clean, simple, but powerful access to the BEAM’s best features and tooling would be a killer app for the ecosystem. Dialyxer, typespecs, and autocompletion are a great start.


#23

Although it is slightly off-topic, I wonder about this as well. I think that @josevalim is probably referring to the implicitness and potentially the huge scope-creep that Device has, but I might be completely missing the mark here.
There do exist a couple of user-management libraries that strive to fullfil the same goal; Coherence comes to mind for instance.


My thoughts on advancing the ecosystem currently are probably mostly that there still is a treasure trove of Erlang-libraries (and even built-in functionality!) that is not or only partially exposed in an idiomatic Elixir way (in some cases, improving the documentation of the existing Erlang stuff might be enough).

One of the things that recently somewhat burned me and my colleagues, for instance, is that Mnesia is basically its whole own entity in the Erlang/Elixir ecosystem, and that it might maybe best be described as a ‘do it yourself’ database: It has many hooks to customize what it does if certain situations occur, but does very little of this for you out of the box. A good (meaning feature-complete and idiomatic; e.g. using Structs rather than Records) Mnesia-wrapper would be much appreciated, especially if it can reduce the amount of configuration to make a sensible ‘works for most cases’ system. Basically, Mnesia feels more like a framework to create a distributed database on, rather than a distributed database itself.


#24

One thing I hope the core team works on is the deployment story.

We have distillery, but the UX is not up to par with Elixir’s S-Tier developer UX. Imagine if these very smart guys focus on the deployment story. There’s a lot of things that could be done to improve, even in the documentation.

I would contribute to the docs at least, but I’m too new with Distillery.


What about more robust tests that not only test using the values you set but also bombard your functions with random data. I know something like this already exists, but again it’s all about dev UX. It could be made easier to use for the novice Elixir dev. By default make Elixir one of the most iron-clad languages to write in.


#25

The second thing is being worked on already, and might be included in Elixir itself at some point once it is finalized :slight_smile:


#26

There is already active work going on to improve the deployment story. As far as I know, it lands first in Distillery and then in Elixir core.


#27

Fwiw, I can report that Emacs + elixir-mode + alchemist works beautifully.


#28

For me, having a set of “libraries” with shared interfaces for small features, written with “idiomatic” Elixir is very important.

Especially, for those who’re migrating existing apps into Elixir, having these “building blocks” is more important than having “full featured” libraries for new projects. It provides good reusable building blocks, and gives good idea on what’s the idiomatic way to use/write Elixir code.

JSON is good example. jason is taking of poison; they have small well defined interface (e.g. encode/2) so pretty swappable (e.g. phoenix, absinthe, ecto…) Also pretty good behaviors (e.g. no automatic encode of random struct - jason), and consistent interface (e.g. ok/error tuple and ! methods)

HTTP area is still evolving - tesla is my choice of wrapper, but what about adapter? Also I’m waiting for xhttp… See HTTP client libraries and wrappers for details.

I’ve worked with XML and :public_key - and they need better documentation.