> There is only one last major feature planned for upcoming Elixir versions, which is the addition of mix release to Elixir itself, streamlining the experience provided by packages like distillery.
Aside from having native support for releases, which would be killer, I was really struck by the idea that the language will be basically "finished". You rarely see that in software these days, but I think there's a lot to be said for trying to get to that point.
I think Jose and team have done a great job with this, especially judiciously limiting what features get added to the core language.
This is also an area where Elixir is benefiting greatly from the maturity and ongoing development of the Erlang VM. Elixir is, in a sense, simply a text based interface on top of the BEAM.
Being that the language is user-extensible, where do you see it going in the future? Will "finished" mean feature-complete, or will we see anything worth incorporating into the language?
This isn't directed specifically at you, but to anyone who might have ideas.
The Elixir team took a deliberate step to limit the features built into the language itself, and prefer non-core solutions developed as external packages instead.
For example, they recently scrapped plans on building property testing into the language core.
Which is something I find very refreshing, TBH, having worked with the JS ecosystem, I somehow find this approach to be rather relieving for some reason.
A great point. Since it's built on top of the erlang VM, and it has all the cool tools built into the eralng VM and OTP, Elixir has been able to rapidly go from a prototype language to a production grade environment to work in extremely quickly.
But also to basically decide that the language ergonomics and syntax is "finished" this quickly is truly impressive. The addition of macros, combined with the huge focus on developer experience, I think allows the core team to say "its feature complete" while not worrying about any particular missing features in the language (you can probably just implement it yourself anyway)
This is also pretty huge from an ecosystem point of view. It means you can have books, video series, tutorials etc. targeting this final feature set which is very nice. Not that it's a huge issue but it's cool to buy a programming book knowing that it'll contain a language that will not change for a long time. It's not a huge deal, I own the PragProg book (I don't recall if it's >=1.6 or if there was a version before) but now I know I'll very likely get the 1.8-version when it is released.
But I have a question. I took an online Erlang class and I actually ended up really liking the Erlang syntax once I got used to it. To me now, Erlang is now far more readable than Elixir.
I understand Elixir is designed for the Rubyist, but I'm curious how is the experience of others who have looked at both Erlang and Elixir.
There are differences beyond syntax. Macros, utf8, variable rebinding, string interpolation and probably more. Also tooling is quite different.
Obvious bias, but I feel that these Elixir additions are going to be welcomed / expected by most programmers. Macros stand out as being complicated / overwhelming, but you can largely just accept the magic and learn them at your own pace (and they end up being rather powerful).
I didn't like Elixir's syntax at first and I like Erlang's syntax, but Elixir is a lot more than "Erlang in rubyesque syntax" it's a brand.
Elixir is a well-thought ecosystem designed by professional developers, it includes tooling(mix), documentation(hexdocs) and most important of all: an excellent community and community support. Plataformatec often posts about design decisions and best practices and it doesn't take long till you hit a forum post or github issue or SO question answered by Jose Valim, Elixir's creator or Chris McCord, responsible for Phoenix.
You can very easily use Erlang code in Elixir projects, so I think it's worth taking a look.
I did play around with Erlang a few time. I really love the comma and period. It really nest and group the function patterns together.
For Elixir you just have to put them near each other. The function are enclose in a do/end block. And you put those similar pattern function next to each other. I believe you can move those pattern function around.
Other than that I can't recall much else. Prolog syntax is foreign but I'll admit I can see myself learning Erlang pretty fast since the language isn't "big" compare to Java or Scala. Like wise Elixir is a small language too with added macro (I don't recall Erlang got this) feature. Elixir also have better tooling baked in (mix/hex, doc, lint, etc...).
Also the Erlang community sucks. This is my personal experience but I vividly recall attending a meetup. The group meetup have a discussion about Erlang's adoption and how to get better adoption. I told them Ruby got popular because RoR other wise people would have chose Python and call it a day. Erlang should really have a killer framework like a web framework. Everybody thought it was ridiculous.
And you know what? Elixir came along and so did Phoenix. Phoenix may not be the only thing that got Elixir popular, Elixir got toolings from the get go. Jose and those people are from the industry they know what was needed. They came from Ruby.
> Elixir have better syntax because it's familiar.
Which syntax is "better" depends on how you measure. I'm a big fan of Erlang's "minimalistic" syntax. It means I might have to write a bit more code, but it also means that the code, once written, is very explicit.
> Like wise Elixir is a small language too with added macro (I don't recall Erlang got this) feature.
Well, Erlang does have simple macros (-define(MACRO(Var1, Var2), {some_expr, #{ var1 => Var1, var2 => Var2 }}).) but they are nowhere near as powerful as Elixir's system. There is merl (http://erlang.org/doc/man/merl.html) which allows for something quite similar, in particular if it's combined with parse transforms. I haven't used it and haven't seen usage in the wild, though.
> Elixir also have better tooling baked in (mix/hex, doc, lint, etc...).
That I give you, while rebar3 is already a huge step forward compared to what we had before, mix's out-of-the-box feature-set is really nice.
> Also the Erlang community sucks. This is my personal experience but I vividly recall attending a meetup. The group meetup have a discussion about Erlang's adoption and how to get better adoption. I told them Ruby got popular because RoR other wise people would have chose Python and call it a day. Erlang should really have a killer framework like a web framework. Everybody thought it was ridiculous.
This is a bit harsh. You can't derive "community sucks" from "the ones at this meetup didn't share my opinion". I don't share it either. I think the main thing holding Erlang back is the current out-of-the-box tooling (rebar3 is not included in the OTP distribution) and its general performance.
* Switched all the strings to waaay more efficient binary string format (with true utf8) - in erlang you have charlist, which consumes more memory, slower and less-handy binaries (and need to remember to pass around right one)
* Made standard library consistent and logical. This also affects 3rd party libraries, they have reasons to follow conventions.
* Hyped pipeline operator ("|>") by mere existence basically enforced correct order of function params
20 comments
[ 2.9 ms ] story [ 48.1 ms ] thread> There is only one last major feature planned for upcoming Elixir versions, which is the addition of mix release to Elixir itself, streamlining the experience provided by packages like distillery.
Aside from having native support for releases, which would be killer, I was really struck by the idea that the language will be basically "finished". You rarely see that in software these days, but I think there's a lot to be said for trying to get to that point.
This is also an area where Elixir is benefiting greatly from the maturity and ongoing development of the Erlang VM. Elixir is, in a sense, simply a text based interface on top of the BEAM.
This isn't directed specifically at you, but to anyone who might have ideas.
For example, they recently scrapped plans on building property testing into the language core.
Which is something I find very refreshing, TBH, having worked with the JS ecosystem, I somehow find this approach to be rather relieving for some reason.
But also to basically decide that the language ergonomics and syntax is "finished" this quickly is truly impressive. The addition of macros, combined with the huge focus on developer experience, I think allows the core team to say "its feature complete" while not worrying about any particular missing features in the language (you can probably just implement it yourself anyway)
José Valim was the one who added "Add {continue, Term} and handle_continue/2 to gen_server" - https://github.com/erlang/otp/commit/69e009e3e1ad899a4609ff3...
José's contributions are at https://github.com/erlang/otp/commits?author=josevalim and Michał Muskała's at https://github.com/erlang/otp/commits?author=michalmuskala - there may be other Elixir devs in https://github.com/erlang/otp/graphs/contributors. (I even got in a tiny optimization myself once: https://github.com/erlang/otp/commit/07b0f4315b079cce7aeef7b...)
But I have a question. I took an online Erlang class and I actually ended up really liking the Erlang syntax once I got used to it. To me now, Erlang is now far more readable than Elixir.
I understand Elixir is designed for the Rubyist, but I'm curious how is the experience of others who have looked at both Erlang and Elixir.
Obvious bias, but I feel that these Elixir additions are going to be welcomed / expected by most programmers. Macros stand out as being complicated / overwhelming, but you can largely just accept the magic and learn them at your own pace (and they end up being rather powerful).
Elixir is a well-thought ecosystem designed by professional developers, it includes tooling(mix), documentation(hexdocs) and most important of all: an excellent community and community support. Plataformatec often posts about design decisions and best practices and it doesn't take long till you hit a forum post or github issue or SO question answered by Jose Valim, Elixir's creator or Chris McCord, responsible for Phoenix.
You can very easily use Erlang code in Elixir projects, so I think it's worth taking a look.
I did play around with Erlang a few time. I really love the comma and period. It really nest and group the function patterns together.
For Elixir you just have to put them near each other. The function are enclose in a do/end block. And you put those similar pattern function next to each other. I believe you can move those pattern function around.
Other than that I can't recall much else. Prolog syntax is foreign but I'll admit I can see myself learning Erlang pretty fast since the language isn't "big" compare to Java or Scala. Like wise Elixir is a small language too with added macro (I don't recall Erlang got this) feature. Elixir also have better tooling baked in (mix/hex, doc, lint, etc...).
Also the Erlang community sucks. This is my personal experience but I vividly recall attending a meetup. The group meetup have a discussion about Erlang's adoption and how to get better adoption. I told them Ruby got popular because RoR other wise people would have chose Python and call it a day. Erlang should really have a killer framework like a web framework. Everybody thought it was ridiculous.
And you know what? Elixir came along and so did Phoenix. Phoenix may not be the only thing that got Elixir popular, Elixir got toolings from the get go. Jose and those people are from the industry they know what was needed. They came from Ruby.
Which syntax is "better" depends on how you measure. I'm a big fan of Erlang's "minimalistic" syntax. It means I might have to write a bit more code, but it also means that the code, once written, is very explicit.
> Like wise Elixir is a small language too with added macro (I don't recall Erlang got this) feature.
Well, Erlang does have simple macros (-define(MACRO(Var1, Var2), {some_expr, #{ var1 => Var1, var2 => Var2 }}).) but they are nowhere near as powerful as Elixir's system. There is merl (http://erlang.org/doc/man/merl.html) which allows for something quite similar, in particular if it's combined with parse transforms. I haven't used it and haven't seen usage in the wild, though.
> Elixir also have better tooling baked in (mix/hex, doc, lint, etc...).
That I give you, while rebar3 is already a huge step forward compared to what we had before, mix's out-of-the-box feature-set is really nice.
> Also the Erlang community sucks. This is my personal experience but I vividly recall attending a meetup. The group meetup have a discussion about Erlang's adoption and how to get better adoption. I told them Ruby got popular because RoR other wise people would have chose Python and call it a day. Erlang should really have a killer framework like a web framework. Everybody thought it was ridiculous.
This is a bit harsh. You can't derive "community sucks" from "the ones at this meetup didn't share my opinion". I don't share it either. I think the main thing holding Erlang back is the current out-of-the-box tooling (rebar3 is not included in the OTP distribution) and its general performance.
Also, Devin Torres, author of Poolboy, wrote https://devinus.io/the-excitement-of-elixir/ and https://devinus.io/elixir-its-not-about-syntax/
* Switched all the strings to waaay more efficient binary string format (with true utf8) - in erlang you have charlist, which consumes more memory, slower and less-handy binaries (and need to remember to pass around right one)
* Made standard library consistent and logical. This also affects 3rd party libraries, they have reasons to follow conventions.
* Hyped pipeline operator ("|>") by mere existence basically enforced correct order of function params