I agree that one of the best ways to improve Elixir is to improve Erlang/OTP. There are many areas of OTP in particular that are unpolished/in need of some love. One area that is still not-as-good-as-it-could-be is the lack of Common Test integration with Elixir. Not that Common Test makes any of this easy to do, of course (it’s not designed very well to play nicely with anything other than Erlang/OTP; for example _SUITE.erl is literally hard-coded in a few places).
In general, I think there are people within the Erlang community who wouldn’t mind moving into the Elixir ecosystem, but have a hard time because they have to give up some of the tooling and frameworks they’re accustomed to using to do their work. Common Test is one of those areas where I don’t feel like we have an equivalent available in Elixir.
I’d throw out there additional support for Elixir LS and editor integrations. I recently explored using Elixir/Erlang debugger support and, while the tools are nifty on their own, it would be amazing if it could be integrated into something like Visual Studio Code. If it was turnkey to setup sane defaults for an Elixir plugin for VS Code, Atom, Sublime, etc. I think that would be helpful for a lot of new developers:
Auto-detect and offer to insert type specs?
Better autocompletion and language snippets
Debugger integration (I suspect this is both rewarding and very complex)
Exposing powerful existing tools like :observer or :debugger (how many newcomers know about those tools out of the box?)
I’m interested! I’ve tried to read up on various systems of type inference but I really struggle to understand the theory. If you have the beginnings of something written in Elixir, I’d be very interested in seeing the code.
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.
I’d be interested in reading more about “Devise was a mistake” (reasoning, lessons learned, etc.). Is there anything out there on this? I was unable to find anything (my searches just turn up user issues with errors/validations).
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.
Is it intended?
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.