D vs Go in real life, part 2. Also, Erlang.

[Paulo Pinto]

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



This is why we already did quite a few consultancy projects that
replaced C++ coded servers by JVM/.NET ones with comparable
performance.

Despite what many anti-GC naysayers say, if you code your data
strucutures and algorithms to be GC friendly, coupled with the
current state of art JIT compilers, one achieves similar
performance coupled with safety.

It doesn't need to extract every ms out of the hardware as C and
C++ developers always try to do, but to be fast enough to be able
to fulfill the task.

--
Paulo