Live data from Hacker News

Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

atilanevesoncode.wordpress.com

21–30 of 50 posts

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#21
post #7

I really can't imagine that this benchmark is relevant anymore. Haven't Go, D, and Erlang had major changes since then? E.g., Go is now compiled by a compiler written in Go.

I'm planning on updating it this year once I finally find the time to learn Rust. Developing an MQTT broker has become my go-to task for learning new languages.

I'm really glad that you've done the D implementation. I think D gets less attention than it should, especially compared to Go.

Maybe somebody already proficient in Rust, reading this, can contribute?

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#22
post #7

I really can't imagine that this benchmark is relevant anymore. Haven't Go, D, and Erlang had major changes since then? E.g., Go is now compiled by a compiler written in Go.

How Go is compiled isn't as relevant to its performance as much as what Go is compiled into, which hasn't changed all that much as far as I know. The GC improvements might help with latency though.

It's still hard to take any benchmark seriously when given the quote:

> Mosquitto was compiled with gcc 4.8.2, the Go implementation was executed with go run, the D implementation was compiled with dmd 2.0.64.2 and the Erlang version I’m not sure.

The "I'm not sure" speaks for itself, but go run also includes both compilation time and execution time and they're comparing it against just the execution times of the other languages. That's not exactly an apples to apples comparison.

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#23
post #7

I really can't imagine that this benchmark is relevant anymore. Haven't Go, D, and Erlang had major changes since then? E.g., Go is now compiled by a compiler written in Go.

I'm planning on updating it this year once I finally find the time to learn Rust. Developing an MQTT broker has become my go-to task for learning new languages.

No big deal, it wasn't a slight against you, but rather the OP. It's not your fault he reposted your two year old benchmarks.

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#24
post #7

I really can't imagine that this benchmark is relevant anymore. Haven't Go, D, and Erlang had major changes since then? E.g., Go is now compiled by a compiler written in Go.

How Go is compiled isn't as relevant to its performance as much as what Go is compiled into, which hasn't changed all that much as far as I know. The GC improvements might help with latency though.

You're right, my phrasing was a bit misleading. It was just the most dramatic example of a "major change" I could think up.

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#25
post #11

> What about readability and ease of writing? I can’t read Erlang so I can’t comment on that. The Erlang code looks very nice. If you read this, great work Patrick! https://bitbucket.org/pvalsecc/ Nice use of gen_fsm + binary matching. Here is an example of the client code that takes only 200 lines: https://bitbucket.org/pvalsecc/erlangmqtt/src/f37505188c1f1c...

Yeah, it all depends on code authors. This is one more example of an mqtt broker in Erlang - VerneMQ; and it's very readable: https://github.com/erlio/vmq_server We are currently estimating it.

Thanks, we're working hard to improve our codebase even more! :)

Umbrella Project can be found on https://github.com/erlio/vernemq as well as our website https://verne.mq

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#26
post #7

I really can't imagine that this benchmark is relevant anymore. Haven't Go, D, and Erlang had major changes since then? E.g., Go is now compiled by a compiler written in Go.

I'm planning on updating it this year once I finally find the time to learn Rust. Developing an MQTT broker has become my go-to task for learning new languages.

How about Java, then? It's a little less esoteric than most of those languages.

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#27
post #20

Earlier quoted context omitted.

>as much as what Go is compiled into, which hasn't changed all that much as far as I know What are you talking about? Go code generation is getting better all the time.

The translation of the compiler from C to Go was a mostly mechanical transformation, specifically to prevent any changes in the resulting compiled programs. Go compilation is getting better all the time, but the switch itself did not change the resulting programs.

An article from 2013 means that it covers a change from at least Go version 1.2 (released 2013/12/01)) to 1.5 (released yesterday?). The performance section of each document talks about cases where it may go slower for faster in certain instance in every since release, including the one that was the change from C to Go for the compiler[2].

That said, I took the original statement about Go switching from Co to Go to indicate there's been major changes in the compiler, so it would be interesting to see more recent results, not that the change itself necessarily was responsible for major speed improvements, but they could very well have assumed the compiler change would have had a larger affect on the resulting binary depending on their understanding of the Go toolchain.

1: https://golang.org/doc/devel/release.html

2: https://golang.org/doc/go1.4#performance

Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)

#29
post #26

Earlier quoted context omitted.

I'm planning on updating it this year once I finally find the time to learn Rust. Developing an MQTT broker has become my go-to task for learning new languages.

How about Java, then? It's a little less esoteric than most of those languages.

Funny you should ask: https://atilanevesoncode.wordpress.com/2014/01/08/adding-jav...
Post reply on HN