I recently started learning Erlang and at this point I'm comfortable with most concepts and syntax. I'd like to continue my learning by using Erlang to build a "simple" instant message application. I'd appreciate suggestions on which resources (books, websites, etc.) can help me along.
Learn You Some Erlang has a bunch of chapters on concurrency, networking, and OTP. You might also be interested in reading the ejabberd code, though it might be a bit involved.
Related
This question is in the context of the Beam VM and the capabilities that it provides, not in the general context of what a Turing complete language can do. I want to invest some time to learn either pure Erlang or Elixir. I get the basic differences between the two and I am leaning towards Elixir because of the macros, better syntax and faster development of the language this day.
My question is: if I choose Elixir, will I stumble on something that I cannot do in it, but can do in Erlang? Can I use all the OTP stuff, all the Erlang libraries, code reload, etc. with Elixir?
I am not asking for someone's preference between the two; just facts about the possibilities of the languages. Preferably from someone who used both in production.
You shouldn't stumble on anything you can do in one that you can't in the other, since you can freely call Elixir code from Erlang and vice-versa. You can even easily mix Erlang and Elixir files in one project.
In Elixir:
:erlang_module.erlang_function(args)
in Erlang:
'Elixir.ElixirModule':elixir_function(args)
TL;DR - Start with Elixir
Erlang has a steeper learning curve compared to Elixir. Once you start learning Elixir, you will automagically start learning Erlang. Hence, start out with Elixir. Elixir is written in Erlang and Elixir. See distribution on Github (since Elixir is full of macros aka meta-programming).
You can use Elixir with Erlang and vice-versa, hence the full Erlang eco-system of 20+ years of libraries.
More details from Erlang Solutions
Elixir’s ‘out of the box’ productivity is accomplished by a strong focus on tooling and convenience in expression of data manipulation. System design is the same in Elixir and Erlang, but Elixir removes a lot of boilerplate code and is easier to extend. The removal of boilerplate raises productivity and allows programmers to get feedback faster – crucial when you want to launch your product to market as fast as possible. Less boilerplate also makes for happy developers, and happy developers are unsuprisingly productive developers.
Joe Armstrong's (Erlang inventor's) blog post about Elixir
Start here to learn about Elixir - Getting Started
Once you feel its going well, work your way towards practicing on Exercism and other resources.
Just to preface - I have only used Elixir in production and not Erlang.
I would honestly recommend Elixir. This is my opinion and not necessarily the right one for you, but below I will list my reasons why.
Productivity: I come from a Ruby/Rails background so the Elixir syntax and style is something that was very familiar to me. One of the main factors that helps me determine whether or not to learn a language is how productive I can be in it - mainly why I chose Ruby. Elixir is the same. I can work just as fast in it as I can Ruby with all the added benefits of concurrency and pattern matching.
Erlang: Since Elixir is built on top of Erlang and compiles down to erlang and the beam vm, you have access to every erlang module and package. So if you are worried about using elixir and missing out on all of the features of Erlang, you shouldn't be. Elixir even has it's own implementations of most of the bigger Erlang/OTP features such as GenServer, GenEvent etc.
Community/Resources: The Elixir community is really a great one. The slack channel is really popular and great way to get some answers for beginner questions. There are already some really good books written on the language (Programming Elixir 1.2 - Dave Thomas, Author of the Ruby Pickaxe) also that make getting into the language really easy.
Really, if you have a mess around with the two you will probably come to the same decision that Elixir is a much nicer language with all the features of Erlang + More. It's on the rise as well, I can't remember the exact numbers but I remember reading something from the Hex website (package manager) about a considerable increase in package downloads.
There are a few things. I think you can't make a recursive anon function in Elixir. Now to be fair this is something that in 8+ years of Erlang I don't think I have ever needed to do, and if I did it could be done easily in some other way. There are probably a few other things like that that quite honestly you can ignore.
In general, for things that most people care about anything you can Do in Erlang, you can do in Elixir and vice versa. The community on the Elixir side seems to be more active so I would suggest starting there. I have recently moved from Erlang to Elixir and with the exception of a few fancy things in Proper I can say that it is a pretty easy transition
I want to write actor style code for embedded processors and I am trying to decide between writing everything in Erlang vs writing everything in zeromq+any language. Using zeromq looks to be very powerful in the sense that I can use any programming language and make my development a lot easier(many available libs) but then I am not sure if there is any gotcha in this power? I understand that Erlang represent actor model much better especially with OTP concepts but then it seems easy to represent similar actor model with zeromq? Am I looking at this correctly?
1.What do I really lose not using Erlang for embedded applications (where distributed processing, a power point of Erlang, is NOT required) and just build things on top a generic messaging framework like zeromq?
2.Is Erlang offering more than a coordinated messaging framework for a non-distributed embedded application?
3.What specific capabilities of Erlang could took too long to implement with zeromq?
You're comparing apples and oranges. Part of the advantage of using Erlang is the language; if you're going to put it up against zmq + some other language, the other language in that comparison really matters. zmq + ARM assembly? Erlang brings all the wonderful advantages of not hand-coding ASM.
As for what else Erlang brings to the table, Embedded Erlang? Absolutely argues that Erlang has advantages in fault tolerance, hot code loading, rapid development by leveraging Erlang and OTP, easy interaction with C libraries, and simple debugging by live REPL and copy-paste of terms.
Some of those things, such as hot reload, on-device REPL, and established libraries, will definitely take some real hacking to reproduce from the ground up.
My point would be that you will have to work very hard to get the same kind of error handling in Zmq. Erlang has some really nice built-in error handling when things begins to go bad. There has been considerable time spent in Erlang optimizing that part and making it robust.
Zmq on the other hand, is probably faster in some combinations with some languages when you make simple benchmarks. There is less overhead, so it may process messages faster than what Erlang can provide.
But chances are that you will end up re-implementing large parts of Erlang in the language of your choice. And you will probably not do a job as good as 6-10 developers working on Erlang/OTP for 15 years.
On the other hand, Erlang is not a simple language to learn. There is way more to it than just learning how to program in a functional style. Especially the concurrency patterns and failure handling can take some time getting used to.
ZeroMQ =/= Erlang covers many differences. The claim there is that ZeroMQ only provides the messaging aspect, not the light-weight processes, process monitoring and other aspects.
I am about to build a system with Erlang (my problem can be solved better with multiple CPUs) and I have skimmed through:
Learn You Some Erlang;
Erlang/OTP in Action
Programming Erlang (Armstrong);
Erlang Programming (Cesarini).
The Erlang/OTP in Action book (2) says: "...writing non-OTP Erlang code is really an advanced topic, and something that should be done only when you really really have to. So perhaps not ever having done it the non-OTP way is a blessing because you will pick up the right habits straight away with regard to things OTP..."
(2) insists that commercial systems should be built with OTP only, whilst (4) gently shows that OTP is not the only way to do this.
Additionally, by reading (4) I have found out that building the knowledge from the very basics of Erlang helps to understand how OTP works (but not in the opposite way).
So, the question is:
Should I choose Erlang/OTP to build a commercial system or can it be done with pure Erlang?
Learn and play with pure Erlang.
Build systems in Erlang/OTP.
can it be done with pure Erlang?
Yes, it can, subject to the analogue of Greenspun's Tenth Rule: your system will contain an ad hoc, informally-specified, bug-ridden, slow implementation of half of OTP.
OTP is written in Erlang so it definitely can be done in pure Erlang. That being said OTP provides you with a lot of useful functionality which you would otherwise need to write yourself. #Alexey is right than you will end up implementing a portion of OTP along the way. The problem is that the framework you need for building fault-tolerant systems, which OTP provides, has to itself be very fault-free.
I will also echo #Mazen in that experimenting with doing it in pure Erlang gives you a good feel for what is going on internally in OTP and how you can build fault-tolerant systems in Erlang. You will make better use of OTP afterwards. You will come to a better understanding when not to use OTP, and why.
If you read through the "Learn You Some Erlang" (like you said you have) you'll notice the author spends the Designing a Concurrent Application chapter building something half-useful in "plain Erlang". Then in the next 2 chapters, he basically throws it all away, and uses OTP to achieve the same thing with far less code (add to that the fact that because it's OTP code, it's standard - so other developers with familiarity with OTP will have a much better idea of where to look to understand it!)
The OTP has been developed and refined over a lot of years (initial release 1998 according to Wikipedia) with a large number of developers, and the backing of a large international company (Ericsson), and peer reviewed as it's all open source. I think it'd be a little audacious to assume you could single-handledly build something equally robust and scalable!
So use the OTP. Even for "play" projects, still use the OTP as it can only help you learn to make your "commercial" code better :)
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Other than specific projects (although those are welcome as well)...
What tools, books, articles, and other resources should I have at my desk to help me learn Erlang?
Also, are there mobile runtimes for Erlang?
Please point me in the right direction.
Note: yes, I have visited Erlang and Wikipedia, but I'd like to hear some reliable, experienced opinions.
I'm a month-or-so into learning and the guides I'm enjoying most are:
The Erlang Site's Getting Started with Erlang Guide
Joe Armstrong's Book Software for a Concurrent World (thoroughly recommended)
And I have on order: O'Reilly's Erlang Programming which has had some really positive reviews and sounds like a good companion to Joe Armstrong's book (covering many of the same topics in greater depth, possibly with more "real world" examples)
I think you can dive into the Getting Started guide straight away and it will certainly give you a feel for functional programming and then concurrency.
If you're in London this June there is the Erlang Factory conference which looks really good.
While I remember, these are two good presentations taking you through Erlang and it's uses:
Thinking in Erlang
Functions + Messages + Concurrency = Erlang
Finally, you can follow my learning experiences on my blog (joelhughes.co.uk/blog) my step by step adjustment of FizzBuzz from python/ruby/php to Erlang might give you a good flavour (sorry about the shameless self promotion).
I have to say learning Erlang is currently one of my greatest pleasures, there is something very satisfying about it!
For beginners, the "Learn you some Erlang" guide is supremely awesome. It is as of yet incomplete, but provides a lot even with what little is there.
It also has an RSS so you can be informed when (if?) it is updated.
I found the best thing to do to learn erlang was reading joe's thesis
http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
and then writing something I enjoyed, for me it was an iax2 server.
What I can recommend you is not to browse the Wings3d source code.
(I did it and it was a waste of time similar as when I tried to read the Quake2 sources :-p)
I have the both the Erlang Progamming and the Software for a Concurrent World, both are excellent. I might almost say the Erlang Programming is better, it shows a lot more about using OTP (Erlang libraries), but I was also a little more comfortable with the language when I was reading it, so that's what I was looking for.
The Getting Started with Erlang Guide is also pretty good.
Definitely you should give writing a simple server a try. That's one of the areas where Erlang really shines and there's plenty of documentation and tutorials around message passing and the gen_server module.
-- edit
Also, you can run Erlang on ARM based mobile devices (ARMv5+) for sure, you could ask on erlang-questions for other architectures. Check out http://wiki.trapexit.org/index.php/Cross_compiling for the basics of getting started with cross-compiling.
I am considering Erlang as a potential for my upcoming project. I need a "Highly scalable, highly reliable" (duh, what project doesn't?) web server to accept HTTP requests, but not really serve up HTML. We have thousands of distributed clients (other systems, not users) that will be submitting binary data to central cluster of servers for offline processing. Responses would be very short, success, fail, error code, minimal data. We want to use HTTP since it is our best chance of traversing firewalls.
Given this limited information about the project, can you provide any weaknesses that might pop up using a technology like Erlang? For instance, I understand Erlang's text processing capabilities might leave something to be desired.
You comments are appreciated.
Thanks.
This sounds like a perfect candidate for a language like Erlang. The scaling properties of the language are very good, but if you're worried about the data processing abilities, you shouldn't be. It's a very powerful language, with many libraries available for developers. It's an old language, and it's been heavily used/tested in the past, so everything you want to do has probably already been done to some degree.
Make sure you use erlang version R11B5 or newer! Earlier versions of erlang did not provide the ability to timeout tcp sends. This results in stalled or malicious clients being able to execute a DoS attack on your application by refusing to recv data you send them, thus locking up the sending process.
See issue OTP-6684 from R11B5's release notes.
With Erlang the scalability and reliability is there but from your project definition you don't outline what type of text processing you will need.
I think Erlang's main limitation might be finding experienced developers in your area. Do some research on the availability of Erlang architects and coders.
If you are going to teach yourself or have your developers learn it on the job keep in mind that it is a very different way of coding and that while the core documentation is good a lot of people do wish there were more examples. Of course the very active community easily makes up for that.
I understand Erlang's text processing
capabilities might leave something to
be desired.
The starling project already provides basic unicode support and there is a EEP (Erlang Enhancement Proposal) currently in draft, but going in to bring it into the mainstream of Erlang/OTP support.
I encountered some problems with Redis read performance from Erlang. Here is my question. I tend to think the reason is Erlang-written module, which has troubles while processing tons of strings during communication with Redis.