Recorded live on twitch, GET IN / theprimeagen Original: joshuamo876.be... MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord
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.
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)
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.
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
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).
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
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!
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
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 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.
@@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 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!
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.
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.
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.
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.
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.
@@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 RUclips 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.
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.
its a great insult you got neckbeards and soydevs. why get triggered? call me a soydev, don't care, call me a neckbeard don't care, call me an incel, still don't care
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.
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.
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.
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 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
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.
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.
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..
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 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.
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
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.
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?
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.
rust gui and web frontend are hot garbage for now. They may improve in the future but who knows when. I say this as a rust programmer for 5 years and use it daily. For any web frontend I would encourage people to stay with javascript and only introduce wasm when you are absolutely sure it make sense(which is not for 90% of use cases). and btw wasm is not a rust only thing.
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 :)
@@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.
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?
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?
Наука
![OsamaSon - ik what you did last summer [Official Music Video]](http://i.ytimg.com/vi/4DIQDnu3mr4/mqdefault.jpg)
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
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)
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
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
I've seen "HTTP" pronounced as "hot potato"
And "HTTPS" can be pronounced as "hot potatoes"
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).
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
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
I REALLY agree with your comments on "developer experience"
^^
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.
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
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.
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.
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.
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
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.
Rust foundation really has me questioning my time with Rust TBH
same
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.
a whole host of issues with typescript will be fixed as long as you use `satisfies` instead of `as`
HTML will be them all in 2030.
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!
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.
MAN IS LITERALLY NAMED JOE SHMOE. WE FOUND HIM
Soy developers like Theo 😂
"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
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.
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.
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.
As a native android developer i'm curious to try kotlin/wasm with Compose
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
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 RUclips 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
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.
I dislike lingo like "soy dev", but your video's are otherwise very entertaining.
its a great insult
you got neckbeards and soydevs. why get triggered? call me a soydev, don't care, call me a neckbeard don't care, call me an incel, still don't care
^ found the soy dev
@@NathanHedglin LMAO
Normally I don’t listen to just any jo shmo, but I’m intrigued
Prime got Flipped at the end. I love it.
@10:32 my man never used C# with ASP. You would be amazed how this is since in C#.
flip, please keep it, i like that
ru*t
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?
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.
hey bro keep us motivated
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.
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.
Just check out where is Elm on that list. But yeah, we should stick to typescript and react/angular
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
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.
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.
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.
Nothing can beat Javascript untill it can run in the browser
I'm refactoring a react rocket app into a leptose front end with rocket right now.
PS, rust analyzer is amazing
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..
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.
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
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 😂
2023 is the year of C on the web
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.
It didn't beat it in 2023. Maybe 2024 though.
9:55 At least in axum they are called extractors.
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
Rust has too much complexity to be productive
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.
This guy sounds like he watched the entire channel of "Programmers are also human" with his morning coffee today.
before rust AI will beat programmers
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?
Everyone knew before watching this, that the answer to the posed question was No.
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.
Why's your previous videos not available on twitch anymore?
rust gui and web frontend are hot garbage for now. They may improve in the future but who knows when. I say this as a rust programmer for 5 years and use it daily. For any web frontend I would encourage people to stay with javascript and only introduce wasm when you are absolutely sure it make sense(which is not for 90% of use cases). and btw wasm is not a rust only thing.
Spoiler: it didn't
I think no! Svelte the best!
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...
I guess it didn’t
"all errors will be handled" sure, what about panics?
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 :)
I only use batch language, everything else is soy
07:47 why not just use (replace * with url) tags or are you talking about non-web browsers like deno?
I watched a few videos about Rust yesterday. What’s next on my journey?
dotnet 💙
"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.
I would really like to see you making a video on shuttle, I personally really liked shuttle
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?
LMAOOOOOOOO
What your thoughts on elixir and phoenix?
How would it compare with Svelte
Svelte is JS bro
would be curious your thoughts on flutter / dart
Id become a front end dev again if that were the case... 😢
tis is why the core behind elixir is so robust because it is used in the telecom industry for serious uptime.
“I don’t like it’s some dude’s laptop” then do it
I did pressed the button already
No no no, it's gonna be *Mojo 🔥* FTW!!
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?
Josh Mo.. jos hMo.. jo ShMo
21:00 hittipee
I hope so tbh
Was it ever beaten by js?
Link is 404
HTTP == Hat to pee