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

101–110 of 202 posts

Re: Comparing Elixir and Go

#101

Post by maxpert »

pjmlp wrote: post #19
maxpert wrote: post #17

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

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

Makes me wonder if its trivial why didnt't people just do it last few decades then? Even with AOT you will be shipping some kind of runtime if you want stuff like Hot reload etc.

Re: Comparing Elixir and Go

#102

Post by maxpert »

pjmlp wrote: post #30
timClicks wrote: post #23

Earlier quoted context omitted.

Pretty significant detail though, as no one has done either.. also "anyone" is fairly strong, building decent compilers and interpreters is pretty difficult

Anyone with a decent CS degree should be able to produce working compilers and interpreters, otherwise it wasn't a decent degree. Of course, writing very good ones is a different matter.

I think every CS graduate does that as part of Compiler Construction course so rather than questioning people's degree I would say doing these advanced features is not a trivial task.

Re: Comparing Elixir and Go

#103

Post by andy_ppp »

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…

Or compile Elixir to native code with HiPE by adding:

    @compile [:native, {:hipe, [:verbose, :o3]}]
to the top of the module with the arithmetic. It might not be as performant as C but it can be about 10-15X more performant than pure elixir (in my tests anyway).

I've no idea of the relative performance against numpy...

Re: Comparing Elixir and Go

#104

Post by axiomabsolute »

jondubois wrote: post #51
fetbaffe wrote: post #49

Earlier quoted context omitted.

You only need to copy the data if the consumer of the data changes it, i.e. copy-on-write.

That sounds a bit better than I thought but it still doesn't change the worst-case complexity.

The canonical text discussing how this is achieved refers to data structures optimized for immutability as "purely functional data structures". [1] These type of data structures are the default for Clojure as well, and there are a number of blog posts and presentations discussing their implementation. [2] [3]

It's a reasonably complicated topic, but the basic idea is that since the data structures are immutable, much of their structure can be shared between versions with few changes. Most of these data structures end up using a Tree of some sort. Performance characteristics can be influenced to an extent by using bucketing to control the width/height of the tree.

[1] : Purely Functional Data Structures (Amazon: https://www.amazon.com/Purely-Functional-Structures-Chris-Ok...) [2] http://hypirion.com/musings/understanding-persistent-vector-... [3] https://www.youtube.com/watch?v=7BFF50BHPPo

Re: Comparing Elixir and Go

#105

Post by pjmlp »

maxpert wrote: post #101
pjmlp wrote: post #19

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

Makes me wonder if its trivial why didnt't people just do it last few decades then? Even with AOT you will be shipping some kind of runtime if you want stuff like Hot reload etc.

I guess, because most developers use languages as given to them, to create stuff they care about.

Not everyone cares about compiler design.

Every programming language has a runtime, even Assembly (microcode).

Re: Comparing Elixir and Go

#106

Post by [deleted] »

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.

[deleted]

Re: Comparing Elixir and Go

#107

Post by pjmlp »

macintux wrote: post #94
pjmlp wrote: post #19

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

I am highly skeptical that the messaging and GC and introspection and hot code loading features of the Erlang VM can be as trivially converted to a compilation model as you assert.

Prolog, Lisp and Dylan are three examples of languages with AOT compilers available, with semantics similar to Erlang.

Also even Erlang has HiPE.

http://erlang.org/workshop/2003/paper/p36-sagonas.pdf

Re: Comparing Elixir and Go

#108

Post by wilsonfiifi »

jeremyjh wrote: post #74
brightball wrote: post #6

Author here. This was published a week earlier than expected so just a heads up that there are a couple of edits coming.

ZeroMQ is a library written in C++, not a server written in Erlang.

The presence of ZeroMQ in the list of projects built with erlang also made me frown as well. But in the author's defence, there is a pure erlang implementation of zeromq [0]

  [0] https://github.com/zeromq/ezmq

Re: Comparing Elixir and Go

#109

Post by [deleted] »

eternalban wrote: post #68
giovannibajo1 wrote: post #39

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

> I think the part about cooperative/preemptive multitasking isn't saying it all. That's still not the entire story: GC & tight loops in Go: https://github.com/golang/go/issues/10958 Per process vs per runtime GC: https://news.ycombinator.com/item?id=12043088

[deleted]

Re: Comparing Elixir and Go

#110

Post by eoincathal »

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…

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 updated since 2010.

I don't know how effective it is to chuck around 8MB data structures via message-passing. I have no experience of this myself.

Post reply on HN