AMD is notorious for not having ROCM support on in production currently sold GPUs, and horrendous bugs that actually make using the devices unusable.

I use AMD gpus on linux, I generally regret not just buying an Nvidia GPU purely because of AMDs lacklustre support for compute use cases in general.

Intel is still too new in the dGPU market to trust and on top of that there is so much uncertainty about whether that entire product line will disappear.

So at this point the CUDA moat makes is a non issue, on top of that what works works and keeps working, whereas with AMD I constantly wonder whether something will randomly not work after an update.

A timeline of decades for “features” your biggest consumers don’t care about is a reasonable tradeoff, even more so if actually pushing those features would reduce stability.

The entire point was that WASM just calls to the existing C functions, the ones you would call from literally any language.

If you care about memory safety then use a “memory safe” language that guarantees the exact same thing as what you thing WASM guarantees except without all the pointless overhead or running a sandboxed interpreter inside a sandboxed operating system process, it is actually just pointless complexity at that point.

For native development WASM gives no benefits, the only useful parts that WASM might bring literally hasn’t been standardised because it’s a real hard problem to solve and has no use in browser.

So wasm is designed for the browser and unless you only intend to embed a library in your existing JS application it is pointless because you are still restricted to the DOM.

Are you a product manager? Or do you just not see the irony on your comment?

Long term support means my thing that has been working great continues to work great. New feature implementation has nothing to do with that and is arguably directly against long term support.

And Nvidia seems justified in this since effectively no distro dropper X11 until Nvidia had support.

The discussion here was building bindings for the OS layer, which means to explicitlY worry about the client platform.

When using the web I have my own issues with that platform, or more specifically using wasm in it since it is literally useless for building web based applications over JS/TS. It is being targeted more as a library platform which gets called into from JS than being an actual “assembly “ language.

You understand why that is exactly pointless…

I could write those exact same bindings for my language that I will compile to wasm and then use the current WASI interface, but even that is pointless because at that point I have written a native app, what good reason would I need to run it through an emulator, specifically when a modern OS is already sandboxing things.

If I am targeting the browser my above point stands, unless the DOM is already a reasonably decent API for what needs to be built(it probably isn’t, it’s the best example you can get of horrible API design in my opinion) then I will need to build something ontop of that, prime example being react.

So I need to run my code in an interpreter, having built data structures to generate a document in an eDSL, which creates other data structures, which then calls into another API, which then calls into the OS/hardware layer.

When what I want to do, is call into the OS/hardware layer directly…