I hope better alternatives will quickly become available, or at least some package where you don't to install a thing inside the thing you already downloaded and installed.
I hope better alternatives will quickly become available, or at least some package where you don't to install a thing inside the thing you already downloaded and installed.
This game logic in Rust was a good example of at least some communication with javascript in a non bloated way:
https://news.ycombinator.com/item?id=15843064 https://aochagavia.github.io/js/embedded-rocket.js
I wish I could just do `wasmcc -ofoo.wasm foo.c` and get a `foo.wasm` that I can include, without any implicit dependencies and such. Let me supply malloc if I call it. I'm sure there'd be libc-lite libraries in no time (if they aren't there already, I'm out of date).
Would it be either a G++ or clang++ module, but something a lot more straightforward and simple. No intermediary, no multiple dependencies. Either a simple compiler binary, and if not possible (although I still wonder why developer never release both source code AND binaries), provide a single downloadable repo that I can build using cmake.
I have read tutorials about binaryen and emscriptem, I did not have a fast computer nor a fast internet connexion, and it was so painful and unclear I gave up.
I get that asm.js was great, but it was mostly a hack, wasm should be much cleaner. I don't understand the choice of emscripten.
From the user's perspective, isn't emcc a C++ compiler that directly compiles to wasm? There are some internal IRs along the way, but you shouldn't notice them, like you don't notice the GIMPLE IR when using gcc?
The emscripten sdk isn't small, that's true, but that's because LLVM+clang are not small, plus the musl libc and libc++ are not small either. But all those pieces are necessary in order to provide emcc which can compile C++ to wasm. So it can't be just a single repo, multiple components are needed here - in fact, regardless of emscripten, more will be needed soon since the LLVM wasm backend will depend on the lld linker.
What we can maybe do to make this unavoidable complexity seem simpler, is to compile all the necessary things into wasm, and have a single repo containing those builds. So it would contain clang compiled to wasm, lld compiled to wasm, etc. Then the user would check out that one repo and have all the tools immediately usable, on any OS. The wasm builds would be a little slower than native ones, but perhaps the ease of use would justify that - what do you think?
In other words, the emscripten integration for those components is the easy work, the upstream LLVM/lld stuff is the hard part.
If half the effort wasted on C++ compilers and usage learning had been spent on something worthwhile...
I don't think C++ will fade away as it's already a well installed language, and it is getting several upgrades, which are supported by big companies.
There is really nothing comparable to C++ in terms of language, to be really honest. There really are no language which are as readable and flexible as C, AND extensible and high level.
I tried to get interested to statically compiled language like rust, go, D, and honestly I can't get used to them. Safety is not really a good idea because putting barriers between the compiler and the programmer will always result in pain. C++ is the ease of C with some syntactic sugar for more convenient use. I see nothing that can be as good as C in term of down-to-earth syntax.
A good language is not a language that is well designed, a good language is a language everyone can use. C++ to me seems to be the least worse, except of course the toolchain.
However, the end game is to be able to load a WebAssembly module just like you load a JS script. So, we are going to get there, but it will take some time.