I followed a link to another post on the blog that was one of the best honest analyses of Erlang. I've been meaning to play with it a while, maybe these upcoming holidays. http://www.evanmiller.org/why-i-program-in-erlang.html
OTOH Kotlin is on that list too, its difficult to choose!
Learning Erlang/Elixir is like learning a new paradigm, or a new way to think about programming. You can then apply these concepts to other languages. It's made me a better programmer.
Kotlin, IMO, is just a "better" java. It would be just learning new syntax if you are already familiar with java like languages.
> Learning Erlang/Elixir is like learning a new paradigm, or a new way to think about programming.
Agreed. It taught me three things primarily, both can be applied to other areas / languages:
1) Importance of fault tolerance (especially applied to distributed system). That is, trying to build a system out of small isolated components that talk to each other, and each can fail independently and be restarted safely. Did anyone say micro-services? Nah, the new rage is nano-services (stolen from here http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...). But there is no need to get all fancy, this also can be done with plain old forking OS processes. The important bit is that the memory has to be separate, either on different machines, OS processes, or in different heaps like BEAM VM does it. So threads, or greenlet or goroutines don't quite fit the bill here. (Thought if Rust's compiler can decide that memory will never be shared at compile time, it's also good enough).
2) Importance of functional programming. Passing state explicitly and dealing with immutable data ensures that there is less chance of confusion and it's also easier to figure out what is happening. Also easier to write tests, as there is less a need to mock everything.
3) Importance of hot code loading and traceability in production systems. Many of the platforms and languages offer some form of hot code loading and ability to set traces on functions and methods. But with BEAM languages it's all built in, integrated and it's a first class feature. This makes a difference in production, can update code with extra logging if there is a bug experience by only one particular customer and reproducing it is hard, or can patch a critical running system without taking it down.
The language is not hard. What's needed is the OA kind of explanation to teach
1. understanding the breadth (pitfalls, hidden gems, whats there) of the "std lib".
2. the ErlangVM / runtime.
3. Esp the OTP/whatever it's called.
4. Erlang tooling how to build, test, deploy, redeploy a non trivial project.
Evan writes posts about multiple languages, IIRC. I had seen his blog earlier and read a few posts about other languages.
Another blogger with an interesting blog, who writes about multiple languages, is Chris Double. His blog is https://bluishcoder.co.nz (Bluish Coder is an anagram of his name, IIRC). I recently saw a post on his blog called "Introduction to J." The post also has a short list of links for learning J.
> And now, the bad news: it's been a fun ride, but I am planning to retire from Erlang and Chicago Boss. But don't cry for me: I've been having success with my desktop software business (wizardmac.com) and realized that going forward I will no longer have the time to dedicate to both CB and Wizard. (Incidentally I also left grad school a couple months ago to focus on Wizard.) Finished software products require a ton of focus and work, and I just don't have the mental capacity to manage two projects at once. I wish there were more hours in the day!
A question for any Erlang devs out there. For Erlang neophytes, what are the arguments for learning vanilla Erlang over one of the other ErlangVM languages?
The only other language that has any commercial acceptance is Elixir, so really it boils down to those two.
Elixir has more syntax to learn than Erlang. You could learn just about everything there is to know about Erlang syntax in a half hour, with the exception of a few advanced features like list comprehensions.
Elixir's syntax is much more familiar to most developers. Most consider this a good thing; I'm biased because Erlang's unusual syntax helps me think differently. If I write something that looks like Ruby, I tend to think like Ruby.
Knowing Erlang can only help with Elixir, but it's not necessary. There are probably more jobs with Elixir these days, which is a good thing. I guess I'm not really helping, so I'll shut up.
Well perfect, do give LFE a try. I know of a few commercial users of it. You might be able to transfer some of the ideas and skills from lisp but also learn about processes and mailbox and such, without seeing a completely new syntax.
I've dabbled in it a couple of times, because I'd also like to do some work with it, but haven't gotten very far. By all means give it a shot if it'll scratch your itch.
You can't escape Erlang when working in Elixir, and Elixir doesn't try exist without Erlang. Elixir tries to offer stuff that Erlang doesn't offer, and doesn't want to offer, including: anonymous functions, more flexible macros, variable reassignment (a=a+1), better string handling, polymorphism (via protocols), etc.
Erlang is simpler, there are less syntactic constructs to learn, has more information and learning resources available probably due to its age (30+ years),maybe more tools and libraries, that also means more example to look at. It is also the default language the VM is written for. So you can track and follow the latest changes as they are released.
However if you come from Rails or want to do mostly web development, then Phoenix is a nice framework, so maybe a good place to start. Also Elixir has a very friendlier community for newcomers perhaps, kudos to Jose and team there, they went above and beyond to make that happen.
All in all, there is a huge overlap. Some of the harder or more interesting concepts - functional programming aspect, using light-weight processes with isolated heaps for concurrency, performance evaluation and debugging will be the same. It is not like if you pick Erlang or Elixir you'll be wasting time and going in a separate direction, they share a lot of common concepts, and could transition easier if you need to between them in the future.
>However if you come from Rails or want to do mostly web development, then Phoenix is a nice framework, so maybe a good place to start. Also Elixir has a very friendlier community for newcomers perhaps, kudos to Jose and team there, they went above and beyond to make that happen.
One of the best parts about Elixir/Erlang/other BEAM languages is that you can use something like the Phoenix framework in your erlang project just fine. You do not need to learn Elixir if you want to use any of the neat stuff developed in it.
I don’t think you can realistically use Phoenix without doing at least some Elixir, because it uses macros quite heavily, and you can’t call those from Erlang.
I don't know of any specifically, sorry. But you can use elixir modules by just prefixing them with `Elixir.` in erlang. So to call the phoenix module in erlang you'd just do a regular function call to 'Elixir.Phoenix':xxx
"Over one of the other" practically means "over Elixir".
Erlang as a language is very simple, without any magic that Elixir has with
its marcos. And there's the tooling aspect: you're not detached from the VM
and its mechanisms, so if anything breaks (and something will break sooner
or later), you have a chance to know where to hit with a hammer.
The underlying libraries you'll use - gen_server, supervision trees etc are all obviously written in Erlang. It may aid in understanding of them. In practice though something like Elixir provides a superset of the functionality of Erlang. If you learn Elixir, learning to read Erlang is not very difficult.
It's like how you kinda need to know js to do anything with coffeescript. The fastest way to learn Elixir is to learn Erlang first.
You will be dealing with Erlang data structures (sans syntax sugar), the Erlang stdlib (Elixir doesn't wrap everything) and Erlang libraries to accomplish anything substantial. Sooner or later you'll have to grok Erlang.
My problem is not that which ErlangVM language to learn but more like how to work with OTP. Most of my Erlang projects are not OTP which is a heretic move according to Erlang devs.
Erlang's syntax is a bit more obscure than other languages that are on BEAM. That being said, there's little reason to learn Erlang directly. It's better to learn OTP and Elixir and Erlang as you need it (e.g. libraries not available in Elixir).
To piggyback on this question: regardless of the merits of each language, do people think that in terms of enterprise adoption and job opportunity Elixir is more interesting than Erlang at this point?
Per the other comments, if you learn Elixir for professional reasons, you're very likely to at least get to the point you can read Erlang, even if you don't write it fluently. And if someone is hired on who knows Erlang but doesn't know Elixir, I doubt that's going to prove a huge impediment, especially if they have any other scripting language experience. I'd consider the question of Elixir/Erlang to be more a "both-and" sort of thing than an "either-or".
"Enterprise adoption" is still years off, "job opportunity" is just starting to come into its own. But the real reason I'd call Elixir a better place to be right now is the community. The Erlang community is not growing. Elixir's community is.
I've been seeing enough interest in Elixir to justify learning it. It's still in the "Nice to have" section of the job listings, but it's popping up more.
FWIW, I'm enjoying my Elixir experience. I was productive pretty quickly, and I've got some fault-tolerance and concurrency pretty cheap.
I haven't used Erlang since 16 (maybe 17), but the two features that attracted me to Elixir were support for UTF-8 strings and macros. Erlang may have both now—I'm not sure—but doing localization in Elixir was a lot easier than it was in Erlang back in the day.
I would recommend learning both Erlang and Elixir. They're both amazing languages, I think, and your Erlang skills transfer nicely into Elixir, since you can call any Erlang function from within Elixir code.
R16 works with utf-8 binaries just fine. <<"Foo"/utf8>> you might need to put a preprocessor flag to set the default encoding for source files (the default changed in 17 or 18, I think); also settings may be needed for console output (but that probably applies to elixir too). Erlang strings are lists of Unicode code points, if you're putting a list of utf8 bytes in there, that's not ideal (but you probably want binaries instead of lists, most of the time anyway)
If you're the type that looks into sources of libraries when you have questions/problems, learning erlang will be helpful -- most of OTP (basically the standard library) is written in erlang itself, so it's useful to know that. (There's some amount of C code in OTP, but not too much.
OTOH Kotlin is on that list too, its difficult to choose!