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.
You mean "Functional AND utilitarian" because for me these both are very welcome features.
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.
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.
For years now at best you can see 1-2 minor features a year. Mostly its just some design tweaks.
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!
Dancing around runtime vs compile time configuration seemed like it was one of the "harder" parts of dropping into Elixir.
edit: grammar
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.
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.
It shows off the power of the BEAM VM -- and kind of makes you stand back and go "whoa.. how do they do that?"
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.This is probably colored from my own experience of going from Python (mainly) to Elixir (mainly). As a toy example, imagine having to remove all the negative numbers from a list in the middle of a function.
Most python programmers would reach for a list comprehension after learning about list comprehensions (which is great because they are more FP)
my_list = [number for number in my_list if number >= 0]
So you pick up Elixir and you are trying to do the equivalent thing after reading through the docs my_list = for number <- my_list, number >= 0, do: number
And that works fine, it's my_list is exactly what you expect, no negative numbers.Let's try the same thing in Erlang
MyList = [X || X <- MyList, X >= 0].
** exception error: no match of right hand side value
As a new user coming to the language, trying to do something so simple and getting a somewhat opaque error message is a significant degree of friction.I have found that when I want the old value of a variable to no longer be available rebinding the name is a great way to ensure that. If in the future I decide that I need the old value later on in the function I can always just change the bind to some other name easily enough, but it prevents me from using state when I meant to use updated_state.
Not to say one way is better than the other, I just found this use of rebinding to work well for me by making it "impossible" to use the old / stale / out-of-date value.
def foo(bar) do
bar = decorate(bar)
{:ok, bar}
end
I like that better than calling it something like `new_bar`. I kind of wish there was prime syntax along the lines of `bar' = decorate(bar)` but I can deal with re-binding when only used like this (and really, the stakes are low). More complex cases can generally always be handled with piping.I 100% guarantee you don't miss "immutable variables" in your REPL.
Pid = module:start_link(...).
oh crap. start_link/n returns {:ok, _}, not naked pid. {ok, PidForRealThisTime} = Pid.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.
- 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).
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.
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 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.
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.
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.
Companies like Jane Street make more sense. They use ocaml but they don't expect you to have any ocaml experience coming in, but they also have plenty of resources for training and hiring talented engineers.
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
I would really appreciate any data that backs this up. Or is this a personal observation written as if it was a consensus? Because if we are going by personal experiences, the community definitely feels bigger and more active than before to me.
It's funny because not only is popularity not a good indicator of the quality/utility of a tool, if it is overpopular it can actually hurt things
I.e. I mostly just program for money, so how do I motivate myself to do a side project I'm not interested in, just to learn the language?
I wonder if I could ask my employer for two weeks of time to "rewrite" parts of our backend in Elixir, just so I could scratch that itch, without any of the consequences of it actually reaching production.
Like a programming language sabbatical
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.
0: https://github.com/elixir-lsp/elixir-ls/blob/master/CHANGELO...