On 12/5/2013 7:27 AM, Paulo Pinto wrote:
> 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.

Although C and C++ are capable of extracting every ms out of the hardware as far as any compiled language goes, the number of programmers who are actually able to get those results are small. Just because someone writes a program in C or C++ doesn't at all mean that they're getting the most out of the machine.

Reminds me of when I worked in a metal shop at Caltech fabricating parts. I'd produce crummy, ugly things. The resident machinist, with the same milling machine, would tweak it here and there and produce things of beauty. (That old bridgeport milling machine had more knobs, levers, and wheels than a steam locomotive cockpit, and none of them were labelled.)

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

On Thursday, 5 December 2013 at 19:58:17 UTC, Walter Bright wrote:
> On 12/5/2013 7:27 AM, Paulo Pinto wrote:
>> 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.
>
> Although C and C++ are capable of extracting every ms out of the hardware as far as any compiled language goes, the number of programmers who are actually able to get those results are small. Just because someone writes a program in C or C++ doesn't at all mean that they're getting the most out of the machine.
>

Fully agree.

Additionally there seems to be a contiguous disease when using
those languages, where one tries to micro-optimize every code
line as it gets written.


--
Paulo

On 06/12/13 08:58, Paulo Pinto wrote:
> Additionally there seems to be a contiguous disease when using
> those languages, where one tries to micro-optimize every code
> line as it gets written.

In a way I think it's a disease that one has to go through with those languages, because in the end it usually leads to a few optimization insights (or "don't do this" insights) combined with the realization that it's much more productive to focus on algorithms and to let the compiler get on with its job, which it usually does better than any human.

On Thursday, 5 December 2013 at 15:24:31 UTC, Atila Neves wrote:
>> Interesting. Care to convert this post (only a little adjustment needed) to a blog and publish with source code? Would make a great article. Ask your friends to contribute with descriptions of their implementations, too.
>
> Ask, and you shall receive:
>
> https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/

"Go is an opinionated language"

It's funny, but I got the same impression after reading about it and looking at the syntax. One of D's advantages is - as I've said before - the freedom you have. When I first started with D, I did Java/Objective-C style things (classes etc.), and it was possible and worked well. As I went along I learned more about structs, templates and everything and I started to "think outside the box", because D is not opinionated. I enjoy coding much more now and it's good when a language gives you freedom instead of telling you what to do.

In Java:

1. Write a class
2. Now think ...

Objective-C:

1. Think, but write a class anyway.
2. Think how to bypass classes.

In D:

1. Think
2. Write a struct, class, template ... whatever is appropriate.

"In the end the choice of algorithm and data structures matter more than the programming language so my personal advice is to choose the language that makes you productive."

And D actually gives you a choice.

On Friday, 6 December 2013 at 07:58:46 UTC, Paulo Pinto wrote:
> On Thursday, 5 December 2013 at 19:58:17 UTC, Walter Bright wrote:
>> On 12/5/2013 7:27 AM, Paulo Pinto wrote:

>
> Additionally there seems to be a contiguous disease when using
> those languages, where one tries to micro-optimize every code
> line as it gets written.

add to that the optimization of number of keyboard strokes :D

On 06/12/13 16:52, eles wrote:
> add to that the optimization of number of keyboard strokes :D

Hah, I got burned by that once in a very amusing way.  I wrote a blog post comparing an existing C implementation of some data structures and algorithms (not mine) to my new D implementation.  One reader on Reddit assumed the terse variable names of the C code extracts (not mine!) must be representative of all the code in the blog post and refused to read past the first paragraph.

He was very nice when he realized his mistake, though. :-)

On Thursday, 5 December 2013 at 16:40:06 UTC, Andrei Alexandrescu wrote:
> On 12/5/13 7:46 AM, Dicebot wrote:
>> On Thursday, 5 December 2013 at 15:24:31 UTC, Atila Neves http://www.reddit.com/r/programming/comments/1s5ze3/benchmarking_d_vs_go_vs_erlang_vs_c_for_mqtt/
>
> https://news.ycombinator.com/item?id=6855278

This might be the first time that I consider the reddit comments of higher quality than HN. I completely left reddit for HN a few years ago, but in the last months I see myself drifting back.

Oh, and thanks for the great article. :)

Am 06.12.2013 16:52, schrieb eles:
> On Friday, 6 December 2013 at 07:58:46 UTC, Paulo Pinto wrote:
>> On Thursday, 5 December 2013 at 19:58:17 UTC, Walter Bright wrote:
>>> On 12/5/2013 7:27 AM, Paulo Pinto wrote:
>
>>
>> Additionally there seems to be a contiguous disease when using
>> those languages, where one tries to micro-optimize every code
>> line as it gets written.
>
> add to that the optimization of number of keyboard strokes :D
>

Canonical Go seems to suffer from that as well, in terms of variable names.