On Thursday, 5 December 2013 at 14:55:53 UTC, Jeff R. Allen wrote:
I am the buddy who's always going on and on about Go.
Here's the blog posting I made explaining why/how I made the
MQTT server in Go and what I learned:
http://blog.nella.org/mqtt-code-golf/
I was a bit surprised and interested to see that MQTT with
small transactions is not easy to optimize because kernel/user
context switching dominates the work that's done under control
of the programmer and which can be optimized via data
structures and/or reducing GC overhead.
Something that both Atila and I verified in this exercise is
that writing a fast network server that scales is so much
easier with a very good networking library that takes advantage
of lightweight threads, and with a runtime that provides GC.
This frees up the programmer to focus on the protocol logic,
and leave concurrency and bookkeeping in the capable hands of
the machine.
And, as has been mentioned on other Go versus D threads, a lot
of this is a matter of taste and team dynamics. I've worked on
many teams in my career where there was not a critical mass of
people who could reason correctly about C++ memory management,
and who could use generic programming techniques reliably. And,
in line with discoveries from psychological research, it's
common that people who are not competent at something do not
recognize that fact. Perhaps I'm above average in this regard:
I KNOW I'm not smart enough to write correct code using
templating techniques. :)
-jeff
Templates are easy. They are pure functions. You just need to
overcome idiosyncrasies introduced by people who thought they
were something else. ;)
