If you want to really understand the philosophy that makes Erlang ( and Elixir ) beautiful ( and why it made me a better programmer ), this conference by Greg Young is a kind of eye opener : <a href="https://vimeo.com/108441214" rel="nofollow">https://vimeo.com/108441214</a> .<p>You realize then that clustering, hot reload, availability etc... are not only features but the logical consequence of a beautifully crafted environnement that aims at developer productivity.<p>I'm sometimes amazed on how easy I can achieve stuff on the Erlang VM that would take ( if it's not impossible at all ) at least 10 times the time in a more usual language ( Ruby or PHP when you work in the web industry as I do ).<p>My last example was when I needed to batch sql inserts in an events database. In a normal language I would have needed a queue, the libraries for it, workers, new deployments and infrastructure to monitor, monitoring, supervision, etc... In Elixir, in 20 lines of code, it's done.<p>If you do not need complex calculations, the Erlang VM can basically become most of your architecture. It's already per se a SOA.
One thing that is completely missing from the Erlang side of the article are the OOB monitoring and operating capabilities.<p>An Erlang VM is a living system that has a shell which you can connect to, and control both the VM and the applications running in it. You can also remotely connect to another VM, execute arbitrary code, debug, stop processes, start processes etc. It really is an operating system in itself, that was _designed_ to be that way.<p>And the best part is that you get all this for free. Whether that is a good thing depends entirely on your needs. You probably wouldn't want to replace your bash scripts with Erlang programs :)<p>What Erlang is not really suited for is where you need multiple levels of abstraction, such as when implementing complex business logic. You would think that the functional nature of the language lends itself to that, but then you quickly realize that because the primary concern of an Erlang engineer is to keep the system alive, and for that reason you must be able to reason and follow the code as it is running on the system, all kinds of abstractions are very much discouraged and considered bad practice (look up "parameterized modules" for an example of a feature that was _almost_ added to the language but was discarded in the end).<p>I think that from this perspective Erlang and Go are actually very similar - both prefer simplicity over abstractions.
I think the part about cooperative/preemptive multitasking isn't saying it all.<p>Go multitasking is based on the compiler inserting switchpoints on function calls and syscall boundaries. But this affects the scheduling of a single OS-level threads executing that specific goroutine. The number of OS-level threads that the Go scheduler uses can arbitrarily grow, and OS-level threads are preemptively multitasked.<p>So I think the description is focusing a narrow view of the problem. What is usually required by applications is low latency in reply to system events (e.g.: data available on network sockets), and Go performs very well in this context. For instance, the fact that Go is transparently using a epoll/kqueue based architecture under the hood is probably affecting latency much more than the whole "cooperative" issue as depicted.
This is more for people looking at erlang/elixir than a critique of the blogpost or a suggestion for a change.<p>> Within Elixir, there is no operator overloading, which can seem confusing at first if you want to use a + to concatenate two strings. In Elixir you would use <> instead.<p>When this popped up, it reminded me of something people try to do often and then have issues with performance. You <i>probably</i> do not want to concatenate strings.<p>"Yes I do" you'll first think, but actually erlang has a neat commonly used thing to help here.<p>Let's say you're doing some templating on a web-page. You want to return "Welcome back username!". First pass (a while since I wrote erlang so forgive syntax errors):<p><pre><code> welcome(Username) ->
"Welcome back " ++ Username ++ "!"
</code></pre>
Now it's going to have to construct each string, then create a new string with all three. More creation & copying means things get slower.<p>Instead, many of the functions you'd use to write files or return things over a connection will let you pass in a <i>list</i> of strings instead.<p><pre><code> welcome(Username) ->
["Welcome back ", Username, "!"]
</code></pre>
Now it's not copying things, which is good. But then we want to put the welcome message into another block with their unread messages.<p><pre><code> full_greeting(Username) ->
welcome(Username) ++ unread_messages()
</code></pre>
More appending than is good here, concatenating lists is going to take time. Of course, we could put it all in one function, but then we lose re-usability in the templates and have horrible massive functions. While this is a simple example, I hope you can picture a larger case where you'd want to split up the various sections.<p>Anyway, there's a better way of doing this. The functions that take lists of strings actually take lists of strings <i>or other lists</i>. So we can just do this:<p><pre><code> full_greeting(Username) ->
[welcome(Username), unread_messages()]
</code></pre>
You can keep going, nesting this as much as you want. This saves a lot of copying, allows you to split things up and avoids having to keep flattening a structure.<p>So, for people about to get started, try not to concatenate your strings, you can probably save yourself and your computer some time.<p>For more info on this, you want to search for "IO Lists" or "Deep IO Lists".
Go's philosophy around error handling (or lack thereof) is arguably atrocious compared to BEAM's "Let It Crash (And I'll Just Log It And Restart In 1 Millisecond With Exponential Backoff)" philosophy.<p>To review: <a href="https://gobyexample.com/errors" rel="nofollow">https://gobyexample.com/errors</a><p>Manually checking every possible error (and then, only in the spots where <i>you can imagine an error occurring</i>) is a heck of a lot of extra work for the programmer (and code for the code reader/reviewer) and <i>still</i> won't catch all possible errors (both conceivable and inconceivable) properly. And arguably, the fact that an unchecked/undetected runtime bug in Go will basically send it into an "indeterminate state" which is impossible to reason about (much less debug), is an incredibly strong argument against this philosophy, IMHO. As far as I'm concerned, as soon as my code goes "off the beaten path" state-wise (read this as: "significantly differing from my mental model"), it <i>should</i> crash, ASAP. Isn't every bug literally a situation the programmer didn't account for? Aren't runtime errors <i>by nature</i> unexpected by the programmer? Why would you then give bugs and errors <i>even more room</i> to corrupt the state of the world, then? ;)<p>We are all obsessed with computers and languages when the real limit is the programmer's mind and ability to reason about the code s/he's building and the states that code can get into. I think BEAM langs and purely functional langs more generally (along with functional/immutable data structures, etc.) do a much better job of addressing this <i>root</i> problem. I'm going to quote John Carmack from his great blog post about functional programming here (<a href="http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php" rel="nofollow">http://www.gamasutra.com/view/news/169296/Indepth_Functional...</a>):<p>"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."
That comparison was way better than I was expecting it to be. Go is still on my to-do list, but Elixir parts seem to be quite thoroughly described and without major mistakes. I also like the conclusion and to be honest this is how I always felt about the two. Definetly recommend reading this is if you're new to any of the two.
I think a good way to increase creativity and productivity is to use the right abstractions of thought and craft.
Every good(non leaky) abstraction expands the creative envelope further and lends itself to creation of new higher order abstractions for the next generation.<p>Having coded in imperative languages like Java, Python and C++, I had been on the lookout for a <i>practical</i> general purpose language which provides good abstractions/high expressiveness.
Elixir appealed to me more than Go in that regard. It's been six months since I started writing Elixir and it's been a pleasure.
I still don't understand what all the hype is about pure functional programming.<p>Sometimes mutations are useful. There are lot of good programming design patterns which depend on mutations.<p>Also, always copying objects by value every time you call a function seems very expensive; especially if you're dealing with very large objects/structs/maps/strings which have to be processed by many functions.
> It has since expanded into numerous other areas, such as web servers, and has achieved nine 9s of availability (31 milliseconds/year of downtime).<p>I definitely want to read more about this.
I am very intrigued in both. I am a reasonably experienced software developer with about 15 hours a week of availability, anyone wants to contract me? I'd gain experience with a modern language, you'd get someone on cheaper than experience would suggest. I know software engineers can use any language but in reality, if I were to get a full time job at a company which uses either of these I'd get a lot less money than I am getting now working with Drupal with 10+ years of experience in it. So I would like to gain some real world experience to make it easier to switch jobs later.
> The biggest difference between the two languages is that compilation for the destination architecture has to be done on that same architecture. The documents include several workarounds for this scenario, but the simplest method is to build your release within a Docker container that has the destination architecture.<p>@brightball Go has had first class support for cross compilation for a while now, no?
There was a good talk at Strangeloop about userland thread runtime scheduling in both the Go and the Erlang VM.<p><a href="https://www.youtube.com/watch?v=8g9fG7cApbc" rel="nofollow">https://www.youtube.com/watch?v=8g9fG7cApbc</a>
The page (like many other pages nowadays) breaks page down - if I press the page down key I then have to scroll up a few lines because the text are obscured by the always-visible "FREE SIGNUP" banner at the top.
If I were putting together a new awesome Thing(TM), I think I would probably use elixir on the front end and internal messaging to handle and distribute jobs, and let go do the crunching and hard lifting.
<p><pre><code> The other trade-off that comes from mutable versus immutable data comes from clustering. With Go, you have the ability to make remote procedure calls very seamlessly if you want to implement them, but because of pointers and shared memory, if you call a method on another box with an argument that references to something on your machine, it can’t be expected to function the same way.
</code></pre>
I would be happy to know how we can make RPC seamless in GO accross multiple machines (clustering). I've missed a nice lib?
<i>In Elixir, error handling is considered “code smell.” I’ll take a second to let you read that again.</i><p>I think that this makes a lot of sense. My experience in just about any language, is that the official means of error handling already feels like a code smell, even before you start using it. And if that's not the case, then it still manages to feel that way when used in a large project.<p>Lots of Smalltalk projects would actually handle errors by saving the image on an unhandled exception. For server applications, this was like having a "live" core dump where the debugger could open up right on the errant stack frame, and you could perform experiments to aid in debugging.
How does Crystal lang compare to the two?<p>I know the syntax is more similar to Elixir, but the format seems closer to Go in the sense that it compiles to a binary.
The article states that Elixir functions must be in a module, during its comparison between Goroutines and one of the few methods of using concurrency in Elixir (there are others beside <i>spawn</i>). This description isn't entirely accurate. Named functions must be inside a module in Elixir, but anonymous functions don't have that requirement.
The BEAM VM and lightweight processes seem amazing - I just wish they could be tied to a language syntax that wasn't so radically different from c/java/javascript and the like. Go code is almost immediately understandable because of this, whereas Erlang is perplexing.
I think it's comparing apples with oranges. They are two different species a compiled vs VM based language, one is a functional styled vs other has duck-tapping. Only thing I can see common is GC and a somewhat but very different concurrency programming paradigms, with message passing. Erlang and BEAM is an aged old giant with battle tested proven reliability, while golang is young lad with the flash like abilities everyone has been longing for. While you get awesome stuff like Hot-Reloading, Go lang gives you compiled code that can run heavy loaded servers on my RaspberryPi (I made one and tried all Erlang, NodeJS, and Golang believe me Golang smokes them all on memory footprint <a href="http://raspchat.com" rel="nofollow">http://raspchat.com</a> ). I can go on and on and on! But picking one is totally dependent on your scenario.
[Deleted] Originally I'd had an off the cuff remark here of "apples to oranges". I'd like retreat to say that the article is actually a good overview and comparison