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 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.
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.
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
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.
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).
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
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)
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
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.
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!
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).
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!
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.
@@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
@@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.
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.
@@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.
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.
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.
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
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.
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
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
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.
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.
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#.
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.
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 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.
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 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.
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.
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.
@@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.
@@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.
@@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.
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.
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.
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.
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.
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 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.
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.
"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.
@@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...
@@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.
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.
@@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
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.
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.
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
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.
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 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.
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).
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.
@@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.
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, ...).
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?
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.
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.
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.
@@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.
@@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 TH-cam will delete my comment if I do, go research the market share OS.
@@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.
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.
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.
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?
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.
@@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 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.
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?
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?
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 :)
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..
What's the point of using a systems programming language for web front-end? Number-crunching/performance-critical parts can be outsourced to WASM modules, that makes some sense for Rust there. For the UI part, however, ss much as awful JS is, TypeScript makes it slightly more palatable and much quicker to develop in than Rust. Why to to bother with borrow checker if a GC fits nicely in this application? Web front-end is very high-level anyway, so there is little to gain from performance point of view, yet much to lose in terms of development effort. Generally, sluggishness of web pages is not caused by the language run-time, but deeper architectural choices both at the level of frameworks and the very foundation (DOM, CSS). Heck, even single-threadedness of JS is not much of an issue as long it is used only for UI, because UI toolkits in general are pretty much single-threaded when it comes to manipulation.
Exactly. I'd much rather have a "JS plague" than a "Rust plague". Rust is trying too hard to be a generalist language that it often fails miserably in making the developer experience good.
Really don't like the antagonistic characterization out of the gate of "soy js devs" and rust devs. I can just write JS and ship a script tag on an HTML doc and generate value for my users. I love Rust getting into the front end tooling space, I am eagerly watching several projects that should help speed things up and make tooling more reliable. No matter what, trying to get ActiX Rust to do everything is as foolish as trying to get Express on JS to do everything. Sometimes a static HTML with some links to resources it the best solution for the job. Your gripe with the definition of DX is a lame ass take bruv - big L on that one. Grunt/gulp/angularjs/requirejs... remember those days? Sprinkling TS in a Knockout MVVM project? Let's gooooo. Nothing _really_ matters I guess - just write your shit in rust and get off your circlejerky high horse. Happy users can be gotten with HTML+CSS+JS - when you add Rust there is no world in which you can have less or equivalent pieces of the stack. You _always_ will be adding rust. (ie it has to be HTML+CSS+JS+Rust, because of how the web platform has evolved). /rant /like /continueswatching
I _really_ like @gbjxc 's take in here th-cam.com/video/4KtotxNAwME/w-d-xo.html where he dives into specifics and tradeoffs. It is looking like a really great year for rust, and there are for sure sensible rust+wasm+js based solutions for the client space, but it's not all or nothing and incremental adoption is the way of the web. Also FormData sucks.
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 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.
If chatgpt writes things for me, Prime reads things for me
yayaya
And both can barely do it properly
He also jumps while reading, but chatgpt can't
(i also use it for reading but maybe that's me..)
invited
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.
Steelmanning should be the default for all arguments.
@@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.
Dioxus doesn't use signals btw.
it uses the React model, but with compile time macros that remove unnecessary comparisons at runtime
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.
@Lena @ui_wizard didn't know that, thank you both
I've seen "HTTP" pronounced as "hot potato"
And "HTTPS" can be pronounced as "hot potatoes"
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
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.
@@BosonCollider Dope. Big learning 🙌
That's why we got Svelte and Solid
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).
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
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)
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.
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
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.
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!
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).
rust on the backend
solidjs on the front
dioxus on the front :p
@@ThePrimeTimeagen Weird interpretation of the mullet, but I’m here for it.
@@SpaceChicken funny seeing you here, space chicken
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!
it was a great article. i really did like what it was saying!
i hope you don't take anything i said as negative :)
@@ThePrimeTimeagen No definitely not, I appreciate that some parts were probably somewhat pointing in the wrong direction 😆
@@joshmo3611 he's lying, he hated it. He told me off stream.
@@joshmo3611 Blog link isn't working now.
I REALLY agree with your comments on "developer experience"
^^
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
In speed? Probably yes. Good luck finding devs to meet the demand.
For me, it's good luck finding projects with Rust.
@@serhiiway the story goes both ways
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.
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.
That and understandably the documentation for most rust web libraries/frameworks is nowhere near what's available for j*******t as of now.
@@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
@@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.
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.
@@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.
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.
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.
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
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.
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
@@ThePrimeTimeagen we can only hope
@@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.
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
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.
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.
Prime got Flipped at the end. I love it.
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.
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.
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#.
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.
Azure is good?
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
how about Discord, they used elixir then go then eventually rust
@@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.
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.
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
From where are you learning? Can you share your ways
@@anmolsharma4049 The Cherno youtube channel.
@@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.
@@lazyh0rse thanks
a whole host of issues with typescript will be fixed as long as you use `satisfies` instead of `as`
As a native android developer i'm curious to try kotlin/wasm with Compose
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.
Just check out where is Elm on that list. But yeah, we should stick to typescript and react/angular
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.
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.
@@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.
@@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.
@@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.
flip, please keep it, i like that
Normally I don’t listen to just any jo shmo, but I’m intrigued
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.
9 minute read to 23mins decompression is impressive. Luv it.
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.
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.
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.
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.
@@thelvadam5269 What matters is the point I'm trying to make, not the tool that I used to write it.
@@blackdereker4023 It's dirty to post AI generated text without stating.
@@Pawnlust If it aligns to what I believe, who cares?
@@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.
tis is why the core behind elixir is so robust because it is used in the telecom industry for serious uptime.
Rust foundation really has me questioning my time with Rust TBH
same
hey bro keep us motivated
@10:32 my man never used C# with ASP. You would be amazed how this is since in C#.
MAN IS LITERALLY NAMED JOE SHMOE. WE FOUND HIM
I would really like to see you making a video on shuttle, I personally really liked shuttle
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.
TIL about `strictNullChecks`. Thank you :)
"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.
@@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...
@@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.
"There's plenty of ways to make an app. At the end, it's how happy your users are." GOLD
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.
@@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
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
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.
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.
No you shouldn't.
Please do not drink the koolaid. Rust is not a silver bullet and there is a reason why it's still not popular.
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
@@thekingofpotatoes1932 I mean I could learn rust by porting over a backend service but I think my co founder would just die 😂
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.
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
They did have something in mind and it was java. And you can blame Microsoft for js not being typed
TS is a lot more enjoyable to write than Rust imo.
HTML will be them all in 2030.
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.
what are you doing in seed exactly? is the webdev good? i've been thinking of getting into seed.
@@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.
I'm refactoring a react rocket app into a leptose front end with rocket right now.
PS, rust analyzer is amazing
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).
yeah, zig is really interesting
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.
@@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.
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, ...).
@@JanuszKrysztofiak correct, altough none of them are production ready JIT.
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?
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...
would be curious your thoughts on flutter / dart
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.
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.
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.
@@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.
"all errors will be handled" sure, what about panics?
21:00 hittipee
I watched a few videos about Rust yesterday. What’s next on my journey?
Rust will beat javascript just like how linux will beat windows, that's how I am feeling about it right now.
Linux is the most used OS for Servers and mobile thanks to Android.
@@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 TH-cam will delete my comment if I do, go research the market share OS.
@@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.
@@lasuch4389 500 most popular websites use Linux I agree but that's not majority of web.
"just like linux will beat windows" HAHAHAHAAHAHA
good joke my man you made me laugh
2023 is the year of C on the web
9:55 At least in axum they are called extractors.
Why's your previous videos not available on twitch anymore?
Nothing can beat Javascript untill it can run in the browser
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.
“I don’t like it’s some dude’s laptop” then do it
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.
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?
Id become a front end dev again if that were the case... 😢
What your thoughts on elixir and phoenix?
is wasm still a thing? i have been waiting it to "take over everything else" for years
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.
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.
@@bmurph24 ye, i believe it have some use cases, but thinking it will take over js seems too much
"Golang is probably the most superior language right now for backend development." - Prime
Ah yes I love writing my secure, standard-compliant, configuration and model-based REST APIs in *procedural code*. Yay.
@@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.
@@_____case Rust. Better in every way beside being less simple
@@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.
Everyone knew before watching this, that the answer to the posed question was No.
No no no, it's gonna be *Mojo 🔥* FTW!!
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?
This guy sounds like he watched the entire channel of "Programmers are also human" with his morning coffee today.
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?
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 :)
07:47 why not just use (replace * with url) tags or are you talking about non-web browsers like deno?
Soy developers like Theo 😂
I hope so tbh
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..
Rust frontend, Go backend. Don't @ me.
😂😂😂
Man is using a systems language to make his UI lmao. I sincerely hope your website isn't more complex than TodoMVC else I pray for your sanity
How would it compare with Svelte
Svelte is JS bro
I love how "javascript vs anything" always just boils down to "javascript vs first-class browser support for literally anything else"
I did pressed the button already
What's the point of using a systems programming language for web front-end? Number-crunching/performance-critical parts can be outsourced to WASM modules, that makes some sense for Rust there. For the UI part, however, ss much as awful JS is, TypeScript makes it slightly more palatable and much quicker to develop in than Rust. Why to to bother with borrow checker if a GC fits nicely in this application? Web front-end is very high-level anyway, so there is little to gain from performance point of view, yet much to lose in terms of development effort. Generally, sluggishness of web pages is not caused by the language run-time, but deeper architectural choices both at the level of frameworks and the very foundation (DOM, CSS). Heck, even single-threadedness of JS is not much of an issue as long it is used only for UI, because UI toolkits in general are pretty much single-threaded when it comes to manipulation.
Exactly. I'd much rather have a "JS plague" than a "Rust plague". Rust is trying too hard to be a generalist language that it often fails miserably in making the developer experience good.
quite gay to use backend for frontend.
ru*t
Dom stuff will still be done in js. But anything computationaly complex will be done in another language and compiled to wasm
It is exciting but it is a long way from really being competitive.
Josh Mo.. jos hMo.. jo ShMo
Was it ever beaten by js?
If you can make Rust as easy as JS/TS, then I’d be happy to do so. But until then, meh.
Really don't like the antagonistic characterization out of the gate of "soy js devs" and rust devs. I can just write JS and ship a script tag on an HTML doc and generate value for my users. I love Rust getting into the front end tooling space, I am eagerly watching several projects that should help speed things up and make tooling more reliable.
No matter what, trying to get ActiX Rust to do everything is as foolish as trying to get Express on JS to do everything. Sometimes a static HTML with some links to resources it the best solution for the job.
Your gripe with the definition of DX is a lame ass take bruv - big L on that one. Grunt/gulp/angularjs/requirejs... remember those days? Sprinkling TS in a Knockout MVVM project? Let's gooooo. Nothing _really_ matters I guess - just write your shit in rust and get off your circlejerky high horse.
Happy users can be gotten with HTML+CSS+JS - when you add Rust there is no world in which you can have less or equivalent pieces of the stack. You _always_ will be adding rust. (ie it has to be HTML+CSS+JS+Rust, because of how the web platform has evolved).
/rant /like /continueswatching
but... how do you really feel?
I _really_ like @gbjxc 's take in here th-cam.com/video/4KtotxNAwME/w-d-xo.html where he dives into specifics and tradeoffs.
It is looking like a really great year for rust, and there are for sure sensible rust+wasm+js based solutions for the client space, but it's not all or nothing and incremental adoption is the way of the web.
Also FormData sucks.
You start hot, but at around 22:50 you relent and say TS is easier to develop in!! GAAAAH you drive me crazy.
@@ThePrimeTimeagen Like a flickering flame
agreed.
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.
i really like solid, i think they are great there
@@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.