wasm isn't super mature now tho afaik
I agree. But things mature as they are used and abused. Some of us are early adopters, out of enthusiasm and love.
and it's not really something you write yourself, but you compile whatever shit you have to wasm
Someone has to write those compilers.
right now only non-GC PLs can do that well, i.e. rust, c, c++
I don't know the veracity of this claim but surely this list proves otherwise:
https://github.com/appcypher/awesome-wasm-langs/blob/master/README.mdThe commentary on the maturity of these backends is purely opinion, btw.
but you want your web shit to be in a safe language, which only leaves rust
This is a religious definition of safe that conveniently excludes every programming language but Rust. I can tell you that I have been using Rust since mid 2014 and the meaning of safe is specifically "memory safety", and "concurrency safety", but only the specific kind of protection against concurrency that results in memory errors, not actual concurrency issues like resource contention, deadlocking, livelocking, and protocol adherence. My experience is that
1) systems programmers who have already committed themselves to a language like C or Rust don't, in practice, actually make the kinds of memory usage errors that Rust protects you against (buffer overruns? returning references to stack frame data? who does this?) and
2) Rust is woefully insufficient for a lot of the systems programming that people actually do. To date, there is still no stable interface for allocating n bytes from the heap. (The HEAP global constant is still feature gated and nightly only). There is still no way to write generics over constant integers, which is one of the most useful ways to use templates in c++. The (ab)use of tagged unions makes the tag opaque, which is totally insufficient for a robust system that might need to check for memory corruption (unsafe unions were a very recent addition). Iterators are by reference because the language has been inflicted with C++'s RAII madness, but there is no by value iterator which is what I'd actually want for writing byte or char stream manipulators. Conditional error handling barely exists (if let is a monstrosity). There is no &out. Etc.
in the future wasm will support GCs so you can use more PLs to compile to wasm but probably none will be as efficient as rust
There is some difficulty currently in implementing precise collectors over the truly braindead design of the stack machine architecture. The stack is not inspectable at all, so you have no idea if references to objects still exist. But the simplest way to overcome this is to simply write your own stack in linear memory, or write a "shadow stack" in linear memory for such values that might escape the lexical extent of the function call (such escape analysis is par for any basic compiler already, i.e. in the stack allocation of closures or small lists). This second implementation is especially interesting because it still exposes small, data churning web assembly routines to JIT compilation by the VM (which is the primary benefit of not having an inspectable stack).
i think you can write wasm directly, but it's kind of like assembly, not very practical for writing large apps
A large application, no, but I just wrote a small implementation of malloc in web assembly last night because I didn't want to have to figure out how to link to a libc web assembly module and it wasn't so difficult at all. Didn't have to think about registers or anything. I would recommend that any junior developer should implement malloc at least once so that they understand what they are saying when they claim "garbage collection" is "slow", and also understand why malloc is also slow and potentially slower for specific use cases.