Can Rust Beat JavaScript in 2023?
joshuamo876.bearblog.dev
joshuamo876.bearblog.dev
First CoffeeScript, then Flow and TypeScript, then ReasonML, and now Rust with WASM & web macros.
Of these only TypeScript has been successful, partly because it's backed by Microsoft, but mostly because the code you end up writing is very close to JavaScript.
This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024.
- Instant hot reload of application
- Inspect app/page structure in runtime
- Runtime debugging
- Monitor all network requests
- Tools to monitor time spent in functions, painting, redrawing...
- Runtime changes instantly applied
...
And now there is essentially one browser who can afford such complexity. Until Google discontinues it.
That's a feature, not a bug, as open source browsers have loosened the importance of the operating system (freed us from the MS monopoly) and enabled an multi trillion dollar web app industry to flourish.
If Google ever discontinued Chrome support it would be picked up by the community in a flash. That's the beauty of open source.
Of course it wouldn't. The number of people capable of managing and developing a full-blown browser is minuscule. Even Microsoft gave up and went with Chrome in the end.
Case in point: how many people picked up Servo? Hell, even Firefox?
Source: https://archive.is/tgIH9
What Google is doing isn't much different from the MS from the 90's, except that they didn't stop improving their browser. At least yet.
Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
Yes it really is how it works. You see, Chromium is used by numerous teams and products already. Developers from these projects already contribute support and patches to Chromium on the regular. That's exactly how open source development works.
> Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
Microsoft (especially Ballmer era MS) sucks at a number of things. That internet explorer was a bloated piece of trash beyond all repair is hardly an indication that browser development is beyond the capabilities of an open source community. It wasn't that it was "too expensive" for Microsoft to maintain IE. It's just that IE could not possibly compete with Chromium, because they were saddled with too much technical debt from years of bad decisions.
Entire operating systems and databases are maintained by open source foundations. Have you ever heard of Linux? MS cannot compete with Linux at the server game. They waved the white flag on that battle a long time ago as well.
Besides, when you fork a project, you don't have to instantly rebuild everything from scratch. A foundation would kick things off by prioritizing bug patches, security fixes, etc. The RFC process for deciding new web features is already handled by a consortium: https://www.w3.org/
With Firefox there is even a viable alternative that isn't controlled by Google in any form. I'd agree on many projects that would be the case. For Chrome, no.
But last I checked Firefox is still very much maintained by Mozilla.
Why doesn't community pick other browsers in a flash?
We have plenty of examples of open source databases, operating systems, libraries and languages leaving the major companies they were created at and being scooped up by a foundation or consortium to maintain.
WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
But there's plenty of other examples in the open source world. Chromium is far too important, and there's already thousands of eyeballs on that code base. There would be a Chromium Foundation established very quickly if Google abandoned.
We have just as many left to die. We just don't know or don't talk about them anymore.
> WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
Ah. So the mythical "community" that will scoop in and continue developing is a compani with a 60-billion yearly revenue. Got it.
> Chromium is far too important, and there's already thousands of eyeballs on that code base.
Eyeballs rarely, if ever, translate into understanding the codebase, or being able to do anything about it.
> There would be a Chromium Foundation established very quickly if Google abandoned.
Can I interest you in Apache Foundation where great amazing projects no longer supported by their original company go to slowly slide into oblivion?
Yes, irrelevant products that no one uses eventually die. At present, Chromium is not one of those, and is installed on billions of devices and used every single day on mobile and on desktop. Entire businesses and derivative ecosystems have been built on top of Chromium (Edge, Brave, Node.js and all of its dependencies, Electron, etc.). If there's an economic incentive to keep an open source product going, it will keep going. Anyway, here's the repo if you're interested in contributing: https://github.com/chromium/chromium
Browsers cost a bunch to develop. Just CI for Servo was 10k per year.
While there are some admirable efforts (Ladybird), browsers complexity means your only specification is Chrome source code.
Flame charts in Visual Studio 2003? Sorry, try again.
I get F5 to refresh the page when source code changes. All the other tooling remains the same: https://developer.chrome.com/docs/devtools/
I mean, Chrome even has an animations debugger
Really? That's surprising but so overkill. How does it know what files to poll and which not to, I assume file:// and localhost but more specific? Does it do it for a webpack/vite app which has its own hot reloading setup?
F5 refreshes the browser page. This has been the way to develop pages since the first browsers.
And the original question was "Import a plain js file without any node tooling and see what you get for free." You don't get hot reloading but you get all I wrote in my original comment and much more for free.
It usually goes something like this: some tool watches the file system for changes > trigger build > another tool in the chain injects changes into session > picked up by client to reflect changes, if done well without resetting state.
These are many tools in a toolchain working well together. This DOES exist in other languages, incremental builds exists. You can save and restore a binary at a certain state, and it's less hassle than it is in js.
One thing the systems development world has that I haven't seen in browser tools is radare/ghidra to follow code paths but it probably exists as a browser extension. The web is just reinventing and repackaging tools that have existed for decades.
> you get all I wrote in my original comment and much more for free
Yes, but `apt install gdb` is just as "free" as `apt install chrome` no? Everything you mentioned exists in systems development, you just haven't used it.
I could probably set up a simple environment to watch for changes, run make, reload the binary at $current_state in gdb with a one-liner. But it doesn't really fit the work flow, and GDB already gets all changes after I run make.
I think Rust has all of that except the hot reload and runtime changes.
Instant hot reloading? Runtime introspection into apps, and into strucutre of the apps, direct view into what the app sends over the network etc.? Open up development tools in your favorite browser, you'll be surprised :)
But the web is definitely the most used “GUI framework” ever, so there is no competition with that on tooling ground, even if there is nothing inherently that would block it, as a dom inspection is pretty easy to implement - just print out the tree of ui nodes.
Don't get me wrong the web pays my bills and I like it but there's no point exaggerating.
"Can be achieved" with some additional tools. I doubt you can easily expect the structure of the app, how it repaints, see all the relevant network requests, and also introspect and query the running app, emulate various hardware, inspect and debug animations etc. in most languages.
Yes, there are collections of tools that may give you all that in aggregate, but frankly, it's not close to an "out-of-the-box" experience.
> there's no point exaggerating.
It's not really exaggeration.
Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. It seems you don't have much experience in the tools you're comparing against. In GDB you would connect to a running application on actual hardware or in a VM, if that's what you're testing. Screen sizes and network can be done locally.
As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser so it's still an "aggregate" as you like to call it.
For me it's the unixy way of doing things and just the way I like it. Do one thing and do it well.
I've used debuggers in general (IDEA, Resharper, Visual Studio), and even dabbled with disassemblers like IDA in my youth.
> Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference.
So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).
And can emulate performance with different number of processor cores. Not bad https://developer.chrome.com/docs/devtools/performance/refer...
> As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser
Wat. The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". So yes, hot loading is a part of tooling. I've yet to see anything outside the web manage hot reloading with any degree of confidence and speed.
You don't like the hot loading, and let's focus on non-moved non-goal non-posts. I hope you noticed the ellipsis at the end of my list?
What's that immediately available tool for GDB and Wireshark whatever that:
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
- examine and debug animations?
- analyze paint/re-paint performance?
- view and debug delayed background actions?
- record and replay user flows?
...
^ Note the ellipsis again.
The build tools for Web are undoubtedly atrocious. However, there are very few, if any, tools that come even close to the versatility and ease of use of the tools that exist for the web ecosystem.
The linux kernel has KVM, doesn't get more out of the box than that. Do what you want with it. Emulate ARM? Sure why not.
> The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling".
Not my comment, I'm addressing your claim of "tooling most languages can't even dream of". The ellipsis doesn't really matter I'm not here to guess what you're meaning.
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
Most debuggers including GDB can print and set state.
> - examine and debug animations?
> - analyze paint/re-paint performance?
I don't do GUI development but you'll have to use a tool specific to the environment you're working with (just like how the DOM is a specific environment). What tool do you use to debug webview? Not your main browser. Systems development is the same.
> - view and debug delayed background actions?
You can get the time spent on anything down to individual assembly instructions if you wish.
> - record and replay user flows?
rr (which is GDB compliant hence integrates well with termdebug in vim).
I don't disagree that there are many tools for web dev. But they're not always better or easier to use. The built-in nodejs debugger is shit compared to GDB for example. My point is that everything you can do in browsers that aren't browser specific exists for other languages as well. Many times very specialized with better features that the devtools version.
Again, I love web development, but I also live in the terminal and love those tools even more. I wish they existed for the web.
> It was just an exploration to see if there was anything we were missing out on.
Doesn't square with this:
> At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.
Reads like rust exceptionalism.
IMHO, the more interesting niche is desktop/mobile apps using html as a toolkit. Because here you can combine raw computing/resource access with being more cross platform.
No one is even close.
Anders Hejlsberg, lead architect of C# and creator of Delphi and Turbo Pascal, has worked on the development of TypeScript.
Recent cool developments on that side include Electric Clojure - generating transparently state passing front and backend code from a single DSL: https://github.com/hyperfiddle/electric
Why? Rust has a bunch of features built in to promote "good code", no?
My theory is that, you probably can see when a language its being picked by some community by looking into courses available, either free or on paid platforms
Not quite sure what you mean. I've written some pretty cool stuff in Rust and never had to do any free() / drop()?
Though a more objective distinction is hard to give on what is a managed language, I found the garbage collection handbooks’ quote on the topic the most illuminating (linking to my older comment): https://news.ycombinator.com/item?id=35332600
In Rust and in C++ memory layout is part of your public APIs and has to be refactored when it changes. This is not the case with managed languages.
It's not really that; it's really just WASM. There's going to be a flood of this sort of thing from all sorts of languages, even multiple per language. It's early days yet and the ground is still being felt out, but eventually the Javascript qua Javascript foundation in the browser is going to be breached and a day will come when it is a minority language (still many years from now), for exactly the same reason that never in the whole history of computing has one general purpose programming language "won". Per https://www.destroyallsoftware.com/talks/the-birth-and-death... , Javascript is going to "win", but it's going to be Javascript in its incarnation as WASM, not the Javascript we know today.
"random bits of Rust in 2024."
And that's "the ground being felt out", not a fundamental problem. I expect to see WASM frameworks develop that are shipped out to the world as WASM and bind to any language. Decent odds they'll be developed in Rust for several reasons (performance not least of all), but you won't need to know that to use it in your Python WASM front-end app or some new WASM-primary language that is nothing more than a gleam in its creator's eye right now. If you don't want the chaos, hey, great. Even people who live on the cutting edge can't be cutting edge in every dimension. By all means sit back and watch from a distance. But these problems will certainly be fixed.
In some cases that complexity is worth it — Figma, for example, squeezes a lot of value from WASM. I myself have used WASM to create a browser-based testing environment for a Rust-based static analysis tool I’ve built, so my colleagues can quickly repro issues. But for most web development, it’s not worth it.
To put it another way, no, you're not wrong, and yes, the resistance to large-scale changes to the web stack is huge, arguably the largest resistance of all time. Nevertheless, the amount of metaphorical amperage flowing through is even larger and is large enough that it is already "short circuiting" and blasting a new circuit through. It's going to take a while, and the backwards compatibility will be with us for a while, but we're already seeing flashes of websites where you don't need to know the old CSS and HTML and such because they're actually WebGL and WASM. As more capabilities are exposed to WASM and they become more efficient, more and more stuff will be moved into it.
That will cause its own explosion problem, but it'll be handled. It's not like every website is going to write its own bespoke text renderer every single time. And in the end there are some technologies that will fade out and become legacy, then irrelevant. I may yet outlive the HTML/CSS/JS stack.
Yes, I can see the advantage of rewriting those layers in terms of the lower level APIs, for example if the DOM API were to implemented in WASM, you could keep it out of the browser, and download only when/where needed (with a number of caveats, of course)...
The main issue is that even if you do that, I don't expect an API designed with JS in mind to be a good fit for Rust, and vice versa. The risk is that you end up programming not against the "Web Platform", but "WebJS platform", "WebRust Platform" etc."
Neither one is a different language. Both merely add type annotations to an otherwise pristine ECMAScript code base.
Typescript has some very few and minor and no longer needed things, like enums or namespaces, that need to be transpiled and are not part of ECMAScript. But again, those are minor and you no longer need them (since ES 2015 one can use modules instead of namespaces, and marked "as const" object literals instead of enums).
I know some people want to argue definitions, "different language" etc., but it's really just a completely optional tooling layer that you can just strip. It's also evaluated purely during development time, for type checks, the actual code that gets executed remains the ECMAScript part.
Whenever there are changes in a new Typescript version it's either purely within the type system, or they add type support for new ECMAScript features, those proposals that reached stage 3.
You could just imagine the type annotations in a different layer than the actual code, like in Photoshop. A layer used only by the IDE and code checking tools.
Microsoft added greatly to the confusion by putting the type checker, like eslint usable standalone or continuously queried through the IDE, and the type annotation files (.d.ts) generation and the completely optional .js file transformation AND .js file transpilation - backwards compatible JS code for earlier runtimes - into one tool. But all of those are different things. If your traget is "esnext" or you don't use JS features that your target runtime does not yet support transpilation is just removal of type annotations (except, enums, namespaces, which are no longer necessary and only exist for historical pre ES2015 reasons).
This isn’t really a matter of debate — Microsoft describes TypeScript as a programming language distinct from JavaScript on its homepage.
It’s a programming language with a trivial transpiration step to another language, but a separate language all the same.
Oh and here is what it ACTUALLY says on the Typescript page (https://www.typescriptlang.org/):
> TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.
None of that contradicts anything I wrote.
Same thing for a Rust replacement for VSCode -- I am sure it is an interesting project, but VSCode performance is generally good enough (I don't ever complain about slowness while developing). A lot of the performance bottleneck comes from the language services anyway. If you improve the loading speed from 2s to .2s that is definitely great, but if at the cost of losing most of the existing extensions, I'm not going to consider it at all.
Yes you can technically maybe get off the ground more quickly up front with JavaScript, but as soon as you hit a certain code base size threshold (not sure what it is personally, it is probably different case by case), you would've been better off with TypeScript or Rust as JavaScript starts to "crumble" under its own lack of types, etc.
JavaScript is like Legos, durable and you can build many things in it.
Agreed. I would hate to see a CRUD spa written in Rust just because it was the fancy new thing. But sites like Figma, Miro, and Frame.io would make sense to look into a Rust WASM solution.
> but VSCode performance is generally good enough (I don't ever complain about slowness while developing).
The one thing I would say it can't handle is large files, like a large JSON file, I'm talking really large. It's something Sublime could handle and I used to keep it around just for that. This is not something I deal with often enough to really annoy me.
Honestly, a major benefit of strict/enforced type systems is that it substantially improves maintainability of the codebase. Large Python or JavaScript projects with no typing can be a huge nightmare.
The pendulum has swung away from dynamic typing but are we sometimes sacrificing expressivity as a result?
I don't really know Rust but from what I've seen of it, it doesn't feel like a natural fit for the web - either front or back-end.
Maybe I'm missing something?
I do think we'll see more simplicity (not Lisp-like) in the future.
Especially with Rust you have to think way more about banalities of the data model you normally really don't care about in web development.
I get a question over and over from front end devs when I teach or mentor about being a "real" computer scientist and picking up c, Cpp, or rust, which is silly. Who do you think invented the dynamically typed languages, English majors?
Yeah. The bill was paid when the language devs bothered to write a compiler, so that your runtime bugs become compiletime bugs and so you can understand what's happening when your program is bigger than a tiny script.
Now, on my old PC, the compiler is super slow so I end up prototyping tricky stuff (like maths) in python and then I port it to rust when I feel it's ready.
(my stuff is emulator: no DB, not much GUI but lots of performance, threading, etc.)
But jokes aside, Java’s type system can’t express HKTs, but up to that point it really is surprisingly strong — there is vavr, but I have also personally followed my former “define Haskell basic data types yourself in Haskell” class quite far in it, including Lists, Eq trait, Maybe type, etc.
This also means that if you architect your app right, you have have the front-end and back-end self contained in the same app, or split them over a network boundary.
So let's say you are writing a 3d modeling app or something. You write the engine and the gui in rust, and you ship that binary to your users. You can then also, again basically for free, put a network between the gui and the rendering engine, then you can serve the gui to client browser, and handle the rendering on a server.
The point is this is easy for the rust dev, so they don't need to be a JavaScript dev as well.
Others chose between Rust and Go, if performance was the most important thing.
The thing about dynamically typed languages and their expressiveness, is that you are sacrificing the ease of long-term maintenance for the ease of short-term prototyping.
Personally, I am a big fan of Clojure as a tool for designing software, but I would prefer having to maintain a code base written in Rust.
edit: and tangentially, the building and iterating lifecycle phase is of course usually the make-or-break bottleneck - maintenance phase sw engineering is comparatively a "happy problem".
Essentially, it's like two completely different reasoning models: inside-the-box (ALGOL / SQL), and outside-the-box (LISP / Datalog).
The first model (ALGOL / SQL) is about designing for machines to better understand, and the second model (LISP / Datalog) is about designing for humans to better understand.
I think that the main issue with dynamically typed programming languages is the lack of robust enforcement.
Rust is a low-level language, quite similar in the target niches to C++, while Go is a managed language with a barely-optimizing compiler for fast compile times, and a GC that prioritizes latency over throughput. They are nothing alike.
And sure, just as alike as Rust and D, Haskell, OCaml - they all produce a native binary with in-built GC, just like Go.
NIM supports concurrency and is as portable as the c and js it can generate to.
C#/F# work on x86 and arm which covers most targets today. And supports concurrency. And is situationally more performant than go.
I can't speak to the other languages mentioned, but they all seem quite similar to go as well, except for haskell.
Rust is more like c, c++, zig, ada etc.
IMO Rust is more expressive than most languages including languages like Python. Traits and enums are just... a joy to work with. It is also more constrictive in some ways, and a rust-like high-level language could do probably do better still (Swift/Kotlin/Elixir are close).
There's also a tradeoff between expressivity and performance and correctness. The way I see Rust is you get maybe 75% of the expressivity, along with much better performance and correctness guarantees.
I'd agree it's not a good fit for frontend, but IMO it's an excellent fit for backend.
It has a server side rendering mode, which for most projects will be all you need.
So then if you follow the Islands Architecture https://www.patterns.dev/posts/islands-architecture means you can sprinkle some typescript when you need more dynamic functionality.
I'd love to use Rust for front end enhancement in this way, but the problem is you have to completely open up your content security policy https://github.com/WebAssembly/content-security-policy/blob/...
Which is going to get picked up in any security review.
I've written up how I develop web apps with rust here https://rust-on-nails.com/
I wrote it up here https://rust-on-nails.com/docs/continuous-integration/integr...
Rust-to-WASM is another attempt to abstract away the pain of JavaScript, attempts which began soon after the world discovered XHR. In fact Google released GWT specifically to appeal to Java devs who took one look at JS and said "no thanks".
This is not so say that there aren't legit uses for this technology - its a great way to port other software, like sqlite or linux into the browser. But as a way to make applications designed to run on the web?
I suggest that any dev that thinks this is necessary to have a good dev experience take the time to attempt to write a web app with just raw html, css, and js targeted at a modern browser. There's a lot of space there left to explore, I think, before labeling it as an unwieldy thing that must be wrapped in a safer abstraction to even think of touching.
This hasn't really been true anymore for quite a long time. Pretty much everything is bundled, minimized, and obfuscated now.
The thing people ship on their sites is compiled.
Yes, but there is a strain of software minimalism that eschews the front-end build entirely. This is relatively recently possible because of excellent implementations of relatively good standards starting with HTML5, CSS3, ES6, and SVG2.
https://www.jslint.com/ is an example of what's possible with ES6 and built-in modules.
I do a lot of frontend development and I just cannot fathom how badly design JS as a language is and how awful the developer experience is. Every time I talk about JS shortcoming with other frontend dev, they point out that JS can do X or Y which other language cannot, but usually it is just a hack that are just not needed in other language because they actually do things properly (like having an actual sane type system and not having three ways to express that a variable is null). And TS is just a crutch that can barely help JS shortcoming.
Finally being able to compile from any language to a, reasonably sane, bytecode that can run in-place of JS is just a miracle and I don't understand why it took so damn long. JS should have been deprecated long ago. Even ActionScript was better.
Anyway, rant over.
Can you put breakpoints in WASM and debug frontend code?
Altering memory is more complicated, though.
Its problem is that the things Javascript excels at aren't all that useful, and the things it's bad at are often sold as features instead ("duck typing means I can iterate faster!").
Hum... Direct calling the DOM API is there already. You may be thinking about FFI marshaling, that there is something on the pipeline for helping (I don't even remember exactly what). But that's only a small improvement on speed, and that almost never is a dealbreaker.
For a while I thought the garbage collection helper was a dealbreaker (for anything except Rust), but GC languages are starting to compile into WASM too, with just a small performance hit. (I haven't looked exactly how.)
This year and the next are looking like some serious promising period for non-JS programing on the browser.
Why would i want to choose Rust? "Speed" and "not requiring as much of a memory footprint as well as more service uptime with less crashes".
I dunno man. I'm not saying those aren't interesting but I'm not sure that when it comes to web development that those are big hang ups.
There's got to be something more compelling IMO before you swing away from a fairly rich and frankly developer rich pool in JavaScript land...
Granted I enjoyed the article and my interest is piqued but that's it.
The language you choose matters relatively little.
WASM is not unlike the JARs and SWFs we got shoved down our throat ten years ago when HTML and JS were lacking any useful web capabilities. Huge files with separate runtime that implement their own renderer and operating environment. Google Docs already does this, using a canvas element to render to rather than using HTML and CSS to lay out text.
That is independent to whether WASM is being used or not. Two completely orthogonal concerns.
These are things that are, IMO, just too engrained as being possible in JS/TS for people to give up easily, especially in terms of UI programming.
I've used both quite a bit - I am pulling for Rust to become more ergonomic for this use case where it makes sense because it has lots of other advantages.
But when the rubber hits the road and you start writing, I think Rust gets in the way too much for UI programming. For a small project it may be OK, but in most orgs you have sweeping design changes occurring (probably too) often. Rust is best when things have stopped churning and stabilize.
UI code often churns like a relentless beast, so something extremely approachable/flexible but strongly typed is best I think. This is why TypeScript is winning in this arena.
I'm optimistic headway will be made, but Rust currently feels a lot better to write for back-end and systems. It's not a surprise since that's what it was designed for.
Besides all this, I'm totally unsure where the size of the distributable comes in. In JS things can be chunked per page easily which keeps load times small. With WASM you get the whole thing by default, correct? That could be problematic.
let decrement = move |_| set_value.update(|value| *value -= 1);
Maybe I've lost that interest I once had in learning language syntax.. I just don't really understand this intuitively and the barrier to understanding this line feels unnecessary. When I compare Rust with JS/TS, Python, or even Swift I feel like those other languages are created in a way that's easy to pick up and transfer knowledge from other languages, then the deeper parts of the language are easily accessible once you're introduced to the basics.
let decrement = () => set_value.update((value) => value -1);
I can't think on any modern language that lacks some short syntax for lambdas.
Hell, it's very easy to make a point that lacking short syntax for lambdas make a language not modern and unusable for our current standards.
let multiply = (a, b) => a * b;
Is this not a lambda?
My point is that the syntax isn't a problem, it's that Rust has very different semantics from the GC'd languages in the original comment and it all has to do with memory management.
let decrement = _=>set_value.update(value => value -= 1)
I don't understand your complaint about syntax. The real difference here is the concept of a move and a dereference. JS lacks these concepts and naturally has no syntax for them.
Now:
What is compile times for real-world medium to large projects? Do these even exist? Rust is infamous for its compile times, and frontend dev often requires live reload on every change.
What does debugging look like? Can I set a breakpoint in rust code in my IDE? What do I see in browser devtools? Can I change values in my paused code at runtime, then resume execution?
This article from 2½ years ago shows what was already possible back then when you're debugging C++: https://developer.chrome.com/blog/wasm-debugging-2020/
Rust build times are huge at first, especially if you haven't downloaded any dependencies before, (comparable to running npm install) but incremental compilation makes small code changes very quick and easy.
Having worked on a Javascript code base that's grown over a few years, I don't believe Javascript is any faster than Rust when it comes to compilation/transcription/packaging, especially when you need to add a layer like TypeScript between your tools and yourself if you don't want to go insane with JS' lack of typing.
I wouldn't use Rust for a browser frontend, but I don't think the lack of tooling is a very good reason not to. The massive size of WASM binaries, the overhead, the lack of transparency, and all the other problems are, though. I'd stick with Rust on the backend instead.
It's Java but with silly names, stupid scoping, a unique prototype system nobody seems to get down, a strong influence from the worst years of Microsoft, and a legacy that forces it to make some pretty stupid choices moving forward.
It's incredible what browsers have been able to make Javascript do, but it's not exactly a well-designed language.
As for being business practical, WASM is already widely employed by web apps. The front end ecosystem is in its early stages so it's quite messy, but it's developing faster than I expected. It may end up being a real competitor for frameworks like Blazor and ASP.NET if it the tooling continues to improve like this.
There is hardly any language that doesn't have some kind of meta language that compiles to JS. And without exception they all are bad, except maybe if you have a backend which only needs some very basic front end which you prefer to write in the same language.
But with any decent sized front end project, JS or TS are the better choices. JS, obviously, because it runs natively in the browser. So all browser tooling works out of the box, debugging is easy because what you see is what actually runs. TS, although it doesn't run natively, at least was designed to be compiled to JS and is widely supported so tooling is good as well. But any JS substitute that was added to a backend language as an afterthought will suffer:
- inferior tooling
- more troublesome debugging
- and last but not least, because it was added as an afterthought, 95% of the language will work fine but the other 5% can give you as a developer serious head aches.
API Gateway + Lambda/OpenFaaS/Knative with rust handlers (low RAM/fast start), and typescript/react served via CDN.
with serverless platforms, it honestly matters not what language. Rust is just a convenience for compiling to arm for gravitron and low memory footprint. Languages that carry runtime bloat are less desired though for cloud functions.
I'm surprised this has been your experience. I've known some pretty strong Rust devs.
But IMO the Rust dev salaries are a bubble that's about to pop. Personally I'm ready to work with Rust at less than the crazy salaries that are offered (though I'd still expect more than the average JS dev salary).
WASM has no native access to the DOM, so all DOM manipulations from wasm-land have to go through JS bindings with all the (de)serialisation costs that go with crossing the language boundary. That eats up a lot of whatever performance gains you'd see from rust-on-wasm for pure compute.
I'm sorry, no.