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

111–120 of 202 posts

Re: Comparing Elixir and Go

#111

Post by eternalban »

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

Can't update parent.

Please /do not/ read my OP as a dig/boost at any level. Just pure geek interest in language architectures and sharing info.

Re: Comparing Elixir and Go

#112

Post by Spiritus »

julio83 wrote: post #29

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. I would be happy to know how we ca…

Perhaps not exactly what you/they are referring to. But this is interesting:

https://github.com/docker/libchan

Re: Comparing Elixir and Go

#113

Post by mr_luc »

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 can write NIFs in Rust (which is made even simpler by supporting libraries like Rustler). scrogson, for instance, is using this to fiddle with lower-overhead json.

Re: supervising external processes, an easy hack if you're writing the processes is to add a deadman's switch to both sides, and then launch the processes from a port in BEAM-land.

This effectively makes them supervised; kill the beam process and the external process will die, and whether they both get relaunched depends on the restart strategy the supervisor launched the child with.

Re: Comparing Elixir and Go

#114

Post by macintux »

eternalban wrote: post #69
kjksf wrote: post #8

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

Not disagreeing with you, just adding a bit more info. I'm nearly sure that the fault-tolerance magic of Erlang happens at the library (OTP) level with supervisors.

That's certainly part of it, but really it's the overlap of multiple layers of the overall system.

Lightweight processes, messaging, OTP, supervision all play a role when it comes to runtime fault tolerance.

Erlang is a rare beast in that the language and its VM are both very opinionated and very focused on certain types of problems (such as telecom and fault tolerance). This is not Java and its VM trying to be all things to all people.

Re: Comparing Elixir and Go

#115

Post by sashaafm »

sasa555 wrote: post #99
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…

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…

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

Re: Comparing Elixir and Go

#116

Post by coldtea »

pjmlp wrote: post #81
coldtea wrote: post #60

Earlier quoted context omitted.

> Anyone with a decent CS degree should be able to produce working compilers and interpreters, otherwise it wasn't a decent degree. Which would be useless for production without several years of maturity, a tools ecosystem, and a community adopting them -- and of course continued support. So this is mostly theoretical.

So now compilers should only be written, if v1.0 is production ready?! > So this is mostly theoretical. No, it is setting the facts straight about the widespread ignorance of mixing languages with implementations.

>So now compilers should only be written, if v1.0 is production ready?!

No, but they are only relevant for the purposes of the discussion, that is, when considering whether to adopt a language platform based on if it's AOT or interpreted etc, when they are v1.0.

That somebody can always make an interpreter for an AOT language, for example, is nothing people care about when checking whether to use a language for their projects. It's what's there that matters.

Re: Comparing Elixir and Go

#117

Post by pka »

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.

I don't know why people keep spreading the misconception that mutation isn't possible in pure languages.

    ref
> 1

There you go, mutation in Haskell.

Re: Comparing Elixir and Go

#118

Post by arthurcolle »

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…

Very easy - many solutions to do just this. Porcelain is one such library for Elixir that lets you call C executables, interact with CLIs. I have a lib called pricing on my github that uses the lib to price options using a simple C executable.

Re: Comparing Elixir and Go

#119

Post by Callmenorm »

sasa555 wrote: post #99
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…

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.

Re: Comparing Elixir and Go

#120

Post by Bahamut »

keymone wrote: post #96
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.

> Sometimes mutations are useful especially in a hello-world sized projects. as you scale up mutations become a constant source of bugs, bottlenecks and complexity. > 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 structural sharing in functional persistent data…

I think the person's point was that you sacrifice performance - having the ability to mutate is only a good thing there, as immutability without being able to exit out of that is too inflexible and potentially could cause other hacks to appear when trying to solve that problem.

FP with a focus on immutability is good for the default, but ignoring its limitations is bad.

Post reply on HN