The Joy of Erlang; Or, How to Ride a Toruk (2011)
evanmiller.org
evanmiller.org
OTOH Kotlin is on that list too, its difficult to choose!
Kotlin, IMO, is just a "better" java. It would be just learning new syntax if you are already familiar with java like languages.
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 downsides are:
1. A somewhat flaky build tool(rebar3)
2. Not nearly as many libraries as Python/Java/Ruby/etc..
The Cowboy web server uses a makefile-based tool.
https://github.com/ninenines/erlang.mk
Some of the reasons why.. https://erlang.mk/guide/history.html
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.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.
jsoftware.com is the J site.
https://en.wikipedia.org/wiki/J_(programming_language)
J was developed by Kenneth Iverson, creator of APL.
http://erlang.org/pipermail/erlang-questions/2014-January/07...
> 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!
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.
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.
https://gist.github.com/macintux/6349828#alternative-languag...
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.
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.
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.
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.
FWIW, I'm enjoying my Elixir experience. I was productive pretty quickly, and I've got some fault-tolerance and concurrency pretty cheap.
For smaller, more agile shops I'm sure there's more Elixir adoption as people look for alternatives to Ruby.
I've never seen any job statistics, nor do I have any useful anecdata.
But it is also following a strategic turn and an organisational change.
Toyota, Comcast, Sky, Adobe,Square Enix are the first "entreprise" names that come to my mind for elixir
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)