12 ms·
Rust Is Eating JavaScript (2023)
- tonyhart7 2y agomore like javascript eating rust
- NomDePlum 2y agoMost of the article appears to be discussing Rust being adopted into the JavaScript toolchain as opposed to directly replacing it in web development.
- jeswin 2y agoA better title would be "Rust is Eating JavaScript Tooling"
- NSUserDefaults 2y agoSo it is actually both eating and excreting Javascript.
- diggan 2y agoEating JS but excreting WASM, little bit of progress at least?
- TheCycoONE 2y agoBabel, prettier, and oxidase for a few examples all output JS. JS -> WASM doesn't tend to be very useful as WASM can't hit the DOM or most APIs.
- paulgb 2y agoThis could use a (2021)
- simonw 2y agoThe article really needs a date too. It talks about projects like Rome as if they're current when Rome was archived a year and a half ago: https://github.com/rome/tools https://github.com/rome/tools I think it used to have one but it was lost in a site redesign a few months ago: https://github.com/leerob/site/pull/727/files#diff-888ddb306a62a891deb0b8045d0f349322cfc49b8db96e206aa522b4e7581095 https://github.com/leerob/site/pull/727/files#diff-888ddb306...
- lumost 2y agoRust lacks major financial backers for the tooling ecosystem. This leads to a huge number of ambitious projects which are abandoned when folks get bored.
- paulgb 2y agoI have no inside knowledge but the speculation I’ve heard is that this was not about a lack of funding per se so much as what happened to the money. E.g. https://news.ycombinator.com/item?id=35930310 https://news.ycombinator.com/item?id=35930310
- lumost 2y agoA single startup with fickle founders/investors is not a reliable source of funding. C/C++ developed thanks to the effort of hardware, kernel, and os makers who invested billions into its development. Development of the JVM once occupied the effort of 10k engineers at SUN. JavaScript has a complex history, but has received significant investment from Netscape, Mozilla, Facebook, Google, and Microsoft. Rust needs one or two singular players with 5+ billion to spend supporting and improving devs lives. The nascent efforts I’ve seen so far are just that - nascent.
- steveklabnik 2y agoI don’t want to actually get into a “which is more” argument because I think historically in total you are correct, but Mozilla, Facebook, Google, and Microsoft are some of the largest financial backers of Rust.
- the__alchemist 2y agoI'm the author of one of the WASM-JS frameworks listed in the article. I now do frontends mainly in HTML + CSS + JS.
- zb3 2y agoWebAssembly is still very limited and not a "first class" language in browser, not sure why..
- klodolph 2y ago…if there’s a “why”, maybe it’s because WASM can’t interact with the DOM and the debugging experience isn’t very good. The DOM API is defined as a JavaScript API. The browser, JavaScript, and the DOM API have been evolving in parallel for over 20 years. If you want to interact with the DOM from WASM, what you can do is write a function in JavaScript that interacts with the DOM, and then import that function into your WASM module. At least for now.
- Philpax 2y agoTo further explain: the standard WASM ABI is essentially just a C ABI, so you can pass integers and pointers around, but you can't do much more; anything more complex needs to be built on top of that, which precludes binding to the DOM API directly. The existing workarounds for this glue the JS DOM API to the guest language through glue on both sides, but this means that you have to pay the penalty of marshalling through JS for every single call you make. There's a solution in the works to make direct interaction possible, but it's proven to be quite challenging to finalise: essentially, you need a high-level ABI that can provide a safe and fast interface between the host and whatever guest language, and defining that in a way that makes everyone happy is non-trivial. For more information, see the Component Model [0] and WIT [1]; the idea is that you will eventually be able to compile your WASM to WASM Components, which can then interface with the host (or other WASM components) through the WIT IDL, including interacting with the browser's DOM. [0]: https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model [1]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md https://github.com/WebAssembly/component-model/blob/main/des...
- wucke13 2y ago> you can pass integers and pointers around No, not even that (the second thing, passing pointers)! WASM has a different address space (starting from 0), effectively indexing into the WASM module's linear memory. A pointer/reference from the outside env can not be dereferenced from within the WASM bytecode. The multiple linear memory proposal can circumvent this (allowing you to build something somewhat similar to a simple MMU/address translation engine), but language support for that feature is sparse (AFAIK, Rust does not expose any way to access a different than the default linear memory for example). There is various hacks around it, but sharing memory block-wise between WASM and outside env is involved already.
- philippta 2y agoJust because a language doesn’t have a garbage collector doesn’t mean you don’t create any garbage to collect.
- VWWHFSfQ 2y agoNot sure I understand what you mean by this. Rust doesn't create "garbage" in the technical sense. It has RAII. It's a different thing.
- deleted 2y ago[deleted]
- philippta 2y agoParsing a JSON document for example will create an unknown amount of temporary heap allocated objects, that later will need to be freed up.
- VWWHFSfQ 2y agoI think you're confusing "garbage" with just normal heap allocation. Rust will free that memory automatically when the JSON strings go out of scope. There's no "stop the world" thing that periodically scans and deletes stuff while your program is running like in Go or JavaScript. Because there's nothing to delete. There's no "garbage".
- philippta 2y agoFor one-shot programs like Babel, Prettier, Terser, etc. mentioned in this article, I don‘t see how the lack of a garbage collector is a strong argument for an alternative language.
- whstl 2y agoNobody is making this argument for JS tooling. The article does mentions GC, but that's just demonstrating differences between JS and Rust. The other popular JS-tooling alternative is esbuild, which is built in Golang, which has a GC. If anything, the two most common arguments in favor of Rust for this specific use case are null-pointer safety and speed.
- cutler 2y agoClickbaity misleading title. Should read "Rust is Eating Javascript Tooling".
- moomin 2y agoRust is pretty good for command line tooling, news at 11.
- binary132 2y agoTbh I would much rather write utilities in Go. The advantages of Rust are minimal here and the disadvantages are an obstacle. Last time I wrote a CLI in Rust it was a search index builder you could pipe CSV to. Awful DX. Go is almost too easy for that kind of thing.
- hot_gril 2y agoYeah, you don't need/want manual memory management for most CLIs.
- binary132 2y agoIf anything I’ve actually seen people using the OS’s virtual memory as a garbage collector in C and C++. Not really portable everywhere, but close enough for most people. For short-lived executables that can’t really allocate unlimited memory, it’s perfectly fine.
- kamma4434 2y agoMy impression is that the JS guru crowd is made of cool kids and very sensitive to what’s in fashion this week - and that’s definitely Rust. Here on HN there is plenty of announces of new things “like X but in Rust” - even when X would be fine in Python or Bash.
- whstl 2y agoThis is inflammatory and myopic. The reason Rust and Go tooling is getting popular is because they are appropriate for the job. C and C++ are riddled with footguns and non-ideal for this kind of tooling, Ruby and Python provide only disadvantages compared to current JS tools, Haskell and OCaml are good but too niche. And so on. And the reason Rust and Go are getting usage in WASM is because they have a good WASM story. They are static, compiled and born at the right time. Other than C and C++, they're the only ones that put the effort. The reason people are making projects in Rust and Go is because they are accessible to those people. For me both hit a sweet spot that none of the languages above do.
- billfruit 2y agoWhy not Java? Shouldn't it tick all the boxes? JVM is like the Cologne Cathedral of the software world.
- OutOfHere 2y agoIsn't Java a memory hog and historically also exceedingly verbose?
- nindalf 2y agoFor a developer tool? Genuine question, how long does the JVM take to start? It used to be slow, but I don't know what it's like now. Check out the speed comparison of a few linters on this page -> https://astral.sh https://astral.sh. Would the JVM start before the fastest one finished? And supposing you took start time out of it, how long would an equivalent Java program take to run? Memory isn't as much of an issue, but all other things being equal users do prefer the program that consumes less memory.
- Imustaskforhelp 2y agothe poll mentioned https://x.com/devongovett/status/1261379312898306048 https://x.com/devongovett/status/1261379312898306048 was between (js) and (go/C/rust) See the problem to me is that this comparison isn't nice. Javascript comes with a lot of its problems , so of course people would want go / C / rust but Now the author thus concluding that people want "the fastest" out of go/C/rust is just wrong. I love golang. People like fast software but hate abandoned software even more . Yes there are rustaceans who would love the project but now hand anybody genuinely interested to contribute a rust project and ask them to learn rust and they would come hating at you. And now ask them to learn go. They can actually much easily do that. I stand with this opinion that go code can be read / written by anybody. There is very rare bad go code but rust code feels "magic" to people. Admire simplicity. That being said , I use archlinux with paru instead of yay , I use a lot of rust tools as well. To be honest , to me it doesn't matter that much , what matters is if its being maintained stable / has active community. It could be written in any language just make it easy to embed / provide bindings for major languages like python node golang etc. Or though this might come overkill but I wish if there was some sort of glue code which can bridge languages , most of these glue code libraries end up having so many use cases. so I like the idea of wasm but its just not that performant. If we can have insanely performant wasm ...
- Szpadel 2y agoI learned golang and rust, and I can say that both have significantly different concepts from other "conventional" OOP languages that it's not just learn new syntax approach. it's of course very subjective, but for me golang feels more magic, especially with importing GitHub repositories like local files. The easiest language is of course the one you already know. i would also argue that it's easier to write bad go code (I personally wrote some of it while learning) in rust usually if it compile and your are not using unsafe, it's at least ok quality and clippy is great with guiding you how to improve your code. to be fair JavaScript also is weird and different than OOP languages but from some time it tries to feel more traditional with classes and this handling. wasm is already fairly performant in comparison to native code, it might lack in come cases like simd (there are extensions already, but I'm not sure about adoption) but generally it's only about 20% slower than native binary. I'm not sure how much wasi is practical for cli tools, but using was for plugins to allow any language someone might be comfortable with seems like no-brainer to me (also isolation will allow you to control potential memory leaks and crashes so your application will not get corrupted or anonymously destabilised)
- jtrueb 2y agoYou left out Leptos!
- pansa2 2y agoIt’s eating Python too - with Ruff, uv, and an upcoming alternative to Mypy: https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26 https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26
- OutOfHere 2y agoIt's true, but the absence of adoption of these great tools in industry worries me. Most Python developers in industry don't seem to care one iota about handling corner cases of types, and so their code is full of problems. Most Python developers in industry are very untrained, and have no discipline when it comes to types. It makes me sad while working in such a setting.
- JodieBenitez 2y agoI don't know, ruff and uv seem to do great on the adoption. Of course speed is the perceived killer feature, not "types".
- OutOfHere 2y agoSpeed and types are different topics. Types are valued by mature programmers who recognize that maintainable and comprehensible projects require aggressive use of types. Short-term thinkers will not value types, and will lead to rapidly decaying and eventually unmaintainable dead projects.
- anon-3988 2y agoI think what will happen is something like numba gets more use. Bad developers can keep writing as they do, but critical infrastructures and functions will be written in natively compiled numba/python code.
- OutOfHere 2y agoI don't think I could agree less. Numba has always had too many errors, bugs, and too inconsistent of a performance gain. Moreover, Python has always been a glue language where numerous packages interact together to form functionality, and this glue usage makes no sense with Numba.
- deleted 2y ago[deleted]
- nottorp 2y ago[flagged]
- brap 2y agoI think the future of JS is going to be a lot like Python - you write your code with JS libraries because of the ergonomics, but critical pieces of those libraries are implemented in WASM under the hood. For example, you’ll still write your React components, but the React framework itself might be written in Rust and compiled down to WASM to make everything snappier (e.g. DOM diffing). I personally really love this pattern because it strikes a balance between speed and DX. Not everything has to maximize performance, and not everything has to maximize productivity.
- buu700 2y agoLike libsodium.js and pqcrypto.js. They're distributed as single self-contained JavaScript files, but under the hood have wasm embedded using the emscripten SINGLE_FILE flag with an asm.js fallback.
- stuartjohnson12 2y agoSharing types between React and a Typescript backend is great DX for developing both in parallel and I've not seen anything that comes close to being as enjoyable. Being able to change the signature of an API endpoint and immediately having all places in the codebase where the change will cause problems flagged as type errors is wonderful. I went back to working with duplicated types across python/typescript on a contract project recently and it took me 5x longer to fix the downstream implications of signature changes.
- rednafi 2y agoMaybe that’s because you only know one language and focused on using that everywhere. I have worked at 2 of those named companies where people made conscious decisions of moving away from TS backend because JS is an awful language to be used for system critical things.
- epolanski 2y agoCare to expand? I've been writing backend TypeScript for 8 years and it's more than fine. It's not my favorite language but it's a great compromise, and I would never choose a Lisp, Haskell, Java or C over it (the other languages I know).
- eknkc 2y agoI’ve been writing JS and then TS on the backend since 2013. Built large apps, startups and while it does the job fine I’d not go with Js on the backend anymore. We built some stuff with Go and then went with full .Net. Its like fresh air after years of Js.
- auggierose 2y agoWhat exactly did you like better in .Net than in TypeScript?
- 2y ago
- rednafi 2y agoSo is Go, and so is Python. The LLM craze shifted the focus from JS to Python a while back, and I’m all for it. That doesn’t mean I’m under the delusion that JS is going away anytime soon; at least from the FE. But its monopoly on the web took a big hit—and rightfully so. JS is a terrible language, and people who only know that one language will fight tooth and nail with anyone who opposes them. This gave birth to the awful trend of using JS in the backend. I understand that sometimes JS is the only option for frontend work, but keep that junk out of my sysarch. There are better languages your backend can benefit from—Go, Rust, Zig, Kotlin, Python—anything but JS/TS. I’m glad the industry has learned from its mistakes. I’m seeing far fewer Node.js backend jobs and a lot more Python, Go, Rust, and C# roles.
- askonomm 2y agoJobs are regional. Here in Estonia I see a lot more Node.js jobs YoY, very few Python gigs, zero Rust jobs, and very few C# jobs. Heck, PHP has more jobs than C#. Node/JS seems to compete with Java here for job popularity, according to local job boards, and most Java jobs also require Node.js/JS knowledge.
- rednafi 2y agoEurope is always playing catch-up with the US. Even so, the number of Node.js backend jobs has declined in both Berlin and Amsterdam. I’m also seeing a ton of Java, C#, and Go jobs in London. At my workplace, Wolt/DoorDash, all new services are being spun up in Go, where Node.js used to be the default. Plus, LLMs have gotten really good at Node.js and Python, driving backend salaries down quite a bit. In this age, being a one-trick pony just won’t cut it anymore.
- askonomm 2y agoGetting kind of tired of this Europe vs US trope. Europe is a huge place with each country having a rather unique economy, making a blanket statement like you just did entirely ignores that, and where does this constant need to compare one place on the planet with another place comes from? I don't live my life comparing everything about my country with another country, do you? Development trends themselves tend to also be cyclical. As for LLM's, from what I see the languages that LLM's are most often used for are those with the lower barrier to entry / and those that UNI's and bootcamps teach, which would very much also include Java. However, what I see is actually my salary going up as the average candidate quality has been also decreasing, almost in correlation with the usage of LLM's. So while maybe the junior/mid-level salary goes down, the senior salary, in my observations, has not. And I keep hearing from companies how finding actually capable developers has become harder and harder, so I expect my salary to only go up. Now, of course, being a one trick pony has never been a good thing, I agree on that (did you assume that I'm a just JS dev?), but I was just answering to your original comment.
- HaQT11 2y agoNot sure if I agree with the article. I saw this YC company recently and I think their vision for NPM install "fullstack app" is compelling: https://www.ycombinator.com/launches/Lkp-freestyle-a-new-way-to-build-fullstack-typescript-apps https://www.ycombinator.com/launches/Lkp-freestyle-a-new-way...
- lewdwig 2y agoIt seems Zig is getting in on the game too now, with Bun leading the way.
- skldj28d2 2y ago> with Bun leading the way Definitely leading the way in segfaults.
- mooreds 2y agoTitle should really be "Rust Is Eating JavaScript Tooling". Except for a nod to WASM, all the examples are about the JavaScript toolchain.
- larodi 2y agoIndeed, no sane JS dev would jump to Rust bandwagon, even if he’s very fond of TS. Besides Bun is not Rust even though Deno and some tools are. The JS crowd generally does not care about coding Rust, though would welcome faster tools which are sometimes rust based. Also Go based and even Zig based.
- pjmlp 2y agoAdditionally if one cares about performance, I would much rather write C++ than Rust, as that is directly supported by V8 tooling, without adding even more additional layers to debug.
- phendrenad2 2y agoThis is where Rust shines, CLI tools where a ton of processing needs to happen and execution time is extremely important. For almost every other problem, the amount of computation is much lower and/or the execution time isn't as important.
- dangoodmanUT 2y agoRust is great, but it's not like it's "fast" to develop in. JS, Python, and Go are all languages that can move a lot faster because you have less rules to follow. Maybe an _expert_ Rust eng can move just as fast, but you'll still move as slow as your slowest team member most likely
- hot_gril 2y agoHeck even C can be quicker to write in than Rust if you don't care too much about safety and don't need the nice Rust libs. I've been there.
- lofaszvanitt 2y agoThe new thing that gadget addicted males love because it's shiny and it's better and safer and the ultimate cool. Come everyone. C is dead, Javascript is dying. Also it is used by the bigdiks, like facebook who can't make a proper comment system, yet they market react as another shiny thing. And Apple who always turn your bluetooth back on after update. And google, who act like inbred mutants thanks to the incest that is going on there. A W S, the three letter magic thing also uses it. Plus cloud! And the list goes on! Plus it has fugly syntax, but who cares, it is memory safe! Jump onboard, this is the future!
- beardyw 2y agoA triumph of hope over experience.
- phplovesong 2y agoLOL, no. Rust is not eating javascript but COMPILED languges are, and only in the build pipeline. Rust does not matter, even Go is far more superior than anything in JS land. Eg. My webpack builds in 35 seconds. The i try esbuild and it does the same job in 35ms. Insane! Ok now lets try rust, now i get 20ms. Wow! Do i care about 35ms -> 20ms? Nope, not one bit. I just want it to compile under 1second.
- binary132 2y agoJavaScript never should have been used for those things in the first place
- cphoover 2y agoGod this comment thread is a series of unsubstantiated subjective opinions trashing languages that people don’t like and ignoring the faults of the languages they do…. Why must we rehash this type of post every few months?
- rtcode_io 2y agoNo, it is not!
- FrustratedMonky 2y agoI wish F# took off like Rust. I know they are very different. But it invokes same 'feel', and have a lot of same benefits.
- pjmlp 2y agoWell, it always felt like Microsoft management has repented themselves to have added it to Visual Studio 2010.
- tuananh 2y agoby this logic, rust is eating python as well.
- fHr 2y agobabel is so bad versus swc brought a 10 fold increase in speed on the frontend
- deleted 2y ago[deleted]