Rust Is Surging Ahead in WebAssembly (For Now) | Hacker News Reader

Rust Is Surging Ahead in WebAssembly (For Now)

thenewstack.io

33 pointsamalinovic25 comments

In the words of the author, C++ is ("arguably") less complex and easier to use than Rust[1]. The guy should have been here yesterday when Conan and C++ modules were discussed... But then he'd need to know at least a bit of C++, which he doesn't. He doesn't know Rust, either. His programming language familiarity begins and ends with BASIC in high school (the bio under the article says).

Why is it that you need to know something to read about that, but you only need to be able to form senteces to write about it?

EDIT: [1] This is of course contrasted by the elegance of Rust's "Hello world".

... If you can make money writing code, would you do tech journalism instead?

... Yes? I make money writing code but I'd love to do tech journalism (no one would pay me money to read my stuff right now).

Sure, if I were interested in journalism. They're different sorts of things, and a ton of people don't decide what they want to do based solely on how much money they can earn doing it.

Yeah, what even is this article.

> The reasons are many, including significantly greater language support both historically and now, a better fit for computations inside WebAssembly modules, exceptionally lightweight and speedy for LLM (large language model), and other superlatives.

Why is Rust (a general purpose programming language) exceptionally suited for LLMs (which typically run on a GPU)? What major LLM projects even use Rust? Definitely not llama.cpp or ollama. They just had to slide in that buzzword.

Indeed while I'm sure Rust could eventually be useful in this space, last time I looked at the story for GPU-dev on Rust, it was still very very nascent. (Which is unfortunate because I'd like to play with that.)

I think both Candle and Hugging Face Text Generation Inference leverage Rust.

There's a whole genre of low-effort SEO articles that claim to answer the question "what programming language should I learn [in {year}|for {use case}]". This is just a thinly veiled entry into that genre.

It's not a genre that calls for nuance or even a little bit of understanding, you just need to make sure you use the right keywords to rank well for the query you're targeting.

I've been learning Rust, and so far anyway, I absolutely find it more complex and harder to use than C++ (which is saying something!) I'm hoping that Rust will become more sensible to me as I gain proficiency, but so far it's been thoroughly unpleasant.

I've also been learning Rust and have also struggled with it a bit more than I expected. It's not bad, but I do think there is a learning curve. I've struggled more with Rust than I typically do when learning new languages.

C++ benefits a little in that you can almost just use C++ as C, and I think part of the reason I struggled less with C++ when I used to play with it was that I didn't do the weird stuff. That's not to say that C++ complexity doesn't matter, but it might make the language more accessible to some people because they don't need to learn the weird stuff until they start looking at other people's code or using tutorials? I'm not sure I ever completely fully learned C++ as much as I learned C and the handful of C++ features that fixed some of the things that bothered me in C.

And with Rust there are concepts that (to me) feel harder to avoid. Rust (from what I've used) seems to be overall a much more elegant language than C++, but it feels like more of its complexity is front-loaded and that you run into difficult patterns that test your knowledge more quickly. That might just be my impression though, I'm tackling the two languages at different times of my life and I'm doing different things with them.

I've also been approaching it in a fairly unstructured way, and I know that some people recommend just sitting down and reading through the Rust book cover to cover. Which to be fair, is probably a faster way to learn it than just trying to build stuff with it and then learning new concepts as they're needed and when I run into errors and problems. My (again, very early) impression of Rust is that it feels more purposefully designed than a lot of other languages I've used, but I have a harder time intuiting what the purpose of everything is and a lot of the systems interlock with each other that seems to make them a bit harder to tackle one at a time -- so I suspect it benefits more from guided learning.

> but it feels like more of its complexity is front-loaded and that you run into difficult patterns that test your knowledge more quickly. That might just be my impression though, I'm tackling the two languages at different times of my life and I'm doing different things with them.

That’s exactly it. C++ will let you do things that are 100% wrong, or worse, occasionally wrong, and you have to “just know” how to do them right. Rust will absolutely refuse to compile until you’ve used the correct concept to solve the problem.

It doesn’t eliminate pure logic bugs, but it can vastly reduce the set of possible inputs and code paths to include a subset of possible failure modes you’d find in C++ code. Which would only be enforced by discipline or code reviews, and forces everyone to be consciously anal-retentive to avoid introducing subtle errors in the codebase.

In addition, a lot of C++’s additions have been more type-safe constructs to partially accomplish some of the safety in Rust, but it doesn’t have a way to drop additions. As a result, the “bad practice” solutions are the ones that got there first and are easiest to reach for, and the best practice solutions have more complex syntax.

For whatever reason, new C++ additions also seem to often be half-baked because support isn’t added to other parts of the STL that they interact with, even if it’s painfully obvious you would absolutely want to reach for those tools. For instance, the limited types supported by std::to_string, or hash tables not supporting tuples for multiple editions (haven’t checked C++23).

So yeah, if you stick to or start out with C++03, single-threaded programming, small codebase, it seems simpler. But once you start scaling the complexity of the code or the size of the codebase, or digging deeper into the language (I haven’t even mentioned template metaprogramming), you keep on encountering more and more complexity.

Whereas with Rust, if you’re writing it idiomatically anyway, the difficulty tends to plateau as (1) the language is in the background minimizing side effects and enforcing cross-module constraints so the volume of code you have to “just know” to safely work on something doesn’t scale with the codebase (2) your initial learning only consists of the modern best practices constructs, and after that additional learning tends to be more bite-sized.

When you factor in C++’s still-chaotic DIY buildscript, packaging, linting, formatting situation, the level of cognitive overhead for the parts of a practical C++ project that you actively have to manage tends to be far, far greater than Rust.

And some teams just throw up their hands and decide they aren’t even going to try to keep pace, and just negotiate some arbitrary point in the past they’re going to keep the codebase.

So the editorial comparisons between the safety of bleeding-edge modern C++ and Rust aren’t even really practically relevant, because a lot of teams fall off from how user-unfriendly C++ tooling and later editions wind up being.

The inability to attach a debugger is a dealbreaker for me:

https://rustwasm.github.io/docs/book/reference/debugging.htm...

Web-Assembly not returning cleared memory is an issue, but not a dealbreaker:

https://webassembly.github.io/spec/core/syntax/instructions....

Uhhhh I've been talking about this for almost a decade now but people just judge me as being noob. Debuggers are nice but if you're a platform jumper they're more of a nuisance than helpful. I'm a programmer who shifts platforms very frequently and oftentimes use niche platforms with very little tooling. Once you do that for a long time you develop muscles to abstract out computation in a more fundamental way. There is always compute, there is always memory (N layers of cache, perhaps RAM, disk, remote etc) and chances are there is always some sense/form of logs. But sometimes there is no way to attach debugger. If one day you're writing code for GPU and the next day the same code is parallelized to 3000 tiny ARM vCPUs, and the next day the same code runs in WebAssembly you'd much rather not waste time playing around with debuggers. This is all to say debuggers are more of a specialized tooling and exceptions rather than the rule. I think software engineers would find some benefit learning techniques such as tracing, canonical logs, debugging logs, ad-hoc printf debugging etc. Just because noobs also do it, doesn't mean experts can't do it.

I have no problem with being unable to use debugger in WebAssembly, my primary approach to debugging is observable outputs from the system:

* Return value

* Logs

* Side effects

* Integration tests, unit tests

I predict wasm is going to die if it can't use the dom or have better tooling and support.

It's an amazing tech but it's stagnating, it's quite sad.

I predict WASM is going to thrive and spread as a generic way of running complex plugins safely inside another piece of software.

I totally agree. This blog post from Aram Drevekenin : Build Zellij WebAssembly (Rust) Plugins for your Terminal[0] is well written and explain a way to achieve it.

[0] -- https://zellij.dev/news/new-plugin-system/

This is a take I don't actually agree with, on it's face, but I will say that even if we assume it's true that DOM access limitations are causing stagnation, I think most devs would prefer wasm to make the DOM unnecessary, rather than to couple anything tighter.

The DOM is kind of great for modeling documents, and quickly creating a form. As far as event driven design goes, it's very performant and accessible. But if you want to do anything that isn't vector graphics or form design, the entire browser stack can hold you back in varying ways.

Personally, I'm seeing a lot of potential in the wasm vector libraries, but I'm even more excited about shader-based, immediate mode guis. And honestly, the fact that you don't need a browser is a bonus, but definitely not the main selling point.

Your milage may vary, of course, but I'm very optimistic about what's coming with wasm!

Desktop apps (SDL et al) don't interact with DOM but they thrive. I don't agree with this take at all. I do however think WebAssembly implementations need to increase storage size, with the current 10MB localStorage in Firefox/Chrome and 5MB in Opera et al, web apps are almost completely memoryless without cloud. If you could use a web app as a standalone app with its own memory that you can download/upload/sync it'd be much more useful.

I see a lot of work around WASM lately with WASI and there are a lot of interesting implementations one example is wasi-cloud-core[1] it could open the doors for more services like wasmcloud.com.

[1] https://github.com/WebAssembly/wasi-cloud-core

Host object (such as DOM elements) support has been underway for a long long long long time. Component-model has been making ongoing progress towards this goal. It'll eventually happen.

IDK it seems that DOM access repeatedly gets deleted from the agenda. documents about the roadmap to web IDL have disappeared. web components want to solve a much bigger problem but seemingly no longer the issue itself, so I agree with OP.

The wasm idl (called WIT) is actively being worked on here: https://github.com/WebAssembly/component-model/blob/main/des...

Being able to access DOM is definitely an objective. It's just taking a lot longer than folks guessed to build a modular wasm ABI.

There's one very simple reason that imo explains at least a part of this: people interested in using one piece of recent technology are also interested in using another piece of recent technology.

To me C/C++ is the best, emscripten gives you a headsert that's unmatched, specially for games and desktop applications

https://web.dev/articles/ps-on-the-web

Rust is slowly getting there but there isn't much to port over to the web that's written in Rust, and when you want to start your project by being web first, then there are much better solutions

Poor quality article

Reply on news.ycombinator.com