34
Dante83
16d

WASM was a mistake. I just wanted to learn C++ and have fast code on the web. Everyone praised it. No one mentioned that it would double or quadruple my development time. That it would cause me to curse repeatedly at the screen until I wanted to harm myself.

The problem was never C++, which was a respectable if long-winded language. No no no. The problem was the lack of support for 'objects' or 'arrays' as parameters or return types. Anything of any complexity lives on one giant Float32Array which must surely bring a look of disgust from every programmer on this muddy rock. That is, one single array variable that you re-use for EVERYTHING.

Have a color? Throw it on the array. 10 floats in an object? Push it on the array - and split off the two bools via dependency injection (why do I have 3-4 line function parameter lists?!). Have an image with 1,000,000 floats? Drop it in the array. Want to return an array? Provide a malloc ptr into the code and write to it, then read from that location in JS after running the function, modifying the array as a side effect.

My- hahaha, my web worker has two images it's working with, calculations for all the planets, sun and moon in the solar system, and bunch of other calculations I wanted offloaded from the main thread... they all live in ONE GIANT ARRAY. LMFAO.If I want to find an element? I have to know exactly where to look or else, good luck finding it among the millions of numbers on that thing.

And of course, if you work with these, you put them in loops. Then you can have the joys of off-by-one errors that not only result in bad results in the returned array, but inexplicable errors in which code you haven't even touched suddenly has bad values. I've had entire functions suddenly explode with random errors because I accidentally overwrote the wrong section of that float array. Not like, the variable the function was using was wrong. No. WASM acted like the function didn't even exist and it didn't know why. Because, somehow, the function ALSO lived on that Float32Array.

And because you're using WASM to be fast, you're typically trying to overwrite things that do O(N) operations or more. NO ONE is going to use this return a + b. One off functions just aren't worth programming in WASM. Worst of all, debugging this is often a matter of writing print and console.log statements everywhere, to try and 'eat' the whole array at once to find out what portion got corrupted or is broke. Or comment out your code line by line to see what in forsaken 9 circles of coding hell caused your problem. It's like debugging blind in a strange and overgrown forest of code that you don't even recognize because most of it is there to satisfy the needs of WASM.

And because it takes so long to debug, it takes a massively long time to create things, and by the time you're done, the dependent package you're building for has 'moved on' and find you suddenly need to update a bunch of crap when you're not even finished. All of this, purely because of a horribly designed technology.

And do they have sympathy for you for forcing you to update all this stuff? No. They don't owe you sympathy, and god forbid they give you any. You are a developer and so it is your duty to suffer - for some kind of karma.

I wanted to love WASM, but screw that thing, it's horrible errors and most of all, the WASM heap32.

Comments
  • 7
    I am slowly clapping at how beautiful this is.WELCOME TO DEVRANT!
  • 3
    Welcome to devRant! Amazing first rant. You will fit in well here. 😊

    WASM also sounds horribly designed. Instead of a function returning a value or pointer, it returns the entire bloody heap? What the fuck!
  • 11
    Wasm by it self is literally a form of assembly.

    So how well it works with your language depends on the way the compiler is set up.

    If you have something that transforms high level constructs to that array format its not so difficulty but as you said, C++ integration seems to favor maximum speed with no qol things that take extra performance.

    Here is a thorough breakdown on types and why this is hard.

    https://hacks.mozilla.org/2019/08/...

    In c# for example, ms decided to more or less build a full il runtime for wasm so any c# type can be used.

    This takes extra memory and is slower than hand optimized c++ but also very much easier and faster than most js code due to better optimization in wasm.

    More solutions will probably come but all will probably come at an performance cost.

    But read a bit about this, it might help

    https://emscripten.org/docs/...
  • 2
    Welcome, and nice first rant!

    Btw., the "devrant" tag is only meant for things around devrant.com itself. We're only devs here, so every rant is a "developer rant".
  • 1
    Welcome to devRant! I love your spirit.

    Though. WASM is a form of Assembly... Assembly is indeed hard, but that’s why I love it. Though, if you want to make something quick, please don’t write in this... it’s foolish to try.
  • 1
    isn't wasm still considered half baked though ? Im excited to eventually see some fully baked c++ web solutions that common joe (me) can get up and running with in a few days.
Add Comment