Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Elixir and Go

blog.codeship.com

Post reply on HN
Print view View original

141–150 of 202 posts

Re: Comparing Elixir and Go

#141

Post by pmarreck »

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.

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 the code reader/reviewer) and still 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 should crash, ASAP. Isn't every bug literally a situation the programmer didn't account for? Aren't runtime errors by nature unexpected by the programmer? Why would you then give bugs and errors even more room to corrupt the state of the world, then? ;)

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 root problem. I'm going to quote John Carmack from his great blog post about functional programming here (http://www.gamasutra.com/view/news/169296/Indepth_Functional...):

"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."

Re: Comparing Elixir and Go

#142

Post by sasa555 »

vvanders wrote: post #132
sasa555 wrote: post #122

Earlier quoted context omitted.

Precisely, which is why I always advise to consider ports first :-) However, in some situations the overhead of communicating with a port might be too large, so then you have two options: 1. Move more code to another language which you run as a port. 2. Use a NIF It's hard to generalize, but I'd likely consider option 1 first. If you go for a NIF, you can try to keep its code as simple as possible which should reduce…

Aren't dirty NIFs on the horizon as well which help with the whole scheduling issues currently associated with NIFs?

Dirty schedulers can help with long running NIFs, but they can't help with e.g. a segfault in a NIF taking down the entire system.

Re: Comparing Elixir and Go

#143

Post by sasa555 »

pmarreck wrote: post #134
sasa555 wrote: post #121

Earlier quoted context omitted.

Thanks, nice to hear that! Basically a NIF blocks the scheduler, so if you run a tight loop for a long time, there will be no preemption. Therefore, invoking foo(), where a foo is a NIF which runs for say 10 seconds, means a single process will get 10 seconds of uninterrupted scheduler time, which is way more than other processes not calling that NIF. There are ways of addressing that (called dirty schedulers), but t…

Won't pre-emptible loops lead to more irreproducible race conditions as a negative consequence, unless the preemption is done deterministically?

Are you asking about BEAM or Go? Preemption already works in BEAM and doesn't lead to race conditions because of nothing shared concurrency.

Re: Comparing Elixir and Go

#144

Post by cookiecaper »

julienmarie wrote: post #88

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 : 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…

>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.

Can you provide more details on this? AMQP is pretty recent and people have been batching SQL inserts for much longer than it has been around. An external queue is not a requirement of non-Erlang languages, but I'm curious about specifically about how the implementation in Erlang would substantially differ/allow new approaches from that in other languages.

Re: Comparing Elixir and Go

#145

Post by gpderetta »

atombender wrote: post #129
gpderetta wrote: post #83

Earlier quoted context omitted.

> Null pointers are impossible in Erlang, whereas they are provable impossible to avoid in C++. They are trivially possible to avoid in C++ as you do not have to use raw pointers. References, value types, custom non-null smart_ptrs, etc.

Not trivially , no. Even if you try to avoid "raw pointers", C++ is an unsafe language by design, and it's non-trivial to turn it into a verifiably safe one: * Even smart pointers are still pointers, which are trivial to access after release by mistake; and references are only safe as long as the caller still exists. C++ does not have anything like Rust's borrow checker. * C++ threads allow race conditions that can s…

Note I was explicitly objecting about null pointers begin impossible to avoid. My claim is that the C++ type system allow avoiding them just fine.

I'm making no claim about general the memory safety of C++, and its issues are well known.

Re: Comparing Elixir and Go

#146

Post by dashoffset »

rbosinger wrote: post #37

I know people will say "apples to oranges" but this is still exactly what I wanted to read. Thanks.

Agreed. It is apples to oranges but the article does an excellent job showing when/why to use each one. I believe the conclusion was spot on and IMO combining the stability of Elixir/BEAM with the performance of Go is the best of both worlds.

Re: Comparing Elixir and Go

#147

Post by julienmarie »

cookiecaper wrote: post #144
julienmarie wrote: post #88

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 : 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…

>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. Can you provide more details on this? AMQP is pretty recent and people have been batching SQL inserts for much longer than it has been aro…

A simple GenServer ( a OTP behaviour ) linked to an ETS ( erlang in memory data store ) table would do the trick. Basically, It receives by message the inserts, and once the counter reaches x or timer reaches y secs, it inserts in the db. Thinking about it, 20 lines of code is already a bit verbose for it :)

Re: Comparing Elixir and Go

#148

Post by julienmarie »

haspok wrote: post #98

One thing that is completely missing from the Erlang side of the article are the OOB monitoring and operating capabilities. 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…

Totally agree. Erlang is quite against "magic" which improves greatly readability. Debugging is really straightforward 99.9% of the time.

Re: Comparing Elixir and Go

#149

Post by di4na »

pmarreck wrote: post #133
eoincathal wrote: post #110

Earlier quoted context omitted.

There are libraries that allow C programs and Java programs to interact with Erlang as though they were Erlang processes. From the Erlang Interoperability guide: http://erlang.org/doc/tutorial/overview.html#id61008 The team at Github took another approach, described here: https://github.com/blog/531-introducing-bert-and-bert-rpc It's an old article - so I no idea if it's still in use. The Github sources haven't been…

> I don't know how effective it is to chuck around 8MB data structures via message-passing. It's my understanding that above a certain size and within the same running Erlang VM (machine), a reference is passed instead of a full copy.

only for binaries. But if your matrix is mainly modified outside of erlang, it may make sense to only use it as an opaque binary inside.

Re: Comparing Elixir and Go

#150

Post by di4na »

vegabook wrote: post #97
julienmarie wrote: post #88

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 : 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…

You may want to have a look at talks like this one

https://www.youtube.com/watch?v=xj3smNjGLaE It is a common pattern to use erlang has a controller plane.

Post reply on HN