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.


#29

You need to get into mix console in order to do that. Any idea on how to do it, not by entering the iex?


#30

Well considering IEX ‘is’ the terminal interface into the system, how would you get a terminal interface without the iex terminal interface? ^.^

You could setup an SSH directly into it! Erlang comes with an SSH Server library. :slight_smile:


#31

What I’m talking about is, in Rails debugger can be placed anywhere, when we run the server, and the interpreter reach the debugger, it will show us the debugger interface.

Elixir (and Phoenix) is pretty different. I know that Elixir has different runtime, so debugging might be different as well. Let say I put require IEx and IEx.pry in a context file (in Phoenix), the context function is surely called by an action in the controller. When I hit that action (it actually hit the function in the context), the debugger won’t show up. Is it intended?


#32

Isn’t that basically what IEx.pry() does? Adding it to code causes the pry debugger interface to pop up in iex. Without IEX the BEAM doesn’t have a normal input/output setup so another interface would have to be made from scratch, which with the BEAM’s multi-core nature would be very… interestingly difficult to work well, so it’s always best just to use the built in shells. :slight_smile:

Yep, unlike Ruby the BEAM is fully multi-core and parallel so doing a shell without a synchronization and overriding point is rather amazingly difficult (even Elixir’s shell is built on Erlang’s due to the difficulty to get it right, that’s why a couple of the limitations of the IEx shell exist).

EDIT: You could indeed make such an interface, you should build something on top of erlang’s shell if you do though, but it will still be a surprisingly amazing amount of work to do.