

Cheerp – A C/C++ compiler for web applications - multimillion
http://leaningtech.com/cheerp/blog/2014/08/11/Cheerp-1.0/

======
pierre-renaux
If anyone from Cheerp reads this, I use emscripten
([https://github.com/kripken/emscripten](https://github.com/kripken/emscripten))
at the moment, is Cheerp any better ?

Specifically does it compile faster, generates a smaller final .js output, or
produce "faster" code ?

~~~
dochtman
The Emscripten author wrote a blog post when Cheerp (then called duetto) was
first announced:

[http://mozakai.blogspot.co.uk/2013/11/c-to-javascript-
emscri...](http://mozakai.blogspot.co.uk/2013/11/c-to-javascript-emscripten-
mandreel-and.html)

~~~
azakai
As far as I know that comparison is still up to date, but if the Cheerp devs
are here maybe they can comment.

I may do a followup post now, since Cheerp is at 1.0. Seems like a good time
to do some benchmarking.

------
neuromancer2701
From my understanding it also allows you to write your front and back end in
one application and language. Then it compiles the front end to JS and the
backend to C++ executable. I think this is where a large advantage can be
seen. edit: it automates the connection between the front and backends tying
the two together.

------
adamnemecek
Reminds me of Wt [http://www.webtoolkit.eu/wt](http://www.webtoolkit.eu/wt)

------
jbarrow
This is somewhat off-topic but they turned user-scalability off, making it
impossible to zoom out (of the pre-zoomed in) mobile site.

Other than that, it's an interesting proposition and I look forward to trying
it out.

~~~
mx267
Thanks for the report, we have fixed that issue today.

------
ksikka
"Cheerp compiles to native binary code backend, JavaScript frontend, and
automatically generates RPC communication code"

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)?

~~~
mx267
Yes, code without client- or server-specific dependencies can be shared.

------
Kip9000
I wonder what advantages choosing C++ to write web apps would bring. At the
end of the day it's all JavaScript so performance is rather moot point.

~~~
Touche
That's actually not true. Emscripten compiles to code that is much faster than
hand-written JavaScript. In this case they are not using Emscripten or a
similar technique but are compiling to regular old JavaScript, so performance
probably is the same, rather this might be for people who just like C++, like
what GWT is for Java devs.

~~~
Kip9000
You misunderstood. People mostly write with C++ when performance is critical.
Why? C++ offers deterministic memory management, Specialize to CPU instruction
set and better use of CPU caches etc. Those performance benefits would not
translate when you cross compile to something like JavaScript. I get the point
about converting the legacy desktop apps to web apps, but how would it handle
the architectural differences ( Desktop apps don't scale)

~~~
humanrebar
> People mostly write with C++ when performance is critical.

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

~~~
pkolaczk
Writing for correctness in a language with no memory-safety, weak type system
and, till not very long ago, no standardized memory-model, and UB in every
other paragraph of the specs? Good joke. If they are really doing this, they
have no idea what they are doing. There are plenty of languages better for
safety-critical systems than C++; even widely hated, boring Java is much
better.

~~~
humanrebar
It's a bit off topic, but I'm being descriptive (based on professional
experience) and not normative when I say C++ (and C and Ada) are used for
safety-critical software. Javascript and functional languages certainly
aren't.

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.

~~~
pkolaczk
> GC languages (like javascript and Scala) do not have provably (for some
> value of provably) deterministic execution times

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.

------
shmerl
A different idea, but still an interesting C++ Web development framework:
[http://cppcms.com](http://cppcms.com)

------
azakai
I'm a bit puzzled by the rebranding. First of all, the logo and the name sound
a bit similar to Twitter. And I'm not sure what bird noises have to do with a
compiler?

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.

------
_kst_
I know C and C++ pretty well; I wonder what this "C/C++" language is like.

~~~
pmelendez
The subset that is the interception of both? which would be a subset of C.
(Although I am pretty sure that wasn't what the author had in mind)

~~~
oso2k
Bjarne has always maintained that C++ is (mostly) backwards compatible with C.
And that's what most people mean by C/C++.

~~~
_kst_
I know that C++ is mostly, but not entirely, backwards compatible with C. That
doesn't answer the question of what "C/C++" means.

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.

~~~
multimillion
Cheerp, like clang (upon which it is based), can compile both C and C++ files.

------
keithnoizu
Interesting although if you want massive performance on a web application i'd
probably vie for erlang unless you're doing something computationally complex
on the backend. It would be nice to be able to write code once and use in
multiple places but theres often so much extra work involved in that, that for
many applications it makes more sense to just use interfaces etc.

Neat project either way.

~~~
farresito
If you want massive performance, you most likely want to avoid erlang; if you
want massive scalability, erlang might very well be a great fit. I think it's
quite different.

~~~
keithnoizu
Performance in terms of request throughput you can serve per minute for some
given set of CPU and RAM.

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.

