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.
Comparing Elixir and Go
161–170 of 202 posts
Re: Comparing Elixir and Go
#162If 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 : https://vimeo.com/108441214 . 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. I'm som…
how easy is it, even if you do need complex calculations, to get the best of the Erlang VM and call out to say, Python/Numpy or C when necessary? Can these external processes still be supervised, for example? Are decent sized matrices (for example 100x20000 floats so an 8MB data structure) easily movable around the Erlang VM via message passing? IE is it viable in your opinion still to use Erlang as a system for dist…
This has been a very informative sub-thread. Many thanks to all contributors for your thoughts and experience. You have helped to move me forward in confidence on using Erlang/Elixir(basically BEAM) for the distribution and routing side of my enterprise-scale soft realtime data-interpretation project. A great testament to the quality of contributors on HN. I will post at a later stage on progress.
Re: Comparing Elixir and Go
#163Earlier quoted context omitted.
> They are two different species a compiled vs VM based language This is an implementation detail. Anyone can write a VM for Go, or an AOT compiler to native code for Elixir.
Pretty significant detail though, as no one has done either.. also "anyone" is fairly strong, building decent compilers and interpreters is pretty difficult
There is an AOT native compiler that ships as part of Erlang called HiPE. The original project has been incorporated into Erlang 15 years ago: https://www.it.uu.se/research/group/hipe/
The current setup is also mentioned on Wikipedia's page about AOT: https://en.wikipedia.org/wiki/Ahead-of-time_compilation
Re: Comparing Elixir and Go
#164The 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.
Have you looked at Elixir syntax? Elixir is functionally the exact same as erlang, but with a more ruby-like syntax.
Re: Comparing Elixir and Go
#165Go'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. To review: https://gobyexample.com/errors Manually checking every possible error (and then, only in the spots where you can imagine an error occurring ) is a heck of a lot of extra work for the programmer (and code for…
While I agree wholeheartedly that Erlang's design is better: To be fair, you can't get Erlang's semantics without also inventing processes and supervisor trees. And those things would be largely meaningless without immutability. Erlang's magic comes from how all the puzzle pieces fit together into a whole: For example, with immutability comes the ability to always be able to restart from a known state, and probably g…
Immutability probably does simplify a lot of things; but it isn't actually required to get Erlang's model, since Erlang isolates the state of processes from each other. Each process could have its own isolated mutable state as opposed to an immutable one and it wouldn't change the "let it crash" philosophy.
Re: Comparing Elixir and Go
#166I think the part about cooperative/preemptive multitasking isn't saying it all. 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. So I th…
When you say "the number of threads that the Go scheduler uses can arbitrarily grow..." is it not set by GONUMPROCS or something like that? Or is it a dynamic thing -- new threads appear as needed?
The cooperative issue is simply that until a thread does become free, the application can not respond to an event -- even given the epoll/kqueue architecture you describe.
Re: Comparing Elixir and Go
#167Earlier quoted context omitted.
While I agree wholeheartedly that Erlang's design is better: To be fair, you can't get Erlang's semantics without also inventing processes and supervisor trees. And those things would be largely meaningless without immutability. Erlang's magic comes from how all the puzzle pieces fit together into a whole: For example, with immutability comes the ability to always be able to restart from a known state, and probably g…
Immutability probably does simplify a lot of things; but it isn't actually required to get Erlang's model, since Erlang isolates the state of processes from each other. Each process could have its own isolated mutable state as opposed to an immutable one and it wouldn't change the "let it crash" philosophy.
You can't guarantee that isolation without immutabilty, or at least forced copying.
In Go, it's extremely easy to accidentally send a pointer (or a data structure that contains a deeply nested pointer somewhere; this includes embedded maps, slices and channels, which are all reference types) on a channel, which is bound to break mutability guarantees at some point.
Re: Comparing Elixir and Go
#168Earlier quoted context omitted.
I was talking about Dialyzer when mentioning that but I wrote it that way because I didn't want to derail into an explanation of Dialyzer and how it works. I did link to a talk on it though. It's such an automatic part of the stack with no drawback to using it that it's why I wrote it that way. Check that talk though, it's really interesting.
I had a hunch you were talking about the dialyzer, but unless you happen to know about it a priori, this part reads like false information, and it almost had me tune out of the rest of the article. I fully understand you intended to write something else, and I very much agree with the power of the dialyzer :) It was more a "I dualized this section by accident, perhaps other readers would do the same?"
I'll get it adjusted. Article release was bad timing for editing sake because I had to be in a meeting all day today. Should have it updated soon though.
One of the links around that section does include a link to a conference talk on Dialyzer, for what it's worth.
Re: Comparing Elixir and Go
#169Earlier quoted context omitted.
This is how myths are created and perpetuated. This claims from a study of a particular model of Ericsson's ATM switch whose software was written in Erlang. A can tell you for sure that: * Ericsson has other switches and other telecom equipment whose software is written in C++ * other companies (Nokia, Cisco, Alcatel etc.) also built similar complex telecom equipment whose software was in C++ I'm going to bet that at…
If a rogue cosmic ray flips a bit in a running process handling phone calls (note: this exact thing apparently took down all of Amazon S3 once, http://status.aws.amazon.com/s3-20080720.html ), in code that wasn't expected to error, 1) Go will crash or at minimum (arguably much worse) go into an unknown state. 2) C++ will crash, and ideally, restart, but lose all "live" state. (So calls get dropped, etc.) 3) Erlang/El…
I'm not sure if you're being serious, but a random bit flip can easily put a process in an incorrect state rather than make it crash (say charge a user $1000000 instead of $1), or affect a pointer (of which Erlang uses a ton internally - imagine for a second how lists, maps, and code loading work) and make the whole VM crash when it tries to access it. Or it could just kill the OS itself. You would have to be incredibly lucky to get a nice, clean process crash.
Re: Comparing Elixir and Go
#170Earlier quoted context omitted.
While I agree wholeheartedly that Erlang's design is better: To be fair, you can't get Erlang's semantics without also inventing processes and supervisor trees. And those things would be largely meaningless without immutability. Erlang's magic comes from how all the puzzle pieces fit together into a whole: For example, with immutability comes the ability to always be able to restart from a known state, and probably g…
Immutability probably does simplify a lot of things; but it isn't actually required to get Erlang's model, since Erlang isolates the state of processes from each other. Each process could have its own isolated mutable state as opposed to an immutable one and it wouldn't change the "let it crash" philosophy.
>Each process could have its own isolated mutable state
Erlang processes do have their own isolated mutable state.
But it's walled off and accessed through calls rather than variable references; in the non-SMP implementationthis enabled copy-free local (same node) message sends (and it still does, but only for large binaries -- the more general use turned out to be less efficient than copying in SMP because of locking issues related to garbage collection and some other implementation details.)