Erlang developer Mariano Guerra has put out a community survey to gather some insights into what we all want from the BEAM community. If you want to also fill it in here, here’s the link:
Are all the questions in the middle supposed to refer to only Erlang? Or do they refer to all OTP languages?
In this section
How important have each of these aspects of Erlang been to you and your projects? I answered as benefits of Elixir through Erlang.
What has been most frustrating or has prevented you from using Erlang more than you do now? I answered more as to why I did not opt for Erlang (/went for Elixir instead) or what I feel needs improving for the whole BEAM eco-system (such as runtime performance - not because it’s not good enough for me but because I know some people get het up on it and improvements here would make beam languages more appealing to others).
It does seem to be aimed more at Erlangers (and Erlang) so I was careful to try not to offend, and in
Any advise on how we can make Erlang more welcoming and easy to use? I just said perhaps it would be worth moving in a direction towards being more like (or embracing) the other modern BEAM languages.
I would like to see more type safety on the beam, or maybe a faster dialyzer
I just said perhaps it would be worth moving in a direction
towards being more like (or embracing) the other modern BEAM languages.
Moving towards elixir? The other ones surely haven’t got any traction
and in terms of adoption I think elixir is the only one that has
received lots of attention.
This is a $10,000 question.
What parts of the other modern BEAM languages (elixir) should erlang look at?
I was being diplomatic (I ticked Elixir as the only BEAM language I use so I’d guess they’d assume I was referring to it). Do any of the others actually class as ‘modern’? I don’t know enough about them.
I think they would need another survey on that “why did you choose Elixir over Erlang?”
Maybe this thread could help…
(Edit: Looking at that thread now, there seems to be a lot more positives about Elixir that could be added :-))
Well, looking at the post it is more what some people subjectively think is nicer about elixir. I don’t think erlang can learn much from what is on that page.
Syntax, obviously is very subjective and I am in camp erlang where I find the syntax much cleaner, less verbose and more explicit and is a better fit for the BEAM. What could erlang learn and adopt from elixir syntax? Not much as I don’t think there is lots of wiggle-room here. The key is to make the other features so strong that you don’t disregard the language straight away because of its unfamiliar syntax.
Macros, as the double-edged sword it is, may be something to look at. Elixir’s macros has perhaps made some libraries easier to use (ecto, I think) and erlang with its parse_transform’s and merl is way behind. Perhaps they could get some traction by adding macros and developing some libraries that make clever use of them.
Documentation and Tooling. Erlang has always had good documentation but a bit of a problem with discoverability. It also perhaps doesn’t look as modern and because developers are quite shallow and vain this seems to be important to us. Tooling is great with rebar3 and thanks to hex.pm it got a good package manager too!
Perhaps what they can learn from elixir is having a coherent, holistic approach to the entire eco-system.
Other than that. To get people to look at erlang again you’d need some head turning new feature. I am thinking:
- A nice static type system
- Performance on at least the same level as go
I think that would attract a few people back to erlang.
What I think would be cool is a much better getting started experience. Think something like a static binary (not too big) you can download and it opens up the entire erlang world for you.
- You can see the observer on one side, a code editor on the other and a repl down the bottom.
- If you spawn a process it pops up in the observer. You can click on it to bring the code up in the editor.
- Edit the code, send a message and see how it behaves.
- You click “add OTP application” and it pops up in the observer. You write your app init code and fire it up. Another click to add a supervisor.
- Drag and drop, or copy behaviours between applications while visualising it in the observer.
That is a project I would like to see. I am a command-like guy, like I only use a light-weight browser for the internet otherwise I spend all my time in text mode but something like that would probably change my mind:) (as long as the editor has vim binding:))
That is exactly me response
I think Elixir is the future of Erlang in many ways, and so I hope that this survey can help the Erlang community understand our needs as well as those who write straight Erlang since the ecosystems have huge overlap in terms of technology. The Elixir devs are helping push OTP and BEAM development, so it is good imho for that communication to flow between the BEAM “sub” communities as well. That they asked in the first question what languages we use on the BEAM tells me this is the idea the author has in mind as well.
there is at least one language being developed on the BEAM that is attempting to offer that.
Performance is such a loaded term … worth a whole thread on its own
Personally, I think Elixir is bringing people back to Erlang by getting them on the BEAM and using OTP. I don’t think it REALLY matters that people write with the Erlang syntax directly. I see it as all part of the same ecosystem, with Elixir being probably the most approachable and attractive, and that’s a great development. Means not having to modernize Erlang itself, which would breaking all the existing code out there, require huge resources reworking OTP, etc. It’s a really beautiful solution, at least to me
I think that’s as true of Elixir. Would love to see what you suggest for BEAM applications in general. These surveys can be a great place to gather this kind of “want” and “need” information in a central place for all of us on the BEAM, including those of us writing mostly or even exclusively in Elixir.
My hope is that just as Elixir has embraced Erlang/OTP, that the Erlang community will continue to do the same with Elixir and perhaps see it as the most approachable way to the BEAM and all the goodness in OTP, and all without having to disrupt the existing Erlang codebases. Those who prefer to continue writing in Erlang can and should absolutely do so, but the cross-pollination via the shared BEAM and OTP (and Cowboy, and …) pieces is just fantastic.
It’s already happened to some extent … I moved to Elixir from Erlang due to sitting in a presentation given by one of the original Erlang developers (also of Erlang: The Movie fame ) who said that if people want to learn Erlang, just skip straight to Elixir instead.
Yes, but I doubt it will get any major traction unless it gets commercial backing. Perhaps as a good experimental playground for what can be done with static typing on the BEAM. Wadler also took a whole year looking at a type system for erlang but came out disappointed so that means it is no easy feat.
Performance is such a loaded term … worth a whole thread on its own
Yes, but you know what I am getting at. Performance on the BEAM as general programming language is not great. There are NIFs and ports of course but they each have their own trade-offs.
I think the getting started experience of both erlang and elixir is OK and similar to what other languages provide but you still need to find the right way to install erlang on your particular platform, then install elixir, and then perhaps some more thing and then get started
I have something much more ambitious in mind Think more like the smalltalk experience but for erlang.
I’m sure it has been tried before but if I can go to the a home-page and download a 32Mb (or something smallish) binary which starts up an integrated IDE, Observer, Repl, documentation discover, package manager browser.
Something where you don’t really write code in files but rather attached to processes. Data structures, serializers. You declaratively just describe how various things should be handled and the system makes it so. I think BEAM would be a nice platform for something like that. Would it work? 98% no but I like the idea behind it seeing how repetitive lots of development are in all languages and that the wheel gets reinvented all the time.
I think elixir is doing good work in driving the BEAM forward but in terms of eco-system I feel it is more one-way. It is straight-forward to use erlang libraries in elixir but quite a challange the other way around, especially if you want to use your current erlang build system.
Macros doesn’t help either. I also have a feeling that elixir is diverging more and more from erlang and from using erlang libraries and that more gets rewritten in elixir instead of improving the erlang code. This together with that is hard to use elixir from erlang means they are sort of growing apart. If that is good or bad I don’t know
Personally I much prefer erlang’s simplicity and explicitness and I think the elixir’s system is quite a bit more dynamic and I feel the same type of “dynamic errors” I had programming python comes back when I use elixir and not erlang.
I use elixir for phoenix and ecto which captures a market which hasn’t been erlang’s strong points. I love that I can use the BEAM for serious web development and elixir is a really good language but for any other projects than web I would be inclined to use erlang over elixir.
Via a very rough analogy, I see the Erlang/Elixir relationship as similar to the C/C++ relationship: people will continue choosing both of them for years to come for a variety of reasons and both can be good choices depending on the circumstances and requirements. So I can absolutely empathize with your point there.
As for the linkage between the ecosystems, I do agree that the Erlang -> Elixir path for code usage is easier than the other way around but don’t feel it’s a huge issue … and meanwhile lots of Erlang libraries/applications continue to be used by Elixir and I don’t think that will ever really change (for a reasonable definition of “ever”), nor does it need to.
Build systems for erlang have been such a circus. It is better with rebar3, no question, and erlang.mk has its bright points as well. But mix really outshines the both imo, and I find myself using it to bring together Erlang libraries into applications because of how outstanding it is. I know it is dreaming, but I think it would be fantastic if mix would become the defacto build system for BEAM code regardless of the langauge it is written in. I just don’t see the benefit of rebar or erlang.mk at this point, and it would make a lot of these decisions so much easier.
Agreed on the first part, it has been a circus But I prefer rebar3 to mix. It works better with erlang/OTP with everything from library applications to releases. I don’t know if it is mix fault but the way the compile-time vs run-time configuration and the way some libraries use it complicates things.
Yes, one build system for them all would be great regardless which one it is (except if it is rebar2 of course ;))
I think this would quickly resolve itself if mix was adopted by the broader Erlang community.
The fact that a package manager was discussed for so long in the Erlang community but only came about when hex.pm arrived with Elixir and mix speaks to the possibilities for Erlang in going that route …
Should I laugh or cry? Maybe both … using rebar2 left me feeling the same way autohell did with C/C++ applications before things like CMake were real alternatives. Ugh. So glad those years are behind us.
Agreed about releases. It is something we will eventually tackle as part of Elixir but not quite now. Having that built-in in rebar3 is certainly a plus, in Elixir bringing in distillery is the way to go.
However, regarding configuration, the compile-time and run-time discussion should not affect your Erlang code at all since the compile-time aspect is simply not there for Erlang. That said, if there is something that makes configuring Erlang from Mix still awkward, we would love to hear it and fix it.
I’m in the same camp.
But still, I’m of the opinion to keep the ‘language’ lean and clean. What Erlang should add is a better macro system that is not as painful as
parse_transform's. Then you could add new ‘syntax’ via libraries a lot more easily. That is how a language should evolve, let the language itself be definable via libraries and eventually accept the best and most used into the Standard Library set.
Oh wait, we have lfe… ^.^
The problem with parse transforms is they are really low level. They expose the underlying AST with all the horrors of it. If it could be wrapped to be a unified style, say a 3-tuple, and then add a built-in (there are parse transforms for this to be used in making parse transforms) set of quoting/unquoting/splicing, and a larger set of built-in helpers (there is a library for this too though) and most importantly, made the system fully aware of parse transforms better (instead of having to decorate per-file or per project), it would be a lot nicer.
Though, it is hard to beat lfe.
Technically you could recreate Elixir in lfe in all its power, and then more.
Hmm, I’ve not checked, I wonder if lfe has read-macro support, then you could even duplicate elixir’s syntax in lfe for those people that like it…
The biggest thing Elixir has by far though is Hex and the ecosystem around it. Phoenix and Ecto and all that are so very nice, and yes they could have been made on lfe (even more succinctly and powerful) but they are on elixir so that is the big elixir draw.
Exactly this! Mix is a very nice build tool as well, I’m actually torn on whether I prefer mix or rebar better. Mix is certainly more readable since it takes advantage of macro’s (but an lfe’d rebar script could do the same…).
Well technically you could build this into lfe as a library not at all hard either. ^.^
Erlang I think is fine without a type system. I’m not a fan of specs being a separate line from the function definition (I prefer combined) and it is good enough for something like erlang, which is the ‘low level interface’ on the beam really.
I would love a static type system overall though, and not for dialyzer-like checking, but rather for all the abilities it gives to you, especially in being able to do static dispatch based on the type instead of needing to use comparatively costly things like protocols or map dispatch, that would be awesome!
A lot of the ‘slowness’ of the BEAM comes from a lack of typing, everything is dynamic. If the system did add full low-level static typing (perhaps with a
dynamic type as a fallback to allow current code to work as-is) then a lot more optimizations can be done, effectively for free.
However, the speed could be helped a lot be a good tracing JIT, however that is an unholy amount of work and would really only speed up things like math, not really the raw IO that the BEAM is used for. Though that would let you write/use fewer NIF’s.
You could make such a thing. Get on it? ^.^
alpaca is pretty cool, but has some odd design decisions that I’m not a fan of that will hamper its ability to statically dispatch ‘smarter’ among others.
I actually don’t see the point. If Elixir made the industry standard choice of piping to the ‘end’ argument then it would have ‘Just Worked’ with most erlang libraries without needing to write needless wrappers around them. I’ve still been wondering if that was on purpose to prevent such interoperability. There are a lot of nice functions in the Elixir libs that were added as well that would have been nicer for everyone if they were in the Erlang libraries instead.
I have to compile asn1 files fairly often, that is done via the erlang compiler, yet the mix erlang compiler does not accept asn1 files as output to generate erl output, so I have a shell function that does it for me when I need to. There are other formats the erlang compiler accepts as well that Hex does not and I have to keep doing them manually when rebar does it ‘for free’ essentially.
I think that’s a great way to look at it.
Elixir has definitely brought the BEAM into the mainstream Imo (even going by forum stats, we’re not just comparable to Rust and Go but our activity actually exceeds theirs).
However you look at it you can not beat a lisp for macros. The simple consistent syntax (some people say no syntax) makes it easy to work with.
No, currently lfe does not have read-macro support though I am thinking about it.
Please please please please please please? ^.^
In my elixir lisp (just a simple sandbox) it has read-macro support, handled in the parser (using my spirit parser) directly. I do too much wrapping of stuff for better errors (I keep line number information and more) so it is not quite an easy api, but eh it works. I’ve kept meaning to rewrite it (when I get time, way busy lately) to just be a normal pure lisp that can optionally compile to elixir ast, though that would completely lose all line/column error reporting.