Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Thursday, 9 January 2014 at 19:16:10 UTC, Paulo Pinto wrote:
> Every time I see such discussions, it reminds me when I started 
> coding in the mid-80s and the heresy of using languages like 
> Pascal and C dialects for microcomputers, instead of coding 
> everything in Assembly or Forth

If you insist on bringing up heresy...

Motorola 680xx is pretty nice compared to x86, although the 
AMD64bit mode is better than it was. 680xx feels almost like C, 
just better ;9, I think only MIPS is close in programmer 
friendlieness.  Forth is nice too, very minimalistic and quite 
powerful for the simplistic implementation. I had a Forth64 
module for my C64 to dabble with, a bit hard to create more than 
toy programs in Forth... Postscript is pretty close actually, and 
clean. But Forth is dense, so dense that you don't edit text 
files, you edit text screens...  But don't diss assembly, try to 
get more than 8 sprites and move sprites into the screen border 
without assembly, can't be done! High level languages, my ass, 
BASIC can't do that!

But hey, I am not arguing in favour of Forth and C (although I 
would argue in favour of 680xx and MIPS). I am arguing in favour 
of smart compilers that allow you to go low level at the top of 
the call stack where it matters (inner loops) without having to 
resort to a different language. D is close to that, so it is a 
promising candidate.

And... I actually think D is too lax in some areas. I don't think 
you should be allowed to call C/C++ without nailing down the 
pre/postconditions, basically describing what happens in terms of 
optimization constraints. I also want the programmer to be able 
to assert facts that the compiler fail to prove so that it can be 
used for optimization. Basically the ability to guide the 
optimizer so you don't have to resort to low level coding. I also 
think giving access to malloc is a bad idea. :-P

And well, I am not new to GC, I have actually used Simula quite a 
bit in classes/teaching newbies. Simula incidentally has exactly 
the same Garbage Collector that D has AFAIK.  I remember we had a 
1970s internal memo describing the garbage collector of Simula on 
the curriculum of the compiler course... So that is veeeery old 
news.

Actually Simula kinda has the same kind of string type 
representation that D has too. And OO. And it has coroutines… 
While it doesn't have templates, it does actually have name 
parameters that has textual substitution semantics (in addition 
to ref and value). Now I also kinda like that it has ":-" for 
reference assignment and ":=" for value assignment, but I didn't 
like it back then.

45 years later D merge Simula semantics with C (and some more 
stuff). And that is an interesting thing, of course.

But hey, no point in pretending that other people don't know what 
programming a GC high level language entails. If I want low 
latency, I go to C/C++ and hopefully D. If I want high level 
productivity I use whatever fits the bill… all GC languages. But 
I don't think D should be the first option in any non-speed area 
yet, so the GC is of limited use for now IMO. (In clusters you 
might want that though, speed+convenience but no need for low 
latency.)

I think D could pick up more good stuff from Python, like the 
array closures that allows you to succinctly transform arrays. 
Makes large portions of Python's standard library pointless.

What I really like about D is that the front end code appears to 
be quite readable. Take a look at clang and you will see the 
difference. So, I guess anyone with C++ knowledge has the 
opportunity to tune both syntax and semantics to their own liking 
and share it with others. That's pretty sweet (I'd like to try 
that one day).