Cheerp – A C/C++ compiler for web applications
leaningtech.com
leaningtech.com
Specifically does it compile faster, generates a smaller final .js output, or produce "faster" code ?
An integrated code minimizer is in the pipeline for release 1.1, and for the medium term we are working on an optimizer which cuts away unneeded libc++ initialization, which is preventing the dead code eliminator from pruning the non-useful libc++ code (which is a great part of that 1.7Mb).
So, expect big improvements in this area!
Disclaimer: I am one of Leaning Technologies founders.
Dynamic memory management. C++ objects are translated directly to JS objects, without the proxy of an emulated, flat memory space. Allow your applications to exploit the JavaScript VM garbage collector and co-exist with fair, on-demand memory allocation.
I don't think that's a good thing though, since the reason why emscripten compiled code is fast is because it has a flat memory space and doesn't create expensive JS objects.
Only advantage IMHO is that you don't need to allocate a big chunk of memory ahead of time (although I think emscripten still allows a growable heap as an option, but with a performance penalty).
http://mozakai.blogspot.co.uk/2013/11/c-to-javascript-emscri...
I may do a followup post now, since Cheerp is at 1.0. Seems like a good time to do some benchmarking.
Other than that, it's an interesting proposition and I look forward to trying it out.
The RPC feature sounds like it could be immensely useful for day-to-day web development. But the C/C++ is a deal-breaker for most web developers. Are there any projects that only do the RPC autogeneration stuff?
Also can frontend/backend code be shared (if there are no dependencies to the browser/unix system)?
Performance is a big reason people use C++, but there are many others. For example, people also write C++ when correctness is critical (bank software, safety-critical systems, etc.).
The vagaries of the standard aren't issues since safety critical software is validated on a per-platform and per-compiler basis. Memory safety is certainly a concern during the development process but more importantly (!) GC languages (like javascript and Scala) do not have provably (for some value of provably) deterministic execution times. Determinism is also a problem for lazy languages (like Haskell).
I say that to say the zero-cost abstractions of C++ is a huge benefit when writing safety-critical software. The level of control over emitted binaries is essential and fairly rare in programming languages.
> If they are really doing this, they have no idea what they are doing.
Well, I can't speak for entire industries, but that's a pretty sweeping generalization. You might be surprised what the challenges are when writing safety-critical systems software. That being said, I'm sure large portions of the industry are ripe for innovation.
This is not unique to GC languages, but any languages with dynamic memory management. C++ new/free and STL abstractions built on top are not provably deterministic either. And if you program without ever touching dynamic memory (statically allocating and pooling everything) then GC is not a concern.
> I say that to say the zero-cost abstractions of C++ is a huge benefit when writing safety-critical software.
You're talking about performance now, not correctness. All those benefits get lost once translated to JS.
That's probably true, but C++ does provide very powerful compile-time evaluation mechanisms like templates, constexpr (compile-time evaluated constants and functions), and template metaprogramming. That being said, compile-time C++ can look very gross since most of the features are accidental.
However, there are a lot of huge performance benefits to moving computation to compile time: selecting the most optimal algorithm for a type, guaranteeing you don't mismatch your units, precompiling search (glob, regex) engines, eliminating dead code, and so on.
So I would be shocked if at least some javascript applications couldn't be much faster and more correct by writing in C++ first and compiling to js. That being said, it's probably not in scope for a minimum-viable product, so improving already business-critical parts of the code base might be the best place to start.
If that was the case, http://asmjs.org/ wouldn't be a thing.
[0] https://code.google.com/p/v8/issues/detail?id=2599#c53
[1] http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html
asm.js does little for you if you write "real JS", but this thread is about cross-compiling other languages, which clearly has real world use.
But if I recall correctly, there are very good reasons why we don't have that in our browsers; security concerns maybe? Anyone?
Or http://hn.algolia.com, here I go again!
(What a great post, thanks for linking. Even though I follow mraleph on twitter, I had never opened his website. Probably because it all looks like scary compiler stuff.)
For example take something like Dropbox's Carousel architecture, which shares the client side cache, date model, and sync client between iOS and Android via a C++ library. Something like Cheerp or Emscripten allows you to also use this same library on the web.
I wouldn't write a web-only app in C++, but if the same code needs to run on other platforms as well (e.g. native mobile, desktop or gaming consoles) then C/C++ is basically the only choice. Also, at least in emscripten, compiled code is faster then hand-written JS for several reasons (asm.js, LLVM optimizer passes, no gc), so it makes sense to write stuff like physics/pathfinding/AI engines in C/C++ and compile it to JS.
Plus, it's fun to write a desktop OpenGL demo, flip a build system switch and run it in the browser ;)
The previous name, Duetto, made sense to me, since they compile to both client and server, so it's like two things running in harmony, which is a duet in music.
They're two different languages. The problem is that different people mean different things by "C/C++". Some people mean "C and C++"; others just seem to be unaware that they're distinct.
Neat project either way.
Erlang processing is slower than C by quite a bit but the reduced threading costs tends to make up for it when you are in a scenario where you need to serve multiple requests simultaneously.
On an apples to apples comparison well written C is going to beat erlang on this every time but once you start getting into threading, mutex locks etc. the equation starts to shift more towards Erlang favor _as long_ as each request you are serving is not highly computational in nature and would involve semaphores, and so on for thread management in c.