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.
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.
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.
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.
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)
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?
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.
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.
