Hacker News Reader

Comment by fxfan | Hacker News Reader

I don't get the wasm craze in the rust crowd. There is no popular language that cannot be compiled to wasm. It just feels sad to spend time there.

View on HN

Rust is particularly suited to WASM due to the lack of GC and runtime (which tend to be quite large, and have to be downloaded in a web context). And due to it being able to achieve very high performance (which is the whole point of WASM). The only other languages that really compete here are C and C++, and they don't have the great, easily installable library ecosystem that Rust has, and they aren't very accessible to JavaScript developers).

Personally I'm more excited about other uses of Rust, but I can see why people are excited about Rust and WASM.

You're talking about web technologies, and needing to download a runtime is the problem?

C++ isn't accessible but rust is? Only because they can't be bothered to learn: It complicated but its really not that hard.

Plug: D can happily compile to wasm

Well yes, the need to download a new runtime for every app you run is a problem if thst runtime is several megabytes.

C++ isn't accessible to web developers compared to Rust. It's not just that I can't be bothered to learn, it's that I'm scared of all the security vunerabilities and memory corruption bugs I will write while I'm learning. And wjy put in that effort when I can learn Rust more easily, and get the ongoing benefits of my code being safe and reliable.

True, D also competes here. I should probably have put D on the list. Although my understanding is that a large part of the D ecosystem still relies on GC.

Most runtimes are fairly small, and most issues could be done away with by either the browser storing common runtimes (Search for x, then checking hashes etc.) or by compiling statically against the parts you actually use.

This is still not conclusive, as the runtimes will probably have to be significantly modified (at the ABI/System level, so around the edges) given that they will have to get memory from the browser etc. This leaves much room for WASM specific optimisation, especially given that the actual (let's say) garbage collector implementation is probably quite small compared to the code used to interface to it.

Writing C++ defensively (i.e. Do what the guidelines tell you, Preach Andrei and Bjarne etc), and using sanitizers cleans up a huge amount of C++ code.

> Writing C++ defensively (i.e. Do what the guidelines tell you, Preach Andrei and Bjarne etc), and using sanitizers cleans up a huge amount of C++ code.

Well sure, but the joy of Rust is that I don't have to worry about any of that. I can write my code naively, and the compiler will throw an error if I do anything stupid.

> This is still not conclusive, as the runtimes will probably have to be significantly modified (at the ABI/System level, so around the edges) given that they will have to get memory from the browser etc. This leaves much room for WASM specific optimisation

Certainly if/when this happens, other languages will be a lot viable in the compile-to-wasm. But you can run Rust (and C/C++) in the WASM runtime without issues today. And Rust even has a number of high-level libraries which provide binding to JavaScript APIs (e.g. https://github.com/rustwasm/wasm-bindgen)

>they aren't very accessible to JavaScript developers

I wonder how Rust is more “accessible” to JS developers than C or even C++. If you find C too hard to comprehend, you’re definitely not ready for Rust...

As someone who learnt Rust after trying to learn C, I disagree. Basic C is easy. I could write a data structure. But as soon as you want to do anything useful, like parse command line arguments or use open gl, C becomes much more complicated.

Rust code is actually pretty similar to JavaScript code, in that I can pull in a library `cargo add regex`, and work with high level abstraction right away.

Of course, there are new concepts to learn, but the Rust book covers these pretty well (I've been unable to find similar documentation for C/C++ that doesn't run to hundreds of pages).

My observation is that many people learn C/C++ at university (where there is lot's of support for learning the arcane folk knowledge of "the right way" of doing things in those langauges), and subsequently find Rust hard, because it introduces new concepts, and doesn't work in the same vein as C/C++.

For those of us coming from higher level languages, Rust is much easier, because it provides guard rails and prompts us when we go wrong, and because once a few new concepts have been learnt, a lot of our existing concepts can still be applied.

I think the point is Rust is a very good language in its own right. The fact it compiles to WASM is a great feather in the cap.

They are able to deliver a demo in the browser for something that would normally require downloading and compiling. I think that’s pretty cool to show for a project people wouldn’t normally be able to try out with such low barrier of entry.

If this ended up making it possible to run Python in the web browser, that might be interesting to a fair number of people.

(There are advantages to running the same language on the server and client, and there's plenty of server-side web application Python code out there.)

>There are advantages to running the same language on the server and client

I see this said quite often. What are they?

Saving in developer salaries is the only tangible one. You could argue there is less context switching for developers between languages, but I’ve never actually heard that from someone who builds the apps.

To make sure the same bootcamp hacks can work on your backend and frontend, neither of which they fully understand.

If you have a traditional server-rendered web application and you want to add a little bit of scripting on the client side, it can be nice to be able to share pieces of domain-specific code (for example, you might want the client and server to have the same notion of what a well-formed stock code looks like).

In more sophisticated systems, people sometimes like the client to "optimistically" do the same processing as it expects the server to do, so it can update its display more quickly.

Or if you have a mostly client-side application which builds up some fancy widget tree, sometimes people like to have the server do the same rendering as the client would so that it's there on initial page load, or so that search engines can see it.

You often have the same data types on the server and the client for data exchange. When both sides use the same language, you only write these types once and it’s impossible for the client and server implementations to differ.

Not having to learn 2 languages and duplicate efforts for starters...

You mean like repl.it or skulpt or ... actually there's a few different option with different features, but doing python in the browser has been a thing for many years.

Running Python, client-side in the browser.

There are already various options, many using Emscripten.

There's already a client-side implementation of Python in JavaScript. See: https://brython.info/

But it might not give you the sort of compatibility between the client and server code that you're looking for.

I think it's less "the Rust crowd is excited about wasm" and more as "there is a crowd which is excited about doing certain things with languages and software, and Rust and wasm are both exciting means for those ends." Perhaps a good approximation is, they're both tools for using high-level programming techniques with high performance for domains that were previously constrained in terms of what languages you could use.

Most of the popular languages are not making a serious effort to compile to WebAssembly, though. It's totally reasonable for Rust to focus on.

Reply on news.ycombinator.com