I have professionally come across many website backends that were developed in Javascript. Over time we are seeing projects that add more robustness, performance, and ability to support in the form of Typescript and now Deno.
With WASM becoming mainstream and the growing maturity of the Rust ecosystem, it appears to be a solid choice for backend systems and potentially emerging frontend use cases.
If they wanted something better for the backend (for robustness of performance reasons) there are other alternatives much better suited for the vast majority of backends. For instance, C#.
WASM is not needed for the backend, so that is not the reason either. For frontend, I can see it for some pages (I used it myself), yes, but there are also other languages that can target WASM.
You also mention maturity of Rust, but other languages in its domain are more mature, so that cannot be it either.
WASM is not required, but having a sandbox around native (e.g. Rust) code seems like a good idea, and it allows you to mix languages and opens other ecosystems.
No, it is not a good idea for backend where your processes and code are trusted because it does not come for free (it comes with a big performance penalty).
Mixing languages does not require WASM in native code either. It has always been done through the C ABI.
No process nor code is trusted in my company. The performance penalty is negligible compared to the multi-million risks, and WASM execution can be optimized a lot as it goes past MVP.
I don't know how to import a ES6 module using C ABI.
V8, JVM, CLR and others are well proven runtimes providing a well functioning sandbox, but of course we test a lot. I am sure you know what the risks are with native code - you're a native code proponent after all; any code running in a medium and bigger company that could misplace money is a huge liability.
I don't know what magic you're talking about - we're simply waiting for WASM to standardize GC, SIMD, tail calls etc, you can read more here[0]; and to get the execution optimized like V8 did over the past 10 years[1] (WASM on V8 gets most of these gains by default as a bonus).
I already said why I want WASM: because it provides a good sandbox and opens most ecosystems through safe and typed interop. I don't care about ES modules in particular - I care about ES modules, Ruby modules, Python modules, Prolog modules, Fortran modules, C modules, Rust modules, AssemblyScript modules, COBOL modules, Erlang modules, F# modules, Java modules, and so on - at once. Finally a future where I can use and trust any library and not get limited to the language I use (if I don't want to spend most of my time fighting and securing C ABI interop, if at all humanly possible) is there.
In that case: yes, we have a lot of JS people coming to Rust. The difference helps explain that too: if you’re going to learn something, learning something that’s very different from what you’re used to means you get more out of it than learning something similar.
When I decided I wanted to move away from Ruby, I didn’t even consider getting deeper into Python. Why would I? They’re so similar that the cost/benefit ratio is off, at least for me back then.
YMMV of course.
Oh and finally, not every bit of writing has to be extremely useful or hit a wide audience. Sometimes people write things because they want to.
Good points, but when I have done that, I always preferred to start fresh, rather than take a "shortcut" map from A to B.
The reason is that otherwise you always try to map things back to your previous knowledge and expertise, which can make you biased or give you tunnel vision.
Rust (and others like D, Ada, Zig...) won't be ubiquitous because it is a systems programming language intended to replace C and C++. This kind of languages are specialized and more costly to develop in them.
Everything else (the world of Java, C#, Go, Python, JavaScript, Swift, etc.), which is the majority of the programming done nowadays, will stay the same.
I don't think "more costly" is true across the board. I think it might be more a matter of taste, in terms of which costs you prefer. Rust is often higher-cost in terms of up front design and development time to get something working. But the resulting program might have lower costs in terms of debugging and downtime afterwards. This distinction is especially strong when the program is multithreaded.
Not really. Many other mainstream languages give you memory safety, strict type systems and overall robustness without having to deal with memory management or low-level details.
Even for parallelism this holds true. I would say it is even more pronounced there, in fact. Some high-level languages even come with simple, effective ways of doing parallelism without multithreading, which simplifies problems a lot.
Of course, they may not reach the top performance that C++ or Rust might, but that is the trade off. Performance vs. development cost.
It’s not that fantastic for low level systems programming due to garbage collection and the runtime. If you’re working with C et al, you’re generally doing something that requires extreme control, and Go is too high level to do that nicely - you can use it of course, but it’s just... weird.
C++ is not really a low level systems language because, very broadly speaking, low level stuff doesn’t benefit as much from the extreme flexibility and abstraction capabilities of C++. It’s used more as a high-performance application programming language for large, complex stuff. Go doesn’t fit that niche because it’s just not a very powerful language.
The niche where a simple language like Go is applicable for systems stuff without being too slow or high-level is extremely small. It’s a fantastic language for working on business-logic type stuff, web backends, etc, and excels when working with less experienced developers or larger teams. It’s as easy as python et al but actually has reasonable performance. But it’s not really a systems language for serious systems stuff.
Automatic heap allocation and garbage collection are big ones. People debate this endlessly, and it's true that undeniably-systems-ish software projects like Docker and CockroachDB are written in Go. But at the end of the day there will always be some systems that cannot be written in Go because of how it manages memory, which is not the case with C, C++, or Rust.
Well thats just like how one might say numpy is written in python, so portion of it certainly is but all the heavy lifing is done by C, the same goes for Docker. Docker is "just" an cli around cgroups which is a kernel feature written in again C.
It's not, not at all. We've actually gone as far as replacing RocksDB with https://github.com/cockroachdb/pebble/ by default now (and it's written in Go).
> - In your average Rust project, all dependencies are already built from source
That is only the case for open source code like crates.io, there is nothing that guarantees you will get the source code of a third-party, though.
I mention this because in the native world it is common to give customers precompiled libraries.
> - Already using LLVM as the compiler backend
Some people don't seem to know this, but all languages that target LLVM (including C, C++, Fortran, Ada, Julia, Swift and others) can be used in WebAssembly.
> all languages that target LLVM (including C, C++, Fortran, Ada, Julia, Swift and others) can be used in WebAssembly.
Having LLVM doesn't mean that webassembly Just Works, in the same way that having LLVM doesn't mean that all of its architectures Just Work. And even after getting past the "hello world" stage, there's a lot of other work to do to make it more than just a toy.
If you just want to run some computational code (which is the case for most of the Wasm use today), it will Just Work, as you say.
In fact, that is how I sped up a webpage: I just wrote myself the minimal support needed to run the code that computed X, and that's it. I don't want the entire world or standard library for computational bits to work.
The example I pointed out was for extra stuff, sure, but even just to get a compiler to spit things out, work needs to be done. I don't know Ada's compiler well enough to point to where that work is, but here's the initial implementation of the asmjs and wasm targets in rustc, for example https://github.com/rust-lang/rust/pull/36339
This is just true of any architecture. LLVM is a toolkit, it isn't magic.
