Hacker News new | past | comments | ask | show | jobs | submit login

The toolchain feels pretty clumsy and bloated, there are many intermediary stages that should be done automatically.

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.




Agreed since the toolchain is aimed at automatic conversion of C/C++ applications to WebAssembly, emulating filesystems, graphics etc, that makes it feel sluggish for me. At this point I haven't seen many people using WebAssembly directly to develop for the web. Mostly it's people who write to a canvas.

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


Agreed, back when I got the tooling up and running it generated a whole bunch of things to emulate stdio and such. I couldn't figure out how to make a freestanding wasm library.

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


What felt clumsy or bloated to you in the toolchain? We'd love to improve it, specific feedback would be very helpful.


I'd prefer a C++ compiler that directly compiles to wasm.

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.


I'd like to understand you better, I don't think I do yet.

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?


Incremental linking is something that most C++ toolchains support. Lacking it is currently our biggest pain point with emscripten. I'm very happy to be wrong, but my understanding is that it's hard to add that to emscripten because it's constructed using several different tools that have been chained together. I suspect a lighter-weight WASM-specific compiler backend would make standard C++ compiler features such as incremental linking significantly easier to do. Is that true?


Actually emscripten should be getting incremental linking soon. It depends on upstream components, the LLVM wasm backend and lld. Those are almost ready now.

In other words, the emscripten integration for those components is the easy work, the upstream LLVM/lld stuff is the hard part.


I really don’t understand the industry fixation with C++. It has to be one of the WORST (as in “error prone death trap”) computer languages ever devised. God how I wish it would fade away into obscurity.

If half the effort wasted on C++ compilers and usage learning had been spent on something worthwhile...


"There are languages people complain about, and languages nobody use." - Bjarne Stroutup.

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.


I agree. At the moment you can use WebAssembly, but it is not exactly user friendly. Effectively they have only build tools that can work inside other tools or as a part of an existing 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: