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.