[sergiotapia]

The author is quite correct. Go is super boring, and runs fast. Two great points for it.

For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit.

The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of code that's easy to understand.

Here's just one example from me - both examples scrape some info from HTML:

Elixir: https://github.com/sergiotapia/magnetissimo/blob/master/lib/...

Go: https://github.com/sergiotapia/gophers/blob/master/scrape.go...

You tell me which one is nicer to look at and easier to understand.

[leighmcculloch]

+100 Go is super boring and that it's a selling point. Code is a tool, not a device for entertainment. I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex features, which makes me think as I also mature as a developer I'm going to find those things less important.

However, the Go version is way easier to understand. Mind you, I have very little experience with Elixir. In the interest of being pragmatic, the easier code is to understand, the easier it will be to maintain, and we spend much more time maintaining code than writing it fresh.

[sheepmullet]

> Go is super boring and that it's a selling point. Code is a tool, not a device for entertainment.

It is a balancing act.

As an industry we don't "do" training on work time.

So how do you convince developers to work on learning and development during their own time?

One way is to make the language fun and interesting.

> I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex features

20+ year devs don't like jumping onto the latest unproven technique/language. Don't mistake that for wanting few/limited features in a language.

20+year developers arent driving transitions to go. It is fairly new developers wanting to switch because it's cool, it's new, and it helps level the playing field by bringing experienced developers down a peg or two.

[20yrs_no_equity]

Having a lot of experience in Elixir and Go I will say that the advantage of Elixir is not excitement, but that you can reason about your code and expect it to work. For years. Half assed go programs will crash. Half assed elixir programs can run for decades without maintenance.

Elixir is way easier to understand than Go. If you will put one week into learning it, you'll be a lot further than you are with go.

I have a couple decades of professional experience, if you are building a serious system, you want Elixir. IF you are building a devops tool, where a single binary with no install process is what's important, you want go.

But given all the containerization and distributed programming people are doing these days using go for that kinda shows to me that most engineering is done by people who don't understand distributed systems.

[piotrkubisa]

> You end up with significantly less lines of code that's easy to understand.

That is very interesting claim, but there is something more than just tooling and number of lines of codes - a paradigm. Elixir is a functional [1] but Go is imperative [2] programming language. It changes a point in discussion quite a lot, especially when you say 'code is easy to understand'. Personally I prefer Elm over JavaScript/React, because it is 'easier and simplier', but I remember a situation in college when after C#-course we had introduced Prolog and F# and many of newbies found functional programming very difficult... But maybe it is matter of taste.

> Everything about the language and the surrounding tooling is polished.

I don't have strong Elixir experience, but playing with Phoenix framework made me really happy to see how many packages are well documented to create backend for web application. But is almost perfect, almost - because it is not Go.

Go is way more performant (Elixir have results comparable to Python or PHP[3]), has great virtual file system [4], auto generating docs (godoc), gofmt, gorename, golint, gocode (no matter which editor you use - VSCode, SublimeText, Vim you have great autocompletion) and a lot of other things (i.e. examples) which makes learning Go easy for newcomers (i.e. devs who are bored of PHP).

[1]: https://en.wikipedia.org/wiki/Functional_programming

[2]: https://en.wikipedia.org/wiki/Imperative_programming

[3]: https://www.techempower.com/benchmarks/#section=data-r12&hw=...

[4]: https://godoc.org/golang.org/x/tools/godoc/vfs

[iamd3vil]

Go has more performance if there is some number crunching work but if it comes to APIs or web applications, I don't think so. That techempower benchmark for Phoenix is seriously flawed [3]. We use Elixir in production and according to our benchmarks, the performance is very close to Go or sometimes even better. We also use Plug (which is used by Phoenix underneath) directly if it is just a small API. These benchmarks relates more to our experience. [1] [2]

1. https://github.com/mroth/phoenix-showdown/blob/master/RESULT...

2. https://gist.github.com/omnibs/e5e72b31e6bd25caf39a

3. https://groups.google.com/d/msg/phoenix-talk/hljH55fsqqw/eFX...

[piotrkubisa]

Thank you for sharing results of other benchmarks with the Phoenix framework. It significantly changes perspective if we speak about Phoenix performance, but still Go has very good results [1][2] (Gin) in case of throughput, latency and consistency.

You made me curious how release 1.7 affects performance of popular routing packages for Go (Gin, Echo, Httprouter).

[randomdata]

Are those really idiomatic examples though?

For instance, without changing too much, you could implement scrapeProfile like this: https://play.golang.org/p/sP34n9acy7 I think that reads quite nicely, although I'm sure someone else can do even better.

If you modified dumpToCSV to take an interface instead of the concrete type, you wouldn't even have to prepare the user structure. You could pass in the vcard directly.

[sergiotapia]

I'm not sure if they're idiomatic. However, I did write both projects with the same amount of experience in each language. It goes to show then, how much easier it is to write idiomatic Elixir.

Also the elixir-lang Slack channel is just full of incredibly nice people. :P

[brightball]

This has been my experience as well. I think a lot of people came to Go looking to solve some limitations from Ruby, Python, JS. While it does that, you get a lot of trade offs that make it a great solution where you had a problem but not a migration path for everything.

From what I've found so far, Elixir gives a migration path for just about everything except heavy number crunching. Several people who came to Go from dynamic languages have seemed to echo this sentiment.

[viach]

Elixir is nicer to look at, Go is easier to understand.

[themgt]

I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely.

Go to me reads like an ELI5 programming language.

[erikpukinskis]

In some ways they converge, in some ways not. On some level "nice to look at" means everything conveys some meaning, and nothing is obviously awkward. "Easy to understand" means everything you might need to know is on the screen. Those things are often aligned, but sometimes orthogonal.

Put another way, you can make something that looks simple and pleasing, but hides a lot of complexity that's required to understand in order to be able to do your work.

[mixedCase]

>I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely.

Sounds like something that won't hold up as well over time.

[20yrs_no_equity]

Having written a lot of elixir code and now spending my days writing Go code, I think of Go as a tragedy of missed opportunity. If go did concurrency correctly, the way elixir and erlang do it, it would be the language I want to use for everything (well and the pipe operator from elixir is really special.)

But concurrency in go is a terrible hack, it's just slightly better multi-threading with all the deadlocks and mutex and hassles that come with it. Channels and goroutines are not erlang processes.

That so many people think of go as a concurrent language shows how little people understand concurrent programming.

Every engineer who thinks they are decent needs to learn at least one good concurrent language (elixir or erlang would be my suggestions.)

[snaky]

> concurrency in go is a terrible hack

And what in Go is not?