> IEx also has been improved to show the documentation for Erlang modules directly from your Elixir terminal.
This is a really nice change for those of us who straddle both languages. I've done a fair bit of work with both ets and the crypto module and having to jump into and out of firefox felt at odds with the rest of the development experience.
Reading through the details of this release, I have to say this sort of functional backend/compiler/performance, etc style releases make the whole product as a whole better in the long run. This tick/tock approach to releases is what every software project should strive for.
Too many consumer focused products become obsessively new-feature driven development [1], often to have new things to announce, or to appease the loudest whining customers/industry critics of the day (operating systems like MacOS, Windows, and mobile platforms are the classic examples).
Much like in the design world where saying "no" often and pushing back against fanciness is critical, the same in software for pushing towards general structural improvement iterations is key to making good software.
[1] Ignoring of course the bug-fixing-driven development cycle that many projects get trapped in.
IIRC some time ago José said Elixir is stable, and there's no v2.0 coming any time soon. There will be updates, but it's just polishing and refining a stable product.
The language might be still be over-hyped, but the language implementation itself has reached the plateau of productivity. Which is great, I know of some language ecosystems where true productivity is never, ever reached.
Pretty stoked for this. I started learning Elixir a few months ago [0] and it's been a great balance of fun + practical. Way easier to get up and running compared some other FP languages I've dabbled with in the past :P
Also shameless plug: we're currently working on an open source messaging product called Papercups [1] if anyone is looking for an Elixir project to hack on!
Question from someone who's never tried Erlang/Elixir but is interested.
If you're starting a greenfield project in 2020, is there any reason to use baseline Erlang instead of Elixir? I get the impression that Elixir is a strict improvement (besides legacy compatibility). But this is a very very uninformed impression.
Try both. It may be because I've been doing Erlang so long but I still prefer it and its tools (like rebar3 and Common Test). I find the syntax more consistent, less verbose and the lack of Elixir style macros to mean less confusing third party libraries.
But I do think Elixir has its strength in web applications. The macros make Phoenix and Ecto much simpler for building full web applications and if I were building a full fledged interactive web application I'd reach for those.
So mainly personal preference, you may find Elixir preferable, but all that to simply say it is not a "strict improvement".
Oh, and one none personal preference reason: it is nice to do libraries that don't benefit from being written in Elixir (like postgrex and jason get a lot of performance out of using macros so there isn't an argument to write those in Erlang) and aren't specific to Elixir (like a Plug adapter) in Erlang so they are more easily usable across BEAM languages, a list that continues to grow.
If you're interested in Erlang/Elixir, you might want to watch this video: https://www.youtube.com/watch?v=JvBT4XBdoUE (GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić)
It shows off the power of the BEAM VM -- and kind of makes you stand back and go "whoa.. how do they do that?"
I work in Elixir most of the time but can read and write Erlang reasonably well, here's my two cents.
Elixir's syntax was inspired by ruby and so if you've used ruby or look at ruby code and think, "yea, I get what's going on here" then you will likely find working with Elixir's syntax preferable to Erlang. Erlang's syntax was based off of Prolog and so it will be less familiar, unless you have done a bunch of Prolog programming.
Elixir layers on a bunch of things that are very nice to have at a language level, the ability to rebind names is probably the one that most impacts code. In Erlang you can't rebind a variable, so Erlang code ends up either using lots of very small functions of having variables like `n` `n2` `n3`. It's not that you can't write good, clean, easy to reason about code in Erlang, but if you are coming from a language with mutability and variable rebinding, it's a bit of a culture shock. I find that Elixir hits a nice medium ground to allow you to wrap your head around immutable data structures, functional programming, actor model, OTP without ALSO having to climb the hills of unfamiliar syntax and some limitations (like variable rebinding) that aren't strictly necessary.
From a tooling standpoint, I find Elixir to be a bit more pleasant than Erlang. Mix (build tool) is great, ExUnit (unit testing) is great, ExDocs (docs generation) is great, Hex (package management) is great. The Elixir community has somehow stayed pretty unified when it comes to tools and for the most part they work really well.
From an interoperability standpoint, you really don't leave anything behind choosing to use Elixir over Erlang. Erlang dependencies work just fine, and the interop is so easy, here, I'll give you an example.
Want to use an Erlang module directly from your Elixir code, here's an example of how to use the timer module.
:timer.seconds(1)
That's it, that's the interop, you don't have to import anything weird, you don't have to fence off your code, you don't have to juggle types from Elixir types into Erlang types and back again. Want your Erlang interop to look more like elixir, two lines of code.
alias :timer, as: Timer
Timer.seconds(1)
Overall the Erlang and Elixir communities are friends (and Gleam, LFE, and all the other BEAM Languages). It's a very positive community all working to build great functionality on top of the really cool piece of tech that is the BEAM VM.
I used Erlang in some university courses, and once wrote a simple crud app in Elixir/Phoenix, so my experience is somewhat limited.
Erlang's syntax is unusual, but after grasping the concepts I always found the language logical and easy to understand. On the other hand, I haven't been able to get comfortable with Elixir. It's a significantly larger language, which comes with higher complexity (but also lets you write code at a higher level of abstraction). I often found myself only half-understanding the code I was writing (and I always make an effort to fully understand what I'm doing).
And personally I find the Elixir syntax to be among the most confusing and inconsistent (especially when compared to Erlang).
Nevertheless, if I was making something web related, I would definitely go for Elixir (because of Phoenix). If I was making something lower-level, I would probably consider both options.
I think it's mostly a matter of taste which syntax you prefer. Where Elixir has the most advantage, in my opinion, is Mix, the language's build tool / project config / task runner. You use the command line tool to compile your project, run your tests, and any other user-defined task you'd like. And you use the Mix module to define your project's dependencies, environments, and build targets in Elixir code. It's a really nice all-in-one Swiss Army knife compared to the cobbled-together build processes from disparate tools found in other languages.
- simpler syntax: there’s no Erlang program that you can’t read after getting comfortable with the language. Seriously. Go read OTP source or Ryaks, everything is extremely clear and explicit. To me, easier to read also means less bugs.
- It’s so different from other languages that, IMO, it makes it easier to “think in Erlang”; the syntax fits so well the semantics that I find it easier to think in terms of processes, patterns and the ocasional recursion when switching from other language (most Erlangers are polyglots IME).
*Edit: Reliable network services (Erlangs sweet spot) are much easier to write and maintain when written in a clear and explicit way. I love macros (consider myself a lisper actually) but I think they’re the wrong tool when writing bullet proof network servers (macros are basically everywhere in Elixir).
Personally I see no reason to start a new project with Erlang unless you really enjoy its syntax (perhaps for someone who has a solid background in Prolog?).
With Elixir you get everything in Erlang plus a lot of extremely powerful libraries/frameworks (e.g. Ecto and Phoenix), macros, a friendlier syntax etc.
It's not an improvement if you prefer prolog syntax (for the record, I personally don't). Everyone likes to say that syntax doesn't matter, but it can affect your time-to-POC, example comprehension, debugability, especially if you're starting a greenfield project.
Otherwise, I would say stick with elixir. It is more opinionated about how to do tests, how to organize your code, how to do documentation, how to deploy, how to use libraries, all of which will make your life way easier, especially for a greenfield project.
I have been using Erlang since 2008, and started using Elixir in 2014.
I much prefer the Elixir syntax. It files off the rough parts of the Erlang syntax, e.g. needing to keep track of commas, periods and semicolons at the ends of lines.
The most important thing Elixir adds, though, is lisp-style macros, which makes everything else easier.
I started to learn Elixir and Phoenix awhile ago. I liked it but stopped due to (i) there's no job opportunities near me for Elixir and I wanted to the learning/projects I do on my own to help me in interviews; and (ii) it's not a strongly typed language which I have come to learn is my favored type of language
Elixir/Phoenix is my hobby. I build personal projects on it.
I was able to find a few jobs, but not a ton (this was a couple years ago). The jobs that are out there all wanted experience but obviously that's hard to do with a new platform. I got an interview with one company that I thought understood that I only had a few months experience as a hobbyist (which means I'll be doing a lot of Googling even for common APIs) but they rejected me. At this point my experience with professional Elixir has not been positive.
I love the language but I'll probably just stay a hobbyist, at least until things change.
Phoenix is a fine web framework. But with the shared-nothing approach of designing webapps, they tend to be pretty simple to both isolate and make concurrent regardless of your stack. I think BEAM languages are much more interesting for backends where a shared-nothing approach isn't an acceptable solution, and I feel like that's where its power and uniqueness over other languages really shines.
I had this issue too, even before the pandemic. In fact back when I was looking even if there were Elixir job postings they often strongly preferred a Ruby/Rails background on top of that, which I didn't have.
I just decided it's one of my hobby languages. If a job comes out of it in the future, that's awesome.
You are experiencing the same global pandemic the rest of us are, right? Remote work and all that? (It’s honestly not for everyone. I prefer some physical facetime myself or I... “get disconnected”)
> not a strongly-typed language
While this guarantees elimination of a class of bug, pattern matching plus guards cover most of the potential bug surfaces there IMHO. I know the language creators have been considering some directions to go, there
Most interesting take-aways from benchmarks are some cases where RabbitMQ processes 30-50% more messages per second. And where a native Erlang JSON library beat NIF C library in some specific tests. The PR link covers this info.
All I could only ask for today is just a better ide support.
I don't like vscode; even though the plugin for intellij has improved, there is still a lot to be desired
I'm a bit biased as someone who's already used to nvim, but the coc-elixir support is fantastic. Takes a bit of configuration but once you've got the language server set up it's better than any IDE.
The IDE type tooling is getting better all the time thanks to Elixir-LS. There was a 0.6 release a couple of days ago with a ton of improvements [0]. Better auto-completion triggers and Ecto completion come to mind as huge quality of life improvements.
I'm stuck between learning Clojure and Elixir (for a backend that will power a web app). The one thing pulling me towards Clojure is ClojureScript, and the fact that I'd be able to write a frontend and backend with the same syntax.
ianleeclark|5 years ago
This is a really nice change for those of us who straddle both languages. I've done a fair bit of work with both ets and the crypto module and having to jump into and out of firefox felt at odds with the rest of the development experience.
andy_ppp|5 years ago
dmix|5 years ago
Too many consumer focused products become obsessively new-feature driven development [1], often to have new things to announce, or to appease the loudest whining customers/industry critics of the day (operating systems like MacOS, Windows, and mobile platforms are the classic examples).
Much like in the design world where saying "no" often and pushing back against fanciness is critical, the same in software for pushing towards general structural improvement iterations is key to making good software.
[1] Ignoring of course the bug-fixing-driven development cycle that many projects get trapped in.
1_player|5 years ago
The language might be still be over-hyped, but the language implementation itself has reached the plateau of productivity. Which is great, I know of some language ecosystems where true productivity is never, ever reached.
risyachka|5 years ago
For years now at best you can see 1-2 minor features a year. Mostly its just some design tweaks.
areichert|5 years ago
Also shameless plug: we're currently working on an open source messaging product called Papercups [1] if anyone is looking for an Elixir project to hack on!
[0] https://www.papercups.io/blog/elixir-noob
[1] https://github.com/papercups-io/papercups
princevegeta89|5 years ago
tres|5 years ago
Dancing around runtime vs compile time configuration seemed like it was one of the "harder" parts of dropping into Elixir.
edit: grammar
strzibny|5 years ago
dcolkitt|5 years ago
If you're starting a greenfield project in 2020, is there any reason to use baseline Erlang instead of Elixir? I get the impression that Elixir is a strict improvement (besides legacy compatibility). But this is a very very uninformed impression.
kungfooguru|5 years ago
But I do think Elixir has its strength in web applications. The macros make Phoenix and Ecto much simpler for building full web applications and if I were building a full fledged interactive web application I'd reach for those.
So mainly personal preference, you may find Elixir preferable, but all that to simply say it is not a "strict improvement".
Oh, and one none personal preference reason: it is nice to do libraries that don't benefit from being written in Elixir (like postgrex and jason get a lot of performance out of using macros so there isn't an argument to write those in Erlang) and aren't specific to Elixir (like a Plug adapter) in Erlang so they are more easily usable across BEAM languages, a list that continues to grow.
randito|5 years ago
It shows off the power of the BEAM VM -- and kind of makes you stand back and go "whoa.. how do they do that?"
ihumanable|5 years ago
Elixir's syntax was inspired by ruby and so if you've used ruby or look at ruby code and think, "yea, I get what's going on here" then you will likely find working with Elixir's syntax preferable to Erlang. Erlang's syntax was based off of Prolog and so it will be less familiar, unless you have done a bunch of Prolog programming.
Elixir layers on a bunch of things that are very nice to have at a language level, the ability to rebind names is probably the one that most impacts code. In Erlang you can't rebind a variable, so Erlang code ends up either using lots of very small functions of having variables like `n` `n2` `n3`. It's not that you can't write good, clean, easy to reason about code in Erlang, but if you are coming from a language with mutability and variable rebinding, it's a bit of a culture shock. I find that Elixir hits a nice medium ground to allow you to wrap your head around immutable data structures, functional programming, actor model, OTP without ALSO having to climb the hills of unfamiliar syntax and some limitations (like variable rebinding) that aren't strictly necessary.
From a tooling standpoint, I find Elixir to be a bit more pleasant than Erlang. Mix (build tool) is great, ExUnit (unit testing) is great, ExDocs (docs generation) is great, Hex (package management) is great. The Elixir community has somehow stayed pretty unified when it comes to tools and for the most part they work really well.
From an interoperability standpoint, you really don't leave anything behind choosing to use Elixir over Erlang. Erlang dependencies work just fine, and the interop is so easy, here, I'll give you an example.
Want to use an Erlang module directly from your Elixir code, here's an example of how to use the timer module.
That's it, that's the interop, you don't have to import anything weird, you don't have to fence off your code, you don't have to juggle types from Elixir types into Erlang types and back again. Want your Erlang interop to look more like elixir, two lines of code. Overall the Erlang and Elixir communities are friends (and Gleam, LFE, and all the other BEAM Languages). It's a very positive community all working to build great functionality on top of the really cool piece of tech that is the BEAM VM.nemetroid|5 years ago
Erlang's syntax is unusual, but after grasping the concepts I always found the language logical and easy to understand. On the other hand, I haven't been able to get comfortable with Elixir. It's a significantly larger language, which comes with higher complexity (but also lets you write code at a higher level of abstraction). I often found myself only half-understanding the code I was writing (and I always make an effort to fully understand what I'm doing).
And personally I find the Elixir syntax to be among the most confusing and inconsistent (especially when compared to Erlang).
Nevertheless, if I was making something web related, I would definitely go for Elixir (because of Phoenix). If I was making something lower-level, I would probably consider both options.
zach_garwood|5 years ago
rlander|5 years ago
- simpler syntax: there’s no Erlang program that you can’t read after getting comfortable with the language. Seriously. Go read OTP source or Ryaks, everything is extremely clear and explicit. To me, easier to read also means less bugs.
- It’s so different from other languages that, IMO, it makes it easier to “think in Erlang”; the syntax fits so well the semantics that I find it easier to think in terms of processes, patterns and the ocasional recursion when switching from other language (most Erlangers are polyglots IME).
*Edit: Reliable network services (Erlangs sweet spot) are much easier to write and maintain when written in a clear and explicit way. I love macros (consider myself a lisper actually) but I think they’re the wrong tool when writing bullet proof network servers (macros are basically everywhere in Elixir).
napsterbr|5 years ago
With Elixir you get everything in Erlang plus a lot of extremely powerful libraries/frameworks (e.g. Ecto and Phoenix), macros, a friendlier syntax etc.
dnautics|5 years ago
Otherwise, I would say stick with elixir. It is more opinionated about how to do tests, how to organize your code, how to do documentation, how to deploy, how to use libraries, all of which will make your life way easier, especially for a greenfield project.
jake_morrison|5 years ago
I much prefer the Elixir syntax. It files off the rough parts of the Erlang syntax, e.g. needing to keep track of commas, periods and semicolons at the ends of lines. The most important thing Elixir adds, though, is lisp-style macros, which makes everything else easier.
This is the post which made me switch to Elixir: https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showd... We get the best of both worlds: the ease of use of Rails with the power of Erlang.
josevalim|5 years ago
It provides more context, links, and other improvements over the CHANGELOG. I am not sure if it is possible to update the link in the post though.
dang|5 years ago
scns|5 years ago
bot41|5 years ago
freedomben|5 years ago
I was able to find a few jobs, but not a ton (this was a couple years ago). The jobs that are out there all wanted experience but obviously that's hard to do with a new platform. I got an interview with one company that I thought understood that I only had a few months experience as a hobbyist (which means I'll be doing a lot of Googling even for common APIs) but they rejected me. At this point my experience with professional Elixir has not been positive.
I love the language but I'll probably just stay a hobbyist, at least until things change.
bcrosby95|5 years ago
peruvian|5 years ago
I just decided it's one of my hobby languages. If a job comes out of it in the future, that's awesome.
pmarreck|5 years ago
You are experiencing the same global pandemic the rest of us are, right? Remote work and all that? (It’s honestly not for everyone. I prefer some physical facetime myself or I... “get disconnected”)
> not a strongly-typed language
While this guarantees elimination of a class of bug, pattern matching plus guards cover most of the potential bug surfaces there IMHO. I know the language creators have been considering some directions to go, there
andy_ppp|5 years ago
samgranieri|5 years ago
sergiotapia|5 years ago
ramchip|5 years ago
anonymousDan|5 years ago
lawik|5 years ago
Most interesting take-aways from benchmarks are some cases where RabbitMQ processes 30-50% more messages per second. And where a native Erlang JSON library beat NIF C library in some specific tests. The PR link covers this info.
jetpackjoe|5 years ago
thepratt|5 years ago
princevegeta89|5 years ago
gmassman|5 years ago
pselbert|5 years ago
0: https://github.com/elixir-lsp/elixir-ls/blob/master/CHANGELO...
auraham|5 years ago
lytedev|5 years ago
unknown|5 years ago
[deleted]
ch4s3|5 years ago
pmarreck|5 years ago
bostonvaulter2|5 years ago
_zachs|5 years ago
svnpenn|5 years ago
https://github.com/erlang/eep/issues/12