Duetto: a C++ compiler for the Web going beyond Emscripten and Node.js

In my honest opinion, C++ needs to separate low level concerns from high level constructs. How variables are captured in lexical closures is a very low-level concern, but lexical closures are a high-level construct -- by mixing in such low-level details, the overall utility of closures in C++ is reduced. This is made even worse by the fact that the programmer must manually maintain the lexical environment of the closure -- and the new "smart pointers" are only marginally helpful, not nearly as robust as a modern garbage collector (which can, oddly enough, improve performance).

C++ could be a really great language if these things were better separated. I write my code in Lisp, and when I have low-level needs I usually have to write some C code and use an FFI. It gets the job done but it is awful to debug and there is a performance hit. C++ is in a much better position: you can write low-level code, or you can write high-level code, or both, and no language barriers need to be crossed (reducing costs in various places).

"As for the reason why non-C++ programmers don't like C++, perhaps you are in a better position to say."

Well, aside from what I mentioned above, I can give you one more: extending the language. You have a few narrow ways to do it, and then you are just stuck. Operator overloading is great, but what if you want to add a new operator? What if you want to change how your type checker works, so that you can have a dependent type system? There are a few hacks that people can do with templates, but on the whole adding a new feature basically means rewriting your compiler (see e.g. what it took to get support for lexical closures), and C++ compilers are pretty hard to write in the first place. This is something of a Lisper gripe, though there are a few languages beyond Lisp that allow programmers to add new syntax or semantics.

Anyways, lest you think my observation is just a "non-constructive comment":

The great thing about the browser is that it is free of a lot of garbage we have to deal with in C++. The antics required to make C++ work in the browser, while laudable, are absurd.

If you need cross-platform code, write in Java and avoid native extensions.

If you need cross-platform code that has to be fast (i.e., you actually need to have inline assembly), write in C or C++ and actually do your proper cross-platform work (proper abstraction of I/O, proper defines, proper selection of types, etc.).

If you need to draw shit in the browser, use the wonderful ecosystem of tools that have evolved using the standard affordances of Javascript and CSS.

Here are the bits I take issue with:

"write web appli­ca­tions in C++, reusing exist­ing code and mak­ing port­ing of whole appli­ca­tions and games to the browser plausible."

Why? What type of code is worth reusing? What type of performance is this going to get me?

Most C++ codebases are janky and sad--game engines being some of the worst offenders.

" code both the fron­tend and the back­end of a web appli­ca­tion in the same lan­guage and codebase "

Why the fuck would you ever want to use C++ as that language? It's terrible, so much so in fact that it lost out to PHP and Perl.

Let that sink in for a second.

People said, "I would really like a language that's easier to work in!" and then picked PHP and Perl. PHP and Perl.

Moreover, go look at their docs:

http://www.leaningtech.com/duetto/examples/

" Duetto does not attempt at emulating numerical types which are not supported by JavaScript float is supported with 64-bit precision, like double. long long is defined as a 32-bit integer. 64-bit integers are not supported at all in JavaScript and duetto does not attempt to emulate them."

Well thank Christ we never will need numerical types not in Javascript--I mean, I've never used bit-twiddling in my engine code, or my decompression code, or my audio code.

~

Look, it's a really cool use of LLVM, but we don't need C++ in the browser.

I saw this sort of thing first-hand when I TA'd a data structures course taught in C++, when a student came to me asking for help with some very bizarre behavior: a member function was being called for an object that had never been allocated. The problem was that the student had forgotten to write a return statement (why is that even allowed? compilers can obvious detect this, since using -Wall picked it up), and a virtual destructor call had been inserted, but the vtbl for some other object was sitting there and so some other member function for an unrelated class was called.

So while you are sitting there trying to figure out if your class members are aligned optimally, your C++ compiler is inserting function calls and not letting you know about it. If it were just a few implicit calls or copies, it would not be a big deal, but C++ is a huge, complicated language with lots of such things.

Basically, almost everything you mentioned is a low-level concern for which high-level constructs are just a distraction. The point of high-level programming is to direct programmer effort away from such things (hence the implicit function calls and copies, etc.). If you want to program at a low level, fine -- but my point was that in C++, low-level and high-level programming are too tightly coupled.

Finally, it is worth pointing out that this:

"copying to enable concurrency are all real things."

Is not something C++ has any kind of advantage in. I do it in Lisp all the time. You see it in functional programming languages all the time.