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

131–140 of 202 posts

Re: Comparing Elixir and Go

#131

Post by mohaine »

danielnesbitt wrote: post #56
cryptica wrote: post #45

I still don't understand what all the hype is about pure functional programming. Sometimes mutations are useful. There are lot of good programming design patterns which depend on mutations. 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.

Pure functional languages often do not use the same data structures common in imperative languages. Instead there's an emphasis on persistent structures that copy on write while sharing as much data as possible. For instance, prepending to a linked list results in a new head node, but nothing is actually copied. Appending requires a full copy. A developer has to be aware of where the limitations of these data structu…

The performance issue still stands. Linked Lists are often MUCH slower then array backed lists on modern hardware. This is true even when doing lots of inserts. Having all your list in the CPU cache is just too much of a performance gain over having it spread out in random locations.

Re: Comparing Elixir and Go

#132

Post by vvanders »

sasa555 wrote: post #122
Callmenorm wrote: post #119

Earlier quoted context omitted.

I spent 30 minutes looking at NIF, but I was scared away. My understanding is that if the NIF crashes then BEAM crashes. Which leads me to think that if you need NIF then you need safety guarantees on the Native side that C can't provide.

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?

Re: Comparing Elixir and Go

#133

Post by pmarreck »

eoincathal wrote: post #110
vegabook wrote: post #97

Earlier quoted context omitted.

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…

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.

Re: Comparing Elixir and Go

#134

Post by pmarreck »

sasa555 wrote: post #121
sashaafm wrote: post #115

Earlier quoted context omitted.

Love your blog and book Sasa. Could elaborate on the fair scheduling disruption by NIFs? Don't recall ever reading about that

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?

Re: Comparing Elixir and Go

#135

Post by julienmarie »

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…

Another solution is to make your non-erlang process run as a foreign erlang node ( example of a Go library to implement this : https://github.com/goerlang/node ). There are some other messaging libraries for python and ruby that do exist for this.

Re: Comparing Elixir and Go

#136

Post by lenkite »

Callmenorm wrote: post #119
sasa555 wrote: post #99

Earlier quoted context omitted.

It is possible to start external processes from BEAM and interact with them. I've blogged a bit about it at http://theerlangelist.com/article/outside_elixir You can also write NIFs (native implemented functions) which run in BEAM process (see http://andrealeopardi.com/posts/using-c-from-elixir-with-nif... ). The latter option should be the last resort though, because it can violate safety guarantees of BEAM, in parti…

I spent 30 minutes looking at NIF, but I was scared away. My understanding is that if the NIF crashes then BEAM crashes. Which leads me to think that if you need NIF then you need safety guarantees on the Native side that C can't provide.

Apparently people are working on this using Rust for writing NIFs https://github.com/hansihe/rustler

Re: Comparing Elixir and Go

#137

Post by whateveracct »

mohaine wrote: post #131
danielnesbitt wrote: post #56

Earlier quoted context omitted.

Pure functional languages often do not use the same data structures common in imperative languages. Instead there's an emphasis on persistent structures that copy on write while sharing as much data as possible. For instance, prepending to a linked list results in a new head node, but nothing is actually copied. Appending requires a full copy. A developer has to be aware of where the limitations of these data structu…

The performance issue still stands. Linked Lists are often MUCH slower then array backed lists on modern hardware. This is true even when doing lots of inserts. Having all your list in the CPU cache is just too much of a performance gain over having it spread out in random locations.

Depending on your GC, linked lists won't be "spread out in random locations." The nodes will be allocated right next to each other in the case where you're building up a list iteratively.

Re: Comparing Elixir and Go

#138

Post by rdtsc »

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…

It's doable. Erlang is used to talk to the hardware and C code. Can build a C functions (NIF), an driver (for IO for example), spawn a process, or implement the logic of Erlang distribution protocol (what is used to talk between VMs) in C.

With 20.0 coming up it will be even easier. A nifty feature called "dirty schedulers" will become stable and so building long-running calculation in C will be much easier. Previously had to take care not to block the running scheduler thread.

All-in-all Erlang is really good at connecting to and managing things, C and hardware being one of those things.

Re: Comparing Elixir and Go

#139

Post by pmarreck »

kjksf wrote: post #8
EduardoBautista wrote: post #2

> It has since expanded into numerous other areas, such as web servers, and has achieved nine 9s of availability (31 milliseconds/year of downtime). I definitely want to read more about this.

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/Elixir process will crash and then get instantly restarted by the supervisor. If the bit flip hit the supervisor instead, then its supervisor will restart it (most larger BEAM apps have a supervision hierarchy). The only way BEAM will go down is if the cosmic ray hit BEAM.

Checkmate, non-BEAMs? ;)

Post reply on HN