Go vs Elixir

[AstonJ]

As Go crops up in conversations every now and again, it might be worth having a thread where you can share your thoughts, experiences and opinions. If you’d like to do that please join in, and perhaps if you can please comment on:

• Where you think Go and Elixir are similar
• How you think they differ
• What your experience has been like developing with each of them
• What you may have used each for
• When you would recommend one over the other
• How they compare overall (so things like size, community, support channels, how easy they are to learn, how fun they are to work with, etc)

For any newcomers coming on to the forum, please note this is a friendly place and so please take part amicably

[wmnnd]

One thing I envy our friends using Go for is the possibility to easily create a single-binary distribution of their applications. I’d love it if that was possible with Elixir/OTP.

I don’t suppose it would be too hard to create a tiny sub binary that could contain and run a Release but as far as I know, something like this doesn’t exist at the moment.

Edit: Thread on this created here: Elixir Static App Binaries

[radar]

I’ve built large-scale systems in both Go and Elixir. The Go one supported at least 100k concurrent TCP connections from IOT devices. The Elixir services ingest events from a monolithic Rails application faster than the Rails application can produce them.

So I feel qualified to comment here.

Points for Go

I agree with @wmnnd regarding the Go binary. That’s certainly a “killer feature”. And that I can cross-compile on my Mac for other OSes too is super nice. Being able to take a binary to any other operating system and just run my program without any external dependencies is one of the best experiences I’ve had with a programming language.

Another Go feature that I appreciate is the type definitions in structs, functions and so on. It helps me not make as many mistakes. The compiler tells me what I’m doing wrong and then I fix it. But sometimes the errors from those can be quite… cryptic.

I would also list go fmt as a plus here, but Elixir is certainly catching up in those stakes.

Points for Elixir

What I prefer in Elixir is that the tooling seems to be better thought-out. Elixir has a fantastic package manager, whereas Go has… well, I’m not sure what they have. It seems like a bit of a “wild west” over in Go-land in that regard.

Elixir’s process management / supervision was also easier for me to wrap my head around than Go’s channels. It somehow makes more sense in ways that I can’t explain right now. When Go’s channels crashed I would get more cryptic messages from that. Elixir’s supervisors and the underlying Erlang error messages typically show me why a process exited, which is very helpful for debugging reasons.

Elixir as a language also tends to have quite a few helpful things built into the standard library, where in Go there seems to be some opposition to having common things like slicing arrays built in. (Although googling this last part turns up nothing of the sort… so maybe my memory is wrong?)

[blatyo]

I’m not a user of Go, but I have noticed it’s prevalent usage in the ops space (kubernetes, docker, hashicorp, etc). If I were doing a project in that space, I feel like I would have a hard time arguing to use anything else.

[aeden]

We use both Go and Elixir (as well as Erlang) over here at DNSimple. Here’s my hot take on them when comparing (all of this is my opinion, feel free to disregard completely):

Go

• Built binaries = ridiculously easy deployment
• CPU and memory usage are generally very small (we build small services with Go)
• Excellent parallel processing performance
• Dependencies were originally challenging to manage (due to simplicity of model) but now everything is vendored, so it is not as much of an issue
• Standard libs cover a huge amount of use cases, meaning external dependencies can be minimized
• Ideal for small services or applications that run and exit often

Elixir/Erlang

• Excellent dev tools (mix for example)
• Excellent runtime inspection (bind to a running service and start calling functions)
• Excellent parallel processing performance (although unbounded message queues needs to be kept in check)
• OTP is a powerful system for building long running services combined of multiple small parts (apps and libs)
• Fail fast design seems to result in more robust systems that are easier to reason about when problems occur
• Ideal for services that run for long periods of time

Bottom line: we love all three languages and take advantage of their different runtime profiles for optimal systems.

[mkunikow]

Microsoft hired a lot of Go developers for Azure

[brightball]

I put my thoughts more long form a while back:

https://blog.codeship.com/comparing-elixir-go/

[mkunikow]

Google wants Go to become the go-to language for writing cloud apps – TechCrunch

https://blog.golang.org/go-cloud

google/go-cloud

[jeramyRR]

Go is great and all, but I think the real comparison here should have been done with Rust’s Actix project (especially actix-web). It is the actor model framework for Rust, and if y’all haven’t noticed it’s been spanking almost all the other frameworks in benchmarks lately.

Now it has a bit of a way to go before it can match OTP feature for feature, but it’s still an amazingly powerful framework. Plus is has the added benefits of being written in Rust, and it was started by a developer at Microsoft.

[jeremyjh]

Every language has something like this. C++ has CAF, Scala has Akka, C# has Orleans. Just like Rust and Actix, they are libraries that try to make async IO tolerable to humans, without implementing a runtime system to do the work for you. If you are stuck in one of those languages to begin with, then maybe these libraries will help you. I wouldn’t pick one just because of some benchmark game scores though.

[sribe]

I wouldn’t pick one just because of some benchmark game scores though.

But if I had to have high CPU performance, I’d sure look at Rust first.

[michalmuskala]

Every language has something like this. C++ has CAF, Scala has Akka, C# has Orleans. Just like Rust and Actix, they are libraries that try to make async IO tolerable to humans, without implementing a runtime system to do the work for you. If you are stuck in one of those languages to begin with, then maybe these libraries will help you. I wouldn’t pick one just because of some benchmark game scores though.

The thing all of the mentioned libraries lack compared to BEAM for me is introspection. Tracing, all the various VM metrics, the lcnt emulator, and many more are such powerful tools when running in production and something goes wrong. I don’t think there’s any other environment that can match this level of insight into the system.

[zven21]

Go is the new favorite of programmers in China.

[OvermindDL1]

The thing all of the mentioned libraries lack compared to BEAM for me is introspection. Tracing, all the various VM metrics, the lcnt emulator, and many more are such powerful tools when running in production and something goes wrong. I don’t think there’s any other environment that can match this level of insight into the system.

Yes this so much!!

I still don’t see how Go code looks the least bit maintainable personally… >.>
Fast to make sure, but not maintainable…

[CptnKirk]

So Go is really the new better Python? Instead of drawing direct comparisons to Elixir. At least that’s what this thread says to me. Faster Python with a better concurrency story. Also, single binary deployments.

Correct me if I’m off base.

[OvermindDL1]

Eh, except Python’s even gotten an optional ML-ish static typer recently, that’s more than can be said about Go. ^.^;

But yes, Go has much better concurrency handling than python while being an optimizing compiler, though it is significantly much less succinct, python bests it there handily.

[jeremyjh]

I don’t think any one liner will do either language justice. Python and Go philosophies are very different. Python is very much an object oriented language that supports inheritance, it relies on exceptions and dynamic typing, all three of which are untrue of Go.

Beyond differences that are mainly a matter of taste, Python is a far better tool for big data, scientific computing and analytics where it has massive market share, mind share and many useful libraries and frameworks. Its also much more established for web application development (Django, Flask) though that is definitely an area where Go will continue to encroach. Go has established itself as the language of choice for cloud infrastructure software and not much else but a lot of hype to be honest.

[mkunikow]

So Go is really the new better Python?

I would say GO is more node js competitor.

[cdegroot]

So Go is really the new better Python

For ops-type stuff, probably. For technical computing, Julia looks very interesting.

(I looked at Go a couple of years ago, found the whole model a tad confusing compared to Elixir, and ditched it when I started looking for any metaprogramming facilities and came up empty-handed. It’s one of these languages that I will pick up on-the-fly if I ever find myself in a Go shop ;-))

[dimitarvp]

I am really 50/50 about Go and have been ever since I made quite a bit of money with Elixir.

It’s undoubtedly mega useful to have cross-compiliing and single binaries. That’s very handy in sysadmin / ops work. Go is indeed fast overall and has a fast bootstrap time.

But it still does not seem like a language where you would like to code a big system that can live for a long time. The concurrency primitives are really barebones N:M mapping between CPU cores and threads. Not to mention the extremely cryptic program panics that you can swear on your life you prevented with your ultra-defensive programming that costed you 500 more lines of code.

Another awful element is the optional strong typing. The interface{} generic non-typed data escape hatch is abused far too much, and I have only inspected ~12 open-source Go projects. Many rely on project docs and team culture to hand-wave this problem away and that’s okay if it works for them, but it definitely gives the language a bad reputation.

Need a very small and focused microservice? Need a CLI tool? Need a network daemon? Go is good.

Everything else? Erlang / Elixir can do it better than most other languages. I suspect Clojure and Racket as well, although they lack the BEAM primitives which is a huge minus.

Or if you need more numbers crunching, you can live in the pleasant illusion that you code Python while you are actually utilizing a well-written native library. That works too.