Rust Is Eating JavaScript (2023)

118 267 1 year ago

NomDePlum• 1 year ago

Most of the article appears to be discussing Rust being adopted into the JavaScript toolchain as opposed to directly replacing it in web development.

jeswin• 1 year ago

A better title would be "Rust is Eating JavaScript Tooling"

NSUserDefaults• 1 year ago

So it is actually both eating and excreting Javascript.

diggan• 1 year ago

Eating JS but excreting WASM, little bit of progress at least?

paulgb3• 1 year ago

This could use a (2021)

simonw2• 1 year ago

The 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

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-888ddb306...

lumost3• 1 year ago

Rust lacks major financial backers for the tooling ecosystem. This leads to a huge number of ambitious projects which are abandoned when folks get bored.

zozbot234• 1 year ago

Note that Biome https://github.com/biomejs/biome is alive and well.

nicce• 1 year ago

It has been updated in 2023. What could be the correct one?

simonw2• 1 year ago

The bulk of the article was written in 2021. There's a short update section at the end that says "Update: 2023".

paulgb3• 1 year ago

2023 is also fine. When I posted it did not say 2021 or 2023 which made it look recent.

the__alchemist• 1 year ago

I'm the author of one of the WASM-JS frameworks listed in the article. I now do frontends mainly in HTML + CSS + JS.

zb3• 1 year ago

WebAssembly is still very limited and not a "first class" language in browser, not sure why..

klodolph• 1 year 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.

Philpax2• 1 year ago

To 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 [1]: https://github.com/WebAssembly/component-model/blob/main/des...

matt_kantor• 1 year ago

The DOM API is defined as a JavaScript API.

It's defined via WebIDL (https://webidl.spec.whatwg.org/) which is theoretically language agnostic, but practically speaking the primary implementation target is JavaScript.

philippta5• 1 year ago

Just because a language doesn’t have a garbage collector doesn’t mean you don’t create any garbage to collect.

VWWHFSfQ6• 1 year ago

Not 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.

philippta5• 1 year ago

Parsing a JSON document for example will create an unknown amount of temporary heap allocated objects, that later will need to be freed up.

kamma44342• 1 year ago

My 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.

whstl6• 1 year ago

This 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• 1 year ago

Why not Java? Shouldn't it tick all the boxes?

JVM is like the Cologne Cathedral of the software world.

gizmo• 1 year ago

C++ was also very popular and fashionable at some point. It also promised better type safety and better memory management than C. Now, 20 years later, it's easy see that C++ didn't deliver on all of its promises about better abstractions and object oriented productivity gains. RAII promised to make race conditions, memory leaks, and use-after-free bugs a thing of the past. The C++ hype was relentless and a very loud minority argued every C project should really adopt C++. Thankfully, a handful of grouchy naysayers stuck with C.

Fashion and hype has always played a big role in software and our industry has at times unwisely abandoned good technology in favor of the 'New hotness'. We gyrate between local apps and cloud apps, thin and thick clients, static and dynamic typing, micro-services and monoliths, relational databases and keyval stores. Our industry is not very rational and the best tools don't always win. Marketing and market effects (winners keep winning) play a big role.

Recognizing the role hype plays in our industry is not myopia.

hot_gril20• 1 year ago

Well, Rust has a good WASM story, Golang doesn't.

Crisco• 1 year ago

I’m not sure if calling Rust “what’s in fashion this week” is accurate since it has been common for at least five years (if not longer) for posts that include “in Rust” to blow up on HN.

It has been the Most Loved/Most Admired language on Stack Overflow’s developer survey for 9 years in a row. I know that’s a relatively short amount of time for a programming language, but to me it seems like it has some serious staying power.

lioeters• 1 year ago

Maybe, just maybe, some of these "kids" know what they're doing and are preferring Rust for legitimate reasons other than fashion - such as performence, memory safety, and type safety.

hot_gril20• 1 year ago

Rust is legit for use cases typically served by C, C++, or maybe Java. I get more skeptical when someone's trying to shoehorn it into some other use case.

dcre3• 1 year ago

This post is four years old!!!!!

hot_gril20• 1 year ago

JS is an old and mainstream thing at this point, though.

Imustaskforhelp• 1 year ago

the poll mentioned 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• 1 year ago

I 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)

pansa22• 1 year ago

Admire simplicity

That would be nice. Instead we’re seeing all these JS/Python tools written in Rust - a complex language whose complexity comes providing memory safety without garbage collection.

Their authors are deliberately choosing to take on that complexity for programs where it’s unnecessary - programs which would work equally well with a GC.

VWWHFSfQ6• 1 year ago

The overwhelming majority of Rust borrowing complexity can be trivially solved by just doing .clone() which is basically all those GC languages like Go and Python are doing themselves anyway. You can avoid the borrow checker altogether if you want to, and a lot of people do. It will still be much faster than go or python just due to the lack of runtime overhead and GC

jtrueb• 1 year ago

You left out Leptos!

tonyhart7• 1 year ago

more like javascript eating rust

pansa22• 1 year ago

It’s eating Python too - with Ruff, uv, and an upcoming alternative to Mypy:

https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26

OutOfHere5• 1 year ago

It'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.

anon-39883• 1 year ago

I 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.

gpm• 1 year ago

the absence of adoption of these great tools in industry worries me.

UV is a year and a day old. It's not surprising that there isn't huge industry adoption yet.

I sort of have the impression that Ruff does have a reasonable degree of industry adoption. Certainly linting does.

There mypy alternative doesn't yet exist in a usable state

I'm not seeing anything worrying here?

LordKeren• 1 year ago

A large amount of important Python libraries are still missing a good amount of typing - and dealing with third party typesheds is not a good developer experience. The implementation of types in cpython has also been glacially slow and fragmented.

To add to the issue, a huge amount of Python in public repositories is untyped and unversioned- which means that LLMs are pretty bad at getting typing correcting in Python, so the debt is growing much faster than the solutions.

I honestly think that the most viable solution at this point for typing is a typescript-adjacent solution for Python. I’m kind of surprised Microsoft hasn’t put one out yet

JodieBenitez• 1 year ago

I don't know, ruff and uv seem to do great on the adoption. Of course speed is the perceived killer feature, not "types".

brap• 1 year ago

I 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• 1 year ago

Like 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.

stuartjohnson122• 1 year ago

Sharing 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.

rednafi7• 1 year ago

Maybe 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.

epolanski3• 1 year ago

Care 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).

hot_gril20• 1 year ago

I know about 10 languages by now, and JS is one of the later ones I learned. Nah, it's the best at what it does. And if I drew a graph of every project that's moved from language A to B, it would have cycles.

charrondev• 1 year ago

This is the nice if your only consumption of the frontend is first party.

Alternatively you could go the openAPI route and declare your API as a spec with types for a client to consume and the endpoint to return. This works cross-language and gives you docs first. (Start from the docs, convert that to types, then implement).

ljm• 1 year ago

I just wish YAML wasn’t so unwieldy for that, especially given the overall complexity of the spec.

I also thing that the tooling hasn’t kept the same pace as it has with graphql, where it’s easy to document your schema and the inspector makes it super easy to play with.

eknkc3• 1 year ago

I thought the same but recently we started using .net on backend and openapi to generate typed api clients for typescript. I mean the initial setup was 15 minutes longer than a full stack typescript app but I get to use .net on the backend and all the type safety on both sides.

dcre3• 1 year ago

At Oxide we use OpenAPI schemas generated from the server code to generate clients and it works quite well to produce the DX you describe despite different languages on server and client. OpenAPI has its frustrations, but it’s good enough.

I like to say that the main value of GraphQL was never really in the dynamic queries (in many ways an anti-feature) but rather in having a nice typed spec that lets you generate typed clients.

https://oxide-and-friends.transistor.fm/episodes/the-fronten...

hot_gril20• 1 year ago

OpenAPI, protobuf, etc. There are a lot of options that don't even require TS.

nicoburns• 1 year ago

Interestingly (relevant to the linked article), you can also do this in Rust.

abraxas9• 1 year ago

I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.

Can I tell you about live debugging of an app server and hot reloads? Pretty wonderful stuff really.

I can't believe how much knowledge, tooling and experience was thrown in the dumpster when Java was abandoned en masse by the younger generation of devs due to the rise of node.js. And if it weren't for Typescript the tooling would still likely suck.

mooreds2• 1 year ago

GWT was an attempt to let you live in java land and also still get the (tremendous) benefits of deploying to the browser Javascript VM. We used it on a java backed project, but we were not building an SPA so didn't see all the benefits.

I haven't used it for a long time, but it's still alive: https://www.gwtproject.org/

jappgar2• 1 year ago

Don't worry, the Typescript ecosystem is fast becoming Java.

And that's the exact reason I'm done with it.

DoesntMatter224• 1 year ago

Most of the abandoning of Java was due to Ruby on Rails not JavaScript.

agumonkey6• 1 year ago

feature of any Java developer setup for the past 25 years

do you mean rmi/javabeans or something else ?

beside that, I left java long ago, and believed in simpler REST stuff but now I realize that it's indeed rediscovering stuff people dealt with long ago

cjonas2• 1 year ago

Java types are not nearly as expressive as typescripts. As someone who has worked with both, I would personally pick typescript everytime.

afavour• 1 year ago

What always strikes me about posts like this is the lack of introspection: why did younger developers reject Java?

It’s easy to say “because they’re hipsters following trends” but I dipped my toe in the Java world years ago and found it immensely frustrating. Eclipse was awful compared to the lightweight editors I was using at the time. The language got in my way more often than it helped me.

I’m sure that’s not the case these days (indeed I’ve done a little Android-adjacent stuff and found it to be fine) but the idea that there were no downsides to Java at the time strikes me as unlikely.

wongarsu2• 1 year ago

I won't apologize for rebelling against Eclipse, SOAP, XML and AbstractBeanFactories. Java the language is pretty cool and very powerful, it's the ecosystem that was turning people off.

I hear Java has gotten a lot better. But then again there is C#, which is pretty much just better Java. Still too enterprisy for the tastes of most HN types though

darepublic• 1 year ago

When java shut it's door to me. When c++ gave me the cold shoulder. When mvn was very confusing for me. This little language became a cozy home for me

rednafi7• 1 year ago

JavaScript is an awful language. Doesn’t mean Java is the answer. There are other languages—Go, Rust, Python, C# that offer better protection without sacrificing ergonomics.,

gedy• 1 year ago

As someone who did Java WebApps for 10 years - they sucked if you cared about making a good user interface.

I thought JS was bad at the time, but node.js was a breath of fresh air for API development, and client side JS has been fine for like 10 years (assuming you care about UI development).

I'd never go back to Java except for maybe some backend service away from the UI.

jen205• 1 year ago

It's pretty interesting that people think Java was abandoned because of other languages, and not because of the problems of Java itself - or indeed that features like hot reloading and live debugging are niche or unique to Java.

.NET has also had all these features for just as long, and is less prone (though definitely not immune) to AbstractFactoryProxyBean nonsense.

watwut4• 1 year ago

Java was not abandoned en masse. Small projects were done in node.js. Large projects were and still are done in java or other non-js languages.

anon-39883• 1 year ago

I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.

Last I checked If I change a signature or something in Java, I am not guaranteed the whole thing "checks". If I add a new exception to a function, how do I know what else is effected?

based2• 1 year ago

Hot reloads?

https://tapestry.apache.org/development-dashboard.html

https://tapestry.apache.org/service-implementation-reloading...

dagw2• 1 year ago

Java was abandoned en masse by the younger generation

We tried. Java was fine, JBuilder was fine. When they instead started pushing J2EE, EJB and all the other acronyms I've forgotten, this 'youngster' realised he'd never be smart enough to be a Java developer and bailed back to C, Perl and Python.

Had they focused on Java and making Java a great language in its own right, it no doubt would have gone a lot better. But all the 'hype' and marketing around Java was focused entirely on these huge frameworks and enterprise 'solution' architectures which most 'youngsters' just didn't understand and didn't see the need for.

If someone makes it clear their product isn't for you and that they don't care about solving your problems, is it strange they abandon you?

wongarsu2• 1 year ago

Typescript and Rust may be more similar in this regard than you think. Both languages are born out of the desire to make coding simpler by making a stronger, more expressive type system. Sure, the details differ: Rust has lifetimes and about 8 number types, Typescript is garbage collected and has about one number type. But the spirit is similar. Both the typescript ecosystem and the rust ecosystem love the idea of taking types and function signatures and providing them for downstream consumers.

While I haven't gone too deep down this particular rabbit hole, if you build a Rust backend you can use function signatures and annotations to automatically build an OpenAPI specification for it. You can then consume that specification to automatically build a typescript client library, giving you an automatically updating Typescript interface to your Rust backend.

Similarly, there are multiple projects to automatically provide python type hints for your Rust python extensions. None of them really production-ready yet, but this is something people are actively working on for quite a while

logscore2• 1 year ago

THis is very similar to what Oxide.computer has done. They wrote their own tooling to go from Rust API to spec to Rust and TS client. Very specific to their use case, but I think its the right approach. If something is wrong in the client, you probably generated a bad spec, and therefore something in the API is rotten and should be adjusted. Using the spec as an intermediate to know if upstream is bad, can be a great benchmark for developers. My co-founder and i have a long term goal of building an end to end tooling chain for OpenAPI to generate spec and clients/tests/docs under one roof. Its definitely far off in development, but think its where devs are moving

whizzter2• 1 year ago

This is where OpenAPI/Swagger shines, we use C# backends and with NSwag (built in now also I think) you get an online API-spec directly from the controller (and types) of the C# code.

Only extra step is running a tool to download the swagger and produce auto-generated typescript definitions, otherwise the workflow is the same as shared code (Some projects are typescript on both ends but C# gives a ton of other benefits for backends).

cjonas2• 1 year ago

My recent experience with NSwag was really bad... It could only handle the simplest of jsonschema. We were trying to connect with a typescript API that had heavy use of union and product types. Maybe the problem was just that C# doesn't support algebraic typings?

lbreakjai• 1 year ago

This is what we do. We use kiota to generate clients within other C# services, and orval to generate a client in the frontend. We also run some basic checks against the openapi definition in branch, to detect breaking changes and whatnot.

lmm• 1 year ago

Sharing 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.

Have you ever seen Scala.js? Same language on the frontend and backend, in a way that actually feels first-class and real. Type system that's as powerful as Typescript but also sound. Full IDE functionality if you need it.

pier25• 1 year ago

You can achieve that with OpenAPI using any backend language.

There are tons of generators that can create a client with types from an OpenAPI spec. Not only to/from TS but also tons of other languages.

rixed4• 1 year ago

There are legions of languages that can be transpiled into JS. Use any of them both for back and front-end and suddenly, not only can you use the same types but also the same functions.

ec109685• 1 year ago

How can you deploy a system where you are changing API types in a way that breaks the type checker?

It seems like in almost all cases, you want to evolve in a forward compatible manner, with a very slow deprecation process.

cutler• 1 year ago

Clickbaity misleading title. Should read "Rust is Eating Javascript Tooling".

moomin• 1 year ago

Rust is pretty good for command line tooling, news at 11.

binary1324• 1 year ago

Tbh 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.

rednafi7• 1 year ago

So 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.

askonomm2• 1 year ago

Jobs 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.

rednafi7• 1 year ago

Europe 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.

wiseowise8• 1 year ago

This gave birth to the awful trend of using JS in the backend.

Right, famous developer Ryan Dahl who knows only one language.

HaQT11• 1 year ago

Not 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...

lewdwig• 1 year ago

It seems Zig is getting in on the game too now, with Bun leading the way.

skldj28d2• 1 year ago

with Bun leading the way

Definitely leading the way in segfaults.

mooreds2• 1 year ago

Title should really be "Rust Is Eating JavaScript Tooling".

Except for a nod to WASM, all the examples are about the JavaScript toolchain.

larodi• 1 year ago

Indeed, 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.

pjmlp16• 1 year ago

Additionally 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• 1 year ago

This 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• 1 year ago

Rust 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_gril20• 1 year ago

Heck 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• 1 year ago

The 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• 1 year ago

A triumph of hope over experience.

phplovesong• 1 year ago

LOL, 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.

binary1324• 1 year ago

JavaScript never should have been used for those things in the first place

cphoover• 1 year ago

God 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• 1 year ago

No, it is not!

FrustratedMonky• 1 year ago

I wish F# took off like Rust. I know they are very different. But it invokes same 'feel', and have a lot of same benefits.

pjmlp16• 1 year ago

Well, it always felt like Microsoft management has repented themselves to have added it to Visual Studio 2010.

tuananh• 1 year ago

by this logic, rust is eating python as well.

fHr• 1 year ago

babel is so bad versus swc brought a 10 fold increase in speed on the frontend

Rust Is Eating JavaScript (2023)

Related Stories