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

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

#11

Post by rdtsc » Thu, Aug 20, 2015, 2:59 PM UTC

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

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

#12

Post by tcfunk » Thu, Aug 20, 2015, 3:06 PM UTC

areusch wrote: post #10

update from go 1.2? since there have been many performance improvements since then...

It seems this article was posted in 2013. Not sure where that falls in the Go release timeline, but I'm guessing the version wasn't was far behind then as it seems now.

Edit: After a quick search, it looks like Go 1.2 was released only 4 days prior to this article being posted.

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

#13

Post by rubiquity » Thu, Aug 20, 2015, 3:09 PM UTC

nanny wrote: 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.

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

#14

Post by playing_colours » Thu, Aug 20, 2015, 3:13 PM UTC

rdtsc wrote: 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.

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

#15

Post by playing_colours » Thu, Aug 20, 2015, 3:15 PM UTC

wehadfun wrote: post #4

Is there any hardware that uses MQTT?

There is. For example, we use it for our hardware product: https://www.relayr.io/products-services/wunderbar/

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

#16

Post by humanrebar » Thu, Aug 20, 2015, 3:16 PM UTC

nanny wrote: 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.

That was basically my reaction as well. I would also like to see a Rust implementation included.

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

#17

Post by tedchs » Thu, Aug 20, 2015, 3:22 PM UTC

This being from 2013 and using Go 1.2, I'd be interested to see an update using Go 1.5.

Thanks to the author for including standard deviation numbers and not just the averages like so many other "benchmarks".

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

#18

Post by voidlogic » Thu, Aug 20, 2015, 3:23 PM UTC

rubiquity wrote: post #13

nanny wrote: 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.

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

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

#19

Post by voidlogic » Thu, Aug 20, 2015, 3:24 PM UTC

tedchs wrote: post #17

This being from 2013 and using Go 1.2, I'd be interested to see an update using Go 1.5. Thanks to the author for including standard deviation numbers and not just the averages like so many other "benchmarks".

Thanks, came here to say this. Go GC and code generation are improving all the time.

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

#20

Post by tedsuo » Thu, Aug 20, 2015, 3:43 PM UTC

voidlogic wrote: post #18

rubiquity wrote: post #13

Earlier quoted context omitted.

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.

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