41–50 of 54 posts
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.
If anyone from Cheerp reads this, I use 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 ?
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...
I may do a followup post now, since Cheerp is at 1.0. Seems like a good time to do some benchmarking.
Earlier quoted context omitted.
I was replying to the statement: "For example, people also write C++ when correctness is critical". And I say if someone writes C++ in a correctness critical system, he must not know what he is doing. Even if you're using only STL, RAII and following all the good coding practices, there are still so many ways to screw things up, that C++ is among the worst choices in this regard.
Nasa and military don't know what they're doing? C++ is the go to language in mission critical systems.
"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/u…
If anyone from Cheerp reads this, I use 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 ?
I just ran the HelloClient.cpp from their example page [1] and the compiled file was 1.7 Mb [1] http://www.leaningtech.com/cheerp/examples/
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.
I know C and C++ pretty well; I wonder what this "C/C++" language is like.
I know C and C++ pretty well; I wonder what this "C/C++" language is like.
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.
Earlier quoted context omitted.
> 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.).
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.
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.
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.
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.
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.