Will Rust Beat JavaScript in 2023?

Recorded live on twitch, GET IN
/ theprimeagen
Original: joshuamo876.bearblog.dev/can-...
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord

[@cameronraw5906]

If chatgpt writes things for me, Prime reads things for me

[@ThePrimeTimeagen]

yayaya

[@izzrose1997]

And both can barely do it properly

[@basepasandhai1906]

He also jumps while reading, but chatgpt can't

[@Manas-co8wl]

(i also use it for reading but maybe that's me..)

[@fear9998]

invited

[@Impatient_Ape]

For those who don't know... "steelmanning" is when you address the strongest interpretation of your opponent's argument; that is, the interpretation that is most favorable for your opponent's position. Steelmanning does not mean you're defending their position. Steelmanning is the opposite of a straw-man argument, wherein you attack a position your opponent doesn't actually support. In politics, straw-man arguments are the norm, and steelmanning is rare.

[@phudlow]

Steelmanning should be the default for all arguments.

[@Leonhart_93]

@@phudlow No it won't, because people as always most of the time want to win the argument even when they know they aren't right. "Should" will never properly apply to human behavior.

[@Lena-qg8bd]

Dioxus doesn't use signals btw. it uses the React model, but with compile time macros that remove unnecessary comparisons at runtime

[@dealloc]

Yes, Leptos and Dioxus also uses Sledgehammer that provides a ton of optimizations around string decoding, etc. which are some of the slowest parts of JSWASM communication.

[@PetWanties]

@Lena @ui_wizard didn't know that, thank you both

[@benbowers3613]

Pointing out that Yew is slow actually helped me wrap my head around these things. React and Yew are slow not NECESSARILY because of their respective languages, but has a lot more to do with their architecture. Virtual DOMS do be expensive

[@BosonCollider]

Not entirely true. Dioxus is fast yet uses (a very well optimized) VDOM with (even stricter than react) hooks. But several of the optimizations it makes require a static compiler that does more work than transforming JSX to nested createelement calls, its VDOM nodes are a shallow tree of static templates that are basically just the state tree instead of the DOM tree.

[@benbowers3613]

@@BosonCollider Dope. Big learning 🙌

[@IStMl]

That's why we got Svelte and Solid

[@dealloc]

10:00 These are called "Magical handler functions" and are also used by Axum and Bevy. The technique is done by taking advantage of Rust traits by implementing a trait for Fn with an arbitrary number of arguments, through generics (generated by macros, usually). They are nice but also comes with some caveats: Error handling (what happens if an extractor fails? e.g. de/serialization), performance with regards to re-computing extractors (as they are independent and cannot share "work already done" between each other) and that the order of how you define extractors in your function arguments can have different performance characteristics (yes, really).

[@mti2fw]

I would appreciate to see your tech choices (backend, frontend, databases, devops, etc) for different situations like: what to pick for a MVP, or a small personal project, or a CPU intensive worker, or an IO intensive API, etc

[@daltonyon]

I like this article too. Seems a little strange yet to me this mix of Rust with "HTML", remember a lot of old freaking PHP sites. The fact of not using try/catch is awesome, help a lot in logic because many of times we use try/catch of part of our business logic and this is terrible!! Thanks Prime, cheers my brother!

[@thekwoka4707]

That thing with the type of the srgs changing what you get is also how Be y, the game engine let's you access different things in the world. Like you can add a "system" that's a function that accepts an arg of type `Query` and now that arg is an iterator over the Players that are Mages. And you can have an infinite number of them for all kinds of different things. It's amazing to work withm

[@BosonCollider]

Just a heads up that Dioxus does not use signals (it follows VDOM + hooks approach) but is still fast. But its VDOM implementation is much, much better than React/Vue/Preacts approach and the VDOM nodes are flattened templates allocated in a bump allocated arena instead of mapping 1:1 to the DOM.

[@jongeduard]

Hi, personally I have not yet explored web and WASM development with Rust (I am not primarily specialized in the web in general), but about what you said at 19:10 I have something to notice: Rust is not just different from JS in this perspective, but also from C and C++ in that exact same kind of way: Not noticing your bugs, giving you a false impression of simplicity. And this is actually kind of surprising, since JS versus C and C++ are generally speaking 2 very different kinds of technology, which both bug and crash in different ways (JS type coercions resulting in unexpected outputs, C and C++ bugs with memory and pointers resulting in UB and crashes, segfaults). So fun fact is that from both the side of JS as well as C and C++ you hear people often come up with that fallacy that development in Rust takes more time, while the opposite is true.

[@derschutz4737]

Its not the cost of signals vs not signals, its the cost of a bad/suboptimal implementation. Dioxus is as fast as leptos yet it still uses a vdom.

[@mantovani96]

I would like to see articles like this one pointing also the cons, not just the benefits. I think would give the reader a deeper understanding.

[@d.sherman8563]

I like most takes in the video, I don't agree with the take on TS + Zod though. In rust you will also need a DTO validation library for more than just checking that the type is what you expect. Think of things like min / max / length / regex / comparing two fields etc. This is why Zod and libraries like it for other languages (including rust) are useful, they provide a declarative way to validate data coming into your system that you don't control. If it was just for validating the runtime types it would still be useful but extremely meh.

[@ThePrimeTimeagen]

fair enough field length validation and other non specific type checking is very nice facet of zod but i still stick by deserialization is validation is one of my favorite aspects of rust.

[@AdiosOcelote]

Prime got Flipped at the end. I love it.

[@jekytck]

I have had the inverse problem for the longest time: I was nevere importing any library, always coding every function by myself while at uni Until my professors told me "Don't re-invent the wheel" for the 10th time But it made me an overall better programming and I never realised it, I always thought I was just inefficient and ignorant of all these magic libraries that do stuff for you

[@simalicrum]

I code in JS because the I need libraries for Azure and the ecosystem is insanely good. I also swap between OSs on the regular and node/JS handles that very well. I nice bonus is anything algo heavy is 2-4x slower than C, which I can live with.

[@yusril-ihsanul-alim]

Azure is good?

[@joshmo3611]

Hey Prime. First of all: Wow, thank you for reacting! I didn't even realise this had gotten so much attention until someone in a discord I'm in actually linked me to this video (and a clip of your initial reaction on-stream). I definitely agree the initial picture was probably not ideal and putting the performance benchmarks first probably ruined the first impressions of the article (as well as maximum clickbait title), but I'm glad that I could get some of your thoughts from reacting to this!

[@ThePrimeTimeagen]

it was a great article. i really did like what it was saying! i hope you don't take anything i said as negative :)

[@joshmo3611]

@@ThePrimeTimeagen No definitely not, I appreciate that some parts were probably somewhat pointing in the wrong direction 😆

[@avi7278]

​@@joshmo3611 he's lying, he hated it. He told me off stream.

[@ahmedaghadi8281]

@@joshmo3611 Blog link isn't working now.

[@siddhartamorionsuarez9017]

Guys help I watched some rust programming language videos and now youtube thinks Im a Rust gamer and only recommends me rust gameplay (sorry rust foundation)

[@lydianlights]

I should do my personal portfolio page in rust. Would be a good excuse to finally learn it, plus it'd be extra funny because I've somehow become a React frontend dev (fml).

[@ThePrimeTimeagen]

rust on the backend solidjs on the front

[@technologyondemand4538]

dioxus on the front :p

[@SpaceChicken]

@@ThePrimeTimeagen Weird interpretation of the mullet, but I’m here for it.

[@thekingofpotatoes1932]

​@@SpaceChicken funny seeing you here, space chicken

[@dinckelman]

I don't think it'll be happening, purely because of one reason. No one is hiring for this specifically, unless you're the 0.1% highly specialized example of a company

[@ThePrimeTimeagen]

yeah, there is definitely a slow shift happening, it was just a few jobs, now its a bit easier to find them. my guess is within 1 year we will start seeing more regular rust jobs.

[@256k_]

rust's excellence is its own pitfall. its a near pefect language but comea at a very high price of learning and frustration and most people will not stick with it, especially when you already have a full time job and family and just wanna get your work done and be done with it. this is why go was a lot more successful in about the same time frame that rust had. it offered a much simpler language with GC to help make code even simpler while giving pretty good performance. sure the gc leaves some performance on the table and you might get some unexpected errors here or there... but in the time someone is learning rust, someone else write a whole bakcend api with go and works pretty good. we cant compare go to rust in this case, we should compare go to javascript and in every case it's a success

[@dinckelman]

@@ThePrimeTimeagen we can only hope

[@balen7555]

@@256k_ No. Go had heavy backing from Google. Rust used to have Mozilla, but that's no more, and even then, it didn't have the resources Go did.

[@4445hassan]

Dioxus is more of a "React in Rust" than Yew i think (that is kind of the purpose of dioxus) but dioxus VDom has a better architecture than Yews, i belief. Returning `impl WhatEver` is also not a trait object its an existential type, you can only return one type out of the function. Trait objects are the ones with "dyn" which are implemented using vtables and dynamic dispatch.

[@bigmistqke]

Compile times, no hmr, no code splitting, big bundles, utf-16 conversions, ... For zero to no performance benefit. Idk man. I think it's cool what they r doing, but the big break s not gonna be for anytime soon imo.

[@dleonardo3238]

As a native android developer i'm curious to try kotlin/wasm with Compose

[@LukeDickerson1993]

would be curious your thoughts on flutter / dart

[@roccociccone597]

Go for backend is great. My team is currently in a migration to Go for our backend services. I find it very enjoyable to write. Personally I think it's much more fun to write than Java or C#.

[@giorgos6576]

In speed? Probably yes. Good luck finding devs to meet the demand.

[@serhiiway]

For me, it's good luck finding projects with Rust.

[@TechBuddy_]

@@serhiiway the story goes both ways

[@srujanj.1284]

hey bro keep us motivated

[@vardhanpatil5222]

I would really like to see you making a video on shuttle, I personally really liked shuttle

[@eboodnero]

I REALLY agree with your comments on "developer experience"

[@ThePrimeTimeagen]

^^

[@TechBuddy_]

I am not going to use rust on the frontend anytime soon ( solid js is awesome btw ) but thinking of switching from a mess of backend services in deno and Golang into rust. But in terms of development time and performance go is good enough. Do you think I should do it. The software is serving a small audience and performance is not my concern at the moment.

[@mishikookropiridze]

No you shouldn't.

[@okie9025]

Please do not drink the koolaid. Rust is not a silver bullet and there is a reason why it's still not popular.

[@thekingofpotatoes1932]

I doubt the value proposition of a switch simply for the sake of using rust on the backend would be worth it, but if it's for learning's sake then it might be worth indulging

[@TechBuddy_]

@@thekingofpotatoes1932 I mean I could learn rust by porting over a backend service but I think my co founder would just die 😂

[@jokeyrhyme]

I've seen "HTTP" pronounced as "hot potato" And "HTTPS" can be pronounced as "hot potatoes"

[@codefork94]

What your thoughts on elixir and phoenix?

[@avi7278]

It's not the speed in which you can write an app, it's the speed in which you can write a production ready app.

[@HermanWillems]

Thats what rust shines at. Programming a Rust application means the chance it works properly and without bugs has increased and therefore the time for a solid product shipping has declined. Even though it takes more time to write a Rust application where the compiler yells against you all the time.

[@Ludwig_Van_Aristossine]

I've started with JS and I pray that one day Rust will surpass it because you don't want to deal with "undifined" or "[Object object]" all ur life

[@posei4094]

The only thing that held it back is job openings, is just lacking as of now. However, i think it might change in the coming years.

[@stugeh]

That and understandably the documentation for most rust web libraries/frameworks is nowhere near what's available for j*******t as of now.

[@okie9025]

@@stugeh people praise Rust for it's great documentation. Honestly, if this is the best that Rust can offer, I'm worried about the people that think Rust will beat any language LMAO

[@stugeh]

@@okie9025 i think the docs for the language itself are incredible but the eco system hasnt reached the point of maturity yet where there are well established frameworks around with a book's worth of introductory documentation like there is if you're trying to pick up vue or something.

[@fahimp3]

also that you need the Visual Studio Build Tools for the rust compiler if you want to code on windows. Which is a must for me... Interestingly Go does not have this issue.

[@Ubben1999]

​@@stugeh Agreed, the Rust docs are great. Given how good the support for documentation is in the first party toolchain, there's a really good chance we'll see fantastic docs across the ecosystem as it matures.

[@bfolkens]

Rust is amazing for TUI and other systems level dev, but Elixir is by far my favorite for BE and other comms dev - there’s a good reason Whatsapp chose the Erlang/OTP platform

[@RedStone576]

how about Discord, they used elixir then go then eventually rust

[@bfolkens]

@@RedStone576 Yes exactly, and they still use Elixir but leverage Rust to build very specific "plugins" (so to speak) into the Erlang/OTP platform. You get the best of both worlds.

[@b_two]

a whole host of issues with typescript will be fixed as long as you use `satisfies` instead of `as`

[@nomoredarts8918]

Just check out where is Elm on that list. But yeah, we should stick to typescript and react/angular

[@durchschnittlich]

flip, please keep it, i like that

[@kristofferkristensen9142]

Why's your previous videos not available on twitch anymore?

[@chrishabgood8900]

tis is why the core behind elixir is so robust because it is used in the telecom industry for serious uptime.

[@unusedTV]

21:00 hittipee

[@lazyh0rse]

I know you are a rust guy, but I have been learning C++ for the past 2 months, and I'm really surprised by how quickly I'm picking it up. I already made a rest api that could serve content, authenticate, and authorize with a database all in almost one month only. It all depends on how much you know the stack+language.

[@ThePrimeTimeagen]

this is such a fact. DX is terms of "how good is a language" is almost exclusively a function of how familiar you are with it

[@anmolsharma4049]

From where are you learning? Can you share your ways

[@lazyh0rse]

@@anmolsharma4049 The Cherno youtube channel.

[@TankorSmash]

@@ThePrimeTimeagen I think DX usually boils down to compile times and the errors you get from crashes and the compiler, and how easy it is to refactor the code you've written. Familiarity helps equally across all languages, so it factors itself out I think.

[@anmolsharma4049]

@@lazyh0rse thanks

[@MarcosVMSoares]

Elixir is production ready today different from GO that u need a lot to have the same quality and BEAM have fantastic ecosystem battle system for year in the server area, not a system language trying to do server apps.

[@hamm8934]

Rust foundation really has me questioning my time with Rust TBH

[@ThePrimeTimeagen]

same

[@o__sama]

I prefer seed-rs, closest one to elm-lang, using it on production, it is basically stale framework and that's amazing, much like elm-lang, it is already complete.

[@basilfeitknecht6430]

what are you doing in seed exactly? is the webdev good? i've been thinking of getting into seed.

[@o__sama]

@@basilfeitknecht6430 I'm using it for an admin dashboard which has a LOT of state and configs for an ecommerce system for B2B, I probably woudn't use it for B2C because that requires a lot more polishing on the asthetics, for for B2B where you don't need animations for example, and standards UIs is enough it is perfect especially paired with a backend in rust, the structs are shared, and since it is using rust + elm architecture it is bug free and very easy to reason about especialy regarding state changes.

[@julienarpin5745]

I watched a few videos about Rust yesterday. What’s next on my journey?

[@KadenCartwright]

Normally I don’t listen to just any jo shmo, but I’m intrigued

[@chm10323]

leptos, yup, it fix my exp in *web-app*, but Dioxus, I think they try to lead the devs to have more like flutter / swift DX...

[@metaltyphoon]

@10:32 my man never used C# with ASP. You would be amazed how this is since in C#.

[@boot-strapper]

There seems to be a myth that rust is just as fast to build things, but it probably takes 10x longer, and if you are a rust expert 5x longer.

[@taragnor]

It's more complicated than that. It's more a case of how big your project is. JS is extremely fast to create small projects. When the project gets larger though, JS runs into a lot of problems. It's the reason typescript was invented because JS at mid to large scale is a nightmare. And while the initial write speed of JS/TS is always going to beat Rust, keep in mind that after you write it, you'll probably be debugging it. And Rust code, while taking much longer to write and produce a working executable, is also far more bug free.

[@boot-strapper]

@@taragnor I agree 100% but it does make it really hard to know what to use and when. Most companies are simply not willing to build at 10% speed just to have less bugs. Its sad but true.

[@taragnor]

@@boot-strapper Yeah, eventually Rust does "catch up" in terms of design speed, but the initial speed to put out a semi-functional program is much slower with Rust. Rust gains its advantage the more complicated things become, because that's more errors the borrow checker and compiler can spot for you. The problem is that projects typically start small, so they often favor languages early on that are good for small projects. You won't see reap the benefits of Rust until years or probably decades into your program's life.

[@boot-strapper]

@@taragnor yep. And in a world where companies want quick profits, and managers need projects completed fast so they can get promoted it makes it very hard to actually use rust. It makes me sad.

[@elvor8512]

MAN IS LITERALLY NAMED JOE SHMOE. WE FOUND HIM

[@benbowers3613]

"There's plenty of ways to make an app. At the end, it's how happy your users are." GOLD

[@okie9025]

The order of importance is: 1. A working app (no bugs) 2. Developer experience 3. User satisfaction 4. Performance Rust violates this by sacrificing developer experience for user satisfaction and performance, which are the 2 least important factors.

[@RenderingUser]

@@okie9025 "sacrificing developer experience" i doubt it hurts developer experience any more than a language like c++ if anything, it might have a better experience compared to that, especially in the long run

[@remrevo3944]

9:55 At least in axum they are called extractors.

[@DrDrero]

9 minute read to 23mins decompression is impressive. Luv it.

[@PeterBernardin]

From a purely practical perspective, I don't really understand how rust is so much better than typescript from an error handling point of view. Some yes definitely, but disallow allow nulls for example and you'll see all the potential errors. Yes it's true javascript does have a little loosey goosey personality with truthies and falsies, but that can easily be overcome with a habit of doing triple equals. It's hard for me to think of how you could possibly get an error that way with strict typescript, unless you're relying on third party apis that might contain errors. But the same can be said in some way about hitting APIs with rust. How do you know the data you're getting back fits the type unless you validate it? You can do the same in TS essentially. Theoretically nothing can go wrong. I think what happens is people maybe don't have the strictest typescript settings on generally, that's why they run into errors. I definitely think there is a place for rust, but I don't see it in a web framework. It's true what you say about js/ts/node being a nightmare, I totally agree. But nowadays, for example, Vite+SolidTS is a fantastic combo. You kind of skimmed over the fact that it's still faster than Leptos, and has a much smaller size, and Vite fantastically breezes over the node/js/ts nightmare. I do think rust is really cool, but more for programming OS drivers. I don't see it succeeding in the web world taking over javascript except for heavy computational tasks. I also think a lot of the benefits of WASM (it seems to me not many people talk about this) comes from unblocking the main thread, which can be accomplished with a web worker. Unless you're doing *heavy* computation, I don't really think WASM/rust adds much benefit. This is my opinion right now and I reserve my right to change my mind later.

[@ChaoticTrack]

TIL about `strictNullChecks`. Thank you :)

[@balen7555]

"This is my opinion right now and I reserve my right to change my mind later." Your ignorance is funny. First, error handling is different from optional values. So, null's got nothing to do with this. Second, how do you know some weird function you call in typescript throws an error? You don't. Now think clearly about what that entails. In Rust, errors are a part of the type system, and you have to handle it explicitly. When you call some weird function, you know what errors it could throw, and you have to explicitly handle them. This means, even if the error involves runtime data, as in you can't know if it will error at compile time, you still know if it COULD error, and you HAVE TO handle it. This allows you to build fault-tolerant systems, that you can be rest-assured with that you've handled all error pathways in Rust. You can't do that in typescript. You can't have this guarantee in typescript. Leptos is a bit slower than SolidJS (while still so much faster than React), only because CURRENTLY, there's overhead to manipulating the DOM from wasm. Those benchmarks only test DOM manipulation. Is that all what your webapp does? No, that's not what happens for majority of webapps. For everything else, Rust compiled to WASM is miles faster. This means for any non-trivial webapp, a website in Rust will end up faster than even Vanilla JS, let alone SolidJS. As for size, WASM loads faster than JS, so you have to keep that in mind too. But yes, currently WASM payloads are heavier, but not by much.

[@PeterBernardin]

​@@balen7555 I want to believe, but I just don't think that's the whole picture. I would obviously agree that rust has more safety-first features, as you explained. But I think the hate on typescript is exaggerated polarisation. A lot of what you mentioned too in terms of speed also didn't address what I wrote above about simply using a web worker (this also saves you for a gluing nightmare, and keeping types, etc). I don't know what kind of web apps you make, but the kinds I make actually do a lot of DOM manipulation. It's really complex to co-ordinate measurements and DOM manipulations in such a way that avoid forced reflows too, which I'm not sure how Leptos would handle this, or how WASM would handle that even if the DOM-WASM relationship was optimised. I do a lot of UX animations (for example re-adjusting a side panel and having the items re-arrange themselves in a way that can't be done with CSS currently). I'll give you an example of what I'm talking about: In one of my apps, there is a part where a page of results are shown. The results appear in a boxes, each box has a paragraph. But there is only one sentence focussed in that paragraph. So the boundary (top, bottom) of that sentence needs to be measured, then the box needs to be "cut" in such a way that the top of the box is a little higher than the top of the focussed sentence and the bottom a bit below the bottom of the focussed sentenced, essentially 'focussing' the box on the sentence. The part that sucks the juice is forced reflows. For example, if I put the measuring and cutting logic inside each block as it is instantiated, then when the next block is rendered, the measurement will force a reflow of the whole page in order to obtain proper measurements because there has been a flagged change in from the previous boxes cutting, which affects the position of the current box. Very computationally intensive. And when you have 20 results on a page, it has to do it 20 reflows. I'm not sure if you're familiar with forced reflows. The general idea to solve it is to do all your measuring at one time, and all your cutting at another time - if you can. So what I did is I made a script that "registers" the boxes as ready-to-be-measured and ready-to-be-cut as soon as their layouts are calculated (but not painted). All the measuring happens at once, then all the cutting happens at once, orchestrated by the container of all the boxes. All this I can do within one frame, before the box is even rendered to the screen. That why there is no "flash" of a full box before it's sliced to its proper size. This is because the painting will hold because of the tightly-nit relationship between the rendering pipeline and javascript thread. If I was using Leptos, even assuming we're in the future and there's a good DOM-WASM interface, I would imagine that the main thread would not know to hold off on the repainting in the situation like the above. Because it's multi-threaded, even before the first measurement, the rendering pipeline would draw the boxes. You would have an influx of measurements at seemingly random times and then cutting at seemingly random times (from the perspective of the rendering pipeline interfacing with a separate thread - WASM). So even if I applied to the same concept as above, you might see "flashes" of drawing. All this to say I can't imagine a multi-threaded web app being tightly interconnected with the rendering pipeline of a browser, which is actually a big deal when it comes to more advanced web apps. This is for the same reason that things for example like, requestAnimationFrame, I don't think would play well in parallel. This problem would affect both a web worker and WASM. But yes I would agree that for an app that isn't really focussed on UX from a DOM perspective like mine above, and more focussed on security that you really don't want bugs or crashes (e.g., a bank app), rust and WASM would probably be a really good option. Especially when the ecosystem gets better. I thought this idea of Rust/WASM was really cool and wanted to implement it in an app I was working on, actually. I get excited about these technologies. Unfortunately I couldn't find a situation where it didn't cause more problems than it solved...

[@balen7555]

​@@PeterBernardin You raise good points. But, regarding this statement " I would imagine that the main thread would not know to hold off on the repainting in the situation like the above. Because it's multi-threaded ...", multi-threading is opt-in. You don't magically get multi-threading in Rust. And multi-threading on WASM for the web will use web workers (currently). But, yes, your WASM code will I assume run on a different thread than the main JS thread. Currently, that doesn't matter for your example, because all DOM operations run on the the main JS thread. The downsides to using Rust for the frontend currently IMO are: - 'difficulty'. Rust forces you to explicitly handle a lot of things, memory, errors, and even asynchronicity relatively speaking. For a lot of code, that's something you don't want to think of. - immaturity Otherwise, I think in principle it should serve better than JS/TS. As for the hate on TS, I am sure everyone loves TS; it's what makes JS development bearable. Regardless, in the end, it's still a hack built on top of JS; so even though the type system is great, it's not sound at all. There is no true notion of types.

[@DiogoSilva-xx8nz]

is wasm still a thing? i have been waiting it to "take over everything else" for years

[@okie9025]

Every year is "the year when WASM takes over JS", just like every year is "the year of the Linux desktop". It will simply never happen.

[@bmurph24]

I use go webassembly for some really performant read/write processes for compute done client side. If I didn't have an easy performant serialization method for talking to the web services it would have sucked and been basically impossible. So ya I have 4 web workers using wasm and I throw the map tiles into those workers on the client and it works great (10x better for bandwidth/compute), and it wouldn't have been possible without wasm. However I would never do any DOM shit with wasm lol. I think it's a performance when you need it thing, like figma I think did the UI in wasm / webgl.

[@DiogoSilva-xx8nz]

@@bmurph24 ye, i believe it have some use cases, but thinking it will take over js seems too much

[@betoharres]

unfortunately JS is a plague that will be haunting us for decades ahead. Rust might gain more traction in 2023, but I highly doubt it's going to be the norm this year. The number of JS work globally right now is the reason this is going to be a slow transition, mainly because Rust is a breakthrough for the developers, not the consumer.

[@okie9025]

There isn't going to be a transition in the first place. People have been trying to replace JS for decades, but the JS community and toolchain is simply too advanced to be replaced.

[@DragonRaider5]

I just dont get why SQL support would be of any relevance for a clientside application. I think stuff like component libraries, GQL clients etc. wohld have been of a lot higher interest. Am I forgetting something?

[@rotteegher39]

I was stupid enough to not realise that the speed of writing software is directly proporsional with you familiarity with the programming language... All this talk about "Fast Developer Experience" => "Faster Programming" was bull**** all along! It's Rather "More Familiarity With Language" => "Faster Programming" Thank you for enlightening me.

[@RandomGeometryDashStuff]

07:47 why not just use (replace * with url) tags or are you talking about non-web browsers like deno?

[@DNA912]

That on familiarity is SOOO true, I've barely used JS or TS, and every time I do, I just think, WTF is going on

[@anon-fz2bo]

Id become a front end dev again if that were the case... 😢

[@j-wenning]

Totally confused by what you mean when you say validation "doesn't exist in Rust." It's not like serde isn't parsing and validating at the same time. Whether you're using JSON.parse and then throwing the result into Zod, or rolling your own solution to do both with slightly greater efficiency, you're doing the same thing. If you're using Zod for anything other than ingesting external input, you're almost definitely doing something wrong.

[@IAmOxidised7525]

How would it compare with Svelte

[@chesster5981]

Svelte is JS bro

[@thedduck]

No no no, it's gonna be *Mojo 🔥* FTW!!

[@adsick_ua]

"all errors will be handled" sure, what about panics?

[@farqueueman]

HTML will be them all in 2030.

[@Heater-v1.0.0]

Rust, Javascript.... "these two sides have nothing in common"? Hmm... I love Rust, I also love Javascript (No not Typescript). They are my current top two languages after many years of using many other languages including C, C++, Pascal, Ada, PL/M, Coral, Lucol, assembler and more. Am I weird? I love Rust for its priority on correctness, all that type checking, lifetime checking, disallowing uninitialized data and null/stale pointers etc, etc. I love JS for its dynamic typing, it's instant response when hacking (no compilation) and general freedom. I love them both because they are polar opposites. Seems I have nothing in common with myself! Am I weird?

[@pokefreak2112]

I tried leptos for a little bit and didn't like it. Compiles took several seconds, views use fake html with weird rules/restrictions and I spent more time writing types than actual logic. Also when I tried to make an API call I got an unreadable wasm runtime error with no source map. Is it just me or is this stuff just not ready for real world use yet?

[@ThePrimeTimeagen]

i think we are "on the verge" but not there. i am somewhere in both camps. i recognize wasm has some pretty nasty error handling i also recognize its easier for me to create a long running service in rust :)

[@Shri]

Rust has the potential to completely dominate if Python AI/ML stuff can be rewritten in Rust (or those Python libs which have C/C++ bindings ported to Rust should probably be sufficient). I am also really tired of Typescript and how slow it is when it comes to type checking and all the warts related to error handling. I am keeping an eye on Zig as well (though it is currently lacking the ecosystem that Rust has).

[@ThePrimeTimeagen]

yeah, zig is really interesting

[@mishikookropiridze]

Not sure if ML/AI guys will ever consider switching, And most of the time if there needs to be performance gains, python AI/ML staff is re-written in C++ , so mostly this is where it might happen.

[@dandogamer]

@@mishikookropiridze yeah python is really good for bashing out a model really quick. Most of the time you dont know if the model will work fully so why waste more time building in rust.

[@JanuszKrysztofiak]

There is no 'silver bullet' or one language to rule them all. All of them have scopes of applicability beyond that they become increasingly burdensome to use (or not possible at all). Rust is a systems programming language, it fits were C or C++ may fit, ML modules can be implemented in it. Python is, however, good for prototyping, glue-like language that can be used interactively (hence jupyter) and that's the main reason it got popular in ML: when developing a model, one wants to focus on model, ease of visualization, not some low-level details and since the basic building blocks are implemented in C++/utilize vector instructions/GPUs, Python's ease of tinkering outweighs its poor generic performance since almost no number-crunching takes place in the Python part. Even when it starts to bite, there are ways around it (there are libraries allowing various strategies of JITting performance critical Python code: pypy, numba, pyjion, ...).

[@mishikookropiridze]

@@JanuszKrysztofiak correct, altough none of them are production ready JIT.

[@DummyFace123]

“I don’t like it’s some dude’s laptop” then do it

[@JuusoAlasuutari]

2023 is the year of C on the web

[@daniel-wood]

God, I hope so. Sometimes I wonder if JS and Typescript were written specifically to cause as much suffering as possible. I wouldn't bet on it, though.

[@Titere05]

That would mean they had something specific in mind when they were building JS, which they didn't, as they wanted it to be eveything and also nothing

[@ChamplooMusashi]

They did have something in mind and it was java. And you can blame Microsoft for js not being typed

[@okie9025]

TS is a lot more enjoyable to write than Rust imo.

[@hrgdavor]

What is that about:" service that will always work ? all errors will be handled". ... that is a pipe dream. Not all errors are recoverable, and if you ccan not ignore it up-to certain checkpoint, u are fkd.

[@ThePrimeTimeagen]

of course, if you run out of memory (oom) there is no recovery, but you can still handle it. all errors are _handled_ whether you ignore them or not, in JS you don't know what errors do what or when and are often handled some distant point from where they were created thus making sensible recovery virtually impossible.

[@hrgdavor]

@@ThePrimeTimeagen I had a bad experience with Hibernate in Java, when in older version all methods threw checked exceptions. That was HELL. It may not be applicable to what you are saying in the vide, and how it is handled in Rust. In my 25 years working with JavaScript I have not had problems with catching errors after IE was killed. Even then it was not that big of an issue.

[@KoltPenny]

Was it ever beaten by js?

[@fatmilf1498]

If it does, it does. Until then I couldn’t care less

[@_____case]

"Golang is probably the most superior language right now for backend development." - Prime

[@okie9025]

Ah yes I love writing my secure, standard-compliant, configuration and model-based REST APIs in *procedural code*. Yay.

[@_____case]

@@okie9025 What would you use instead? If your application is CPU bound, it seems like Golang is a very good option, or if you want to really save on resources at scale. But for my purposes, I probably wouldn't reach for Golang.

[@balen7555]

@@_____case Rust. Better in every way beside being less simple

[@_____case]

@@balen7555 That "less simple" downside is a big one. Most projects are bound by development time, and Golang has a much smaller dev cycle and learning curve than Rust. But tbh, I would reach for Node/Deno for most projects, unless the application is *actually* CPU-bound.

[@blackdereker4023]

While Rust's performance benefits are impressive, its steep learning curve may hinder its adoption compared to JavaScript/TypeScript. For most web development tasks, availability of libraries and ease of development are prioritized over raw performance. Rust's strengths really shine in heavy real-time calculations, such as simulation projects, but for general applications, JavaScript will likely remain the more popular choice. However, as Rust's ecosystem continues to mature, it may become a more viable option for a wider range of web development tasks.

[@HermanWillems]

Ah thats because companies want webdevelopment to be easy so they can outsource it to some indian sweatshops. I understand. The best is offcoarse having the best of both worlds having performance and ease of use.

[@blackdereker4023]

@@thelvadam5269 What matters is the point I'm trying to make, not the tool that I used to write it.

[@Pawnlust]

@@blackdereker4023 It's dirty to post AI generated text without stating.

[@blackdereker4023]

@@Pawnlust If it aligns to what I believe, who cares?

[@Pawnlust]

@@blackdereker4023 It's plagiarism. You're pretending to have written it and it's supposed to be a personal expression that came out of a human. To do otherwise is to be a fraud in an area that is most tied to your person.

[@Mth-Ryan]

Hey. I want to write a simple blog from scratch. I would like to maintain only one service, so the project started with Sveltekit. But I really want to try this in Rust (because I hate typescript). Do you have any libs or framework ideas I can use for this?

[@okie9025]

Wow, Svelte and Rust. You really drank the koolaid huh?

[@Mth-Ryan]

@@okie9025 Yeah. Well, I just wanted to try something different than my usual Stack, but yesterday it proved to be a really bad idea.

[@code-chronicles]

I did pressed the button already

[@amasoharnold4762]

I keep wondering why which language would be good for backend if performance is your concern I'm contemplating between Node, go or rust I hear rust is pretty cool in terms of performance but I can't make a case for it with the steeper learning curve I mean imagine I was building a server that was handling < 1 million crud operation wouldn't node or go still suffice In terms of performance would it matter much if you use rust maybe you have a server with low specs would rust use your resources more efficient than node or go Or for the use case of < 1 million users it's just overkill

[@ThePrimeTimeagen]

go is simple and best bet to get most perf without significant learning curve rust is fastest node is slowest

[@amasoharnold4762]

@@ThePrimeTimeagen Thanks for the reply Although I'm not totally sure what is meant by fastest like in what terms If I have a server serving files would rust and go outperform node ? In what way is it like if it takes node 300ms to serve files it'll take go like 150ms and rust 60ms is that how we know which is fast I hear Netflix uses node from a course I took a couple years back from ZTM the person teaching the course said so since node is like really optimized at doing these tasks (serving files efficiently) If the statement is true and Netflix are using it to serve video doesn't it mean for any startup node should be good enough even if it's though of as being slow

[@okie9025]

Node is only a few milliseconds slower than Go/Rust. Even if you are serving more than a million users, Node will be more then enough.

[@Tony-dp1rl]

Everyone knew before watching this, that the answer to the posed question was No.

[@freaklore]

If Rust doesn't beat JavaScript then perhaps another language will rise up one day. The development community can do better and create something else far superior. Focus on speed and simplicity with a small footprint.

[@okie9025]

Speed is the last thing that new languages should focus on. If you really need speed, you should be ready to drop down to assembly if needed. Switching to a new language is not worth it. In fact, instead of making new languages, why not improve JS?

[@HelloThere-xs8ss]

Dom stuff will still be done in js. But anything computationaly complex will be done in another language and compiled to wasm

[@austincodes]

Front end masters... Isn't that fast

[@AmstradExin]

This guy sounds like he watched the entire channel of "Programmers are also human" with his morning coffee today.

[@erictrinque6513]

Josh Mo.. jos hMo.. jo ShMo

[@Makeshitjusbecuz]

I dont think so. As much as everyone would love and think they would love it. Thats not how a majority of companies work. Specially when you're dealing with clients who change entire features over night and expect fast development.

[@noahg2]

Rust will beat javascript just like how linux will beat windows, that's how I am feeling about it right now.

[@NathanHedglin]

Linux is the most used OS for Servers and mobile thanks to Android.

[@noahg2]

@@NathanHedglin 🤣 where are you getting those numbers ? A good chunk of server OS is still dominated by windows and that's more than 50% globally, Android uses modified Linux kernel BTW, it's not an official distribution of Linux. I can post links but KZbin will delete my comment if I do, go research the market share OS.

[@lasuch4389]

@@noahg2 Windows isn't popular on servers, even M$ uses Linux on their cloud service (Azure). Web literally runs on Linux, and 500 most powerful supercomputers run Linux. No one uses Windows on a real server.

[@noahg2]

@@lasuch4389 500 most popular websites use Linux I agree but that's not majority of web.

[@okie9025]

"just like linux will beat windows" HAHAHAHAAHAHA good joke my man you made me laugh

[@music4life467]

rust cant beat javascript of its popularity and its is very easy to use in terms in front-end,,, every project i saw in web use javascript thats why its the top 2 rank in the world ... but in term of speed of the applications rust is best for it... to make rust popular it must be a c++ or c-style coding syntax... because i like the rust how it implemented because it offer a safety memory or safety program as possible.... thats why rust is powerfull for that.... but it can beat javascript ,,, if that can be a javascript... c or c++ is ahead of javascript since javascript is made in c..

[@ramfattah211]

dotnet 💙

[@frittex]

I hope so tbh

[@jogurtnaturalny]

Coming back to this after 9 months, I can say... No, rust is not new JS! HTMX manage to take a lot of wasm interested developers ( like full stack or backend ) who do not want to code in this insane language.

[@yuryzhuravlev2312]

I think no! Svelte the best!

[@tsalVlog]

You said something that triggered me - signals. It's why I hate EVERYTHING react-like. Not because signals are bad, but because .. every. single. framework. that implements them, does it in a wonky, backwards way, that either impacts development speed, or runtime speed -- to a great degree. I feel weird saying this, but Objective-C had a better signals implementation than RxSwift's, and the Swift wrapper around it suffers for being very poorly documented. If that weren't true, no one would use RxSwift; we'd implement bind in an extension and be done with it.

[@ThePrimeTimeagen]

i really like solid, i think they are great there

[@tsalVlog]

@@ThePrimeTimeagen I have looked at solid, I just haven't used it for anything as of yet. I keep hearing the same thing -- it's better than many other implementations, despite the shortcomings of JS. I suppose this means I should give it a fair shake.

[@EightSixx]

Go FTW!

[@NathanHedglin]

It is exciting but it is a long way from really being competitive.

[@nexovec]

I love how "javascript vs anything" always just boils down to "javascript vs first-class browser support for literally anything else"

[@Danielo515]

Short answer: no