The new Rust/WASM powered Rust Adventure site is live now at www.rustadventure.dev/ and the discord server is now open if you want to learn Rust: discord.gg/2FwB9EqCGs
Trunk has a problem while running with ARM processors Reason I found was related to wasm-binaryen which is used to make trunk Binaryen package is not optimised for ARM processors which Is causing rust developers using ARM processors struggle to get there UI frameworks work
that's interesting, I run an m1 as my primary machine and I haven't had any issues. Looking at the issue tracker it seems like this was resolved back in 0.16
Great story about how Node was an entrypoint to many topics. I think it is sometimes overlooked that JS as language and Node.js as ecosystem have allowed a lot of pople to learn building systems and advance into more complex domains.
Rustjerks would disagree 😂. Even though I'm gradually moving solely into Rust, I would never 💩 on the Node ecosystem because it has enabled me to do sooo much. I moved to JS back in the day from much more powerful languages simply for the ease and access that Node provided me. Yes, there's good and bad in every ecosystem but if you're a good enough dev, you know exactly how to apply the filter.
@@m4heshd Building in TypeScript was fun for me. I lacked fun with PHP, Ruby, C#. I will never shit on NodeJS, but we can leave it behind going forward. I don't believe evething in Rust though
I’ve been interested in learning Rust but I was under the impression it was mostly for low level embedded stuff. Seeing the flexibility and usability of Rust across a wide domain has been a much needed and I’m excited to give it a go!
I was under the same impression, but after looking deeper into it that's clearly not the case. It seems to be because it can be used to replace C++, people assume that's all it's for. Just started reading The Rust Programming Language recently and I think I'm in love.
It's a bit clunky to use for some things due to the restrictions that are set in place, using it for an API will end up with you needing to manually register all routes for example (haven't found a way to do it dynamically at the very least). That's not really the end of the world, but it is just one of those things that makes it a bit less appealing for such work. I absolutely do recommend trying it though. Even if you don't end up using it a lot, it can teach you a lot about how to think about code.
@@CottidaeSEA yeah a month in and I’m probably still going to use typescript/Go for api stuff. I will say I’ve really loved rust for CLI stuff and tooling tho. Replaced some old Python tools at work with rust and the increase has been nuts. I just wish the standard library was more robust like Go.
Great work Chris! I love how you shared your entire journey and the decisions you ended up making for the new site! I’ve been an early adopter of Rust Adventure and I’m excited to see how it will continue to evolve over time! Seems like some great bets so far.
In recent days, I've started learning more about Rust. This clip really sells it. I think I'll jump on the bandwagon and take your RustAdventure course.
as an amateur haskeller, I must say what attracts me of Haskell is not its direct useability but how it forces you to think of the domain problem and break it into its fundamental rules and components (types). I'll keep writing Python and probably pick up Rust soon, but I'll keep using Haskell to prototype stuff just to remind myself of how a good design should look like.
Yeah I definitely think that's the biggest utility of Haskell these days: as a language that forces you to think about problems in a different way, that you can then use to apply to the way you use other languages. It's the same for a bunch of languages I think. If you really want to understand the actor model, then erlang is a great environment to do that in, for example.
@@chrisbiscardi It feels so absurd to me that Rust is the only mainstream language that has adopted Algebraic Data Types and Type Classes from Haskell and similar languages. It's the obvious way to model data. I also feel that Rust's ownership model can give many of the advantages of purity by forbidding mutable aliasing, which is one of the largest sources of bugs related to impurity. Because of the lack of mutable aliasing, a Rust function that takes a mutable reference `fn foo(x: &mut Bar)` is roughly equivalent to a pure function `fn foo(x: Bar) -> Bar`.
@@asdfghyterhow is it obvious? normal programming is obvious. ifs are obvious, classes are obvious, etc. but functional programming like pattern matching and monads are not obvious at all.
@@donkey7921 monads are clearly not obvious, but pattern matching is. classes are not in any way obvious, you’re just used to them. and as rust has shown, tagged unions/ADTs/sum types and pattern matching are not in any way specific to functional programming what i mean is that if you would informally talk about data, you would very often do it in terms equivalent to sum and product types. “you would get either this thing or that thing” = “sum type”. and you also often write a poor man’s sum types in a program without the safety guarantees, e.g. when a function returns a status code that tells you if the other returned value is valid, instead of a Result type. and let’s not forget null pointers, which are just the Option type in disguise (but without any way for the compiler to tell if you’ve checked it). and similar to null pointers we have returning special magical values for non-pointer types to signify failures (e.g. negative number = failure), which are also Result types. sometimes a class hierarchy can make sense, but often it feels artificial and it would be much nicer to just say “this is one of these three things”
@@donkey7921 It's much easier than it sounds. Monads are a box with a value, it gives the value a set of rules to follow so you can compose or pass it around to functions. The rules allow you to treat the box the same way regardless of what the value inside it is. It makes your program simpler because the value in the box could be null or an error, your functions don't care, you only need to handle it when you check inside the box. If you've used promises in javascript, you probably know enough to use it.
3:26 I tend to write a lot fewer tests in Rust than I did in other languages. Maybe it's the culture of my workplace but also if it compiles, it works. Tests run in CI and I forgot when was the last time I got an email alert with a failure.
This video was the type of ecosystem overview I needed to put rust into context of all the things I do with the JVM, js/ts and python. I try to learn a new language every year or so, and this year it’s rust. Unlike most of the other languages I’ve dabbled in, I’m starting to feel like rust might be a place I could live for a little while. I haven’t felt that way since I started really loving kotlin a few years ago.
just wanted to ask a quick question as a person of mostly backend which books have you read primarily to understand the concepts like these ??? are there any list of books? or it's just a few books which gives the impact?
I was hesitating to pick a programming to adopt a programming language as I am trying to get back to software development and I was stuck and indecisive about Rust, that video help me make up my mind, I will be taking the rest of the year to embrace Rust fully. Thank you
Well, I just started going into Rust with no idea what I am doing. You did give me a whole lot of things of what I can do with it. I come from react, java, node side, apart from rust being a low-level programming, this video sure widened the scope for me, thanks :)
Your bio is so similar to mine :) I started with AS too, but skipped nodejs because I always hated JS. Erlang and clojure are in my collection too, but I did Elm instead of Haskell, and really lerned a lot from it. Now I'm learning Rust (ecosystem mostly), and I hope I won't need to learn another language in near 5+ years, because I want to become a pro in Rust. While I'm learning, I hope wasm Rust tooling for usual HTML/CSS stuff become more mature, though I don't like the idea of keeping logic/state on frontend, some glue is needed anyway. I waited so long to be able to avoid JS on frontend completely, and last few years I noticed this is possible, and I finally can do frontend tasks and sleep well after deploy :)
Tbh i would be really interested learning about what open source crates we can use as Rust devs creating web UI, since i feel one of Rust's big strengths is how plentiful, reliable and modern its packaging system is. I personally am learning Yew (Similar to React) to rewrite my app, using Cargo Features to either run on the web using REST APIs or run locally using Tauri depending on build. However, I haven't seen much of whats available in terms of elements, design aids and other utilities. I've found Rust a very exciting, refreshing and comfortable language to write in, coming from a C# background. It feels like everything I wanted from C# without much compromise, and even some things i didnt know i wanted!
I'm right on the verge of diving into the Elixir garden, and learning the tools to work with Phoenix LiveView. Basically because it ticks every box when it comes to some of the projects I'm involved in. I'm really hoping that one of these WASM Rust crates will come along and do the same soon - ideally, this week 😆 Thanks, interesting video.
I am only two minutes in and I am really appreciative of the journey you've shared thus far and I am excited for the rest of the video. I've been very interested in learning Rust and have found a few folks who seem like solid folks that I've followed on Twitter for a bit and it seems to me like it's at a point where maybe Node was in its formative years? I am curious your thoughts on where Rust is heading and your sense of how it compares to the Node Community formation! I look forward to hearing back!
@chrisbiscardi I am curious if in the future you'd be open to discussing the migration away from GraphQL and instead moving to axum+tokio with MySQL. I work in the GraphQL space and I am very much interested in understanding where it serves and where it doesn't. 🙏
I'd generally agree with that assessment. I think there's actually *literally* people coming over from JavaScript to Rust, as well as it feeling very formative in a similar way right now. There's a lot of crates that already exist, but also the opportunity to write "The X crate". It also seems to be a further expanding of the types of software people can write beyond the expansion that nodejs offered around the time it came out. For example, writing kernel extensions in JavaScript isn't really going to happen, and embedded development has certain restrictions, but Rust supports these sorts of environments well. The migration away from GraphQL was a migration away from AWS AppSync (and mostly Amplify specifically). GraphQL-the-concept is something I think is still very viable. At the time I wasn't sure if I could find a Relay-level client for Rust and even if I could, if that would work well with where Leptos was going. I knew REST was going to work even if it meant I made more endpoints for different use cases and such. I don't know that I'd advocate for building GraphQL servers yourself? but Hasura is really nice if you don't want to and I think I'll get into writing GraphQL servers in Rust at some point, which will predictably turn into RUclips videos when I do. I've been using GraphQL since it came out in a whole bunch of scenarios and I still like it, but I definitely wanted to distance myself from Amplify.
@@chrisbiscardi Thank you for the reply! I want to take a few moments to process what you've shared and I'd love to follow up. I'd love to continue short exchanges of thoughts like this in the future if you're open to it, definitely async to allow followup when time, bandwidth, want allow. I connected with you on BlueSky 🙏
I think its not just javascript that rust is competing against. Its the frameworks. I think vanilla js vs a decent frameworks is no competition. These frameworks are explosive in productivity and easy to work with in a team. I think rust has real potential in the low level hardware community. But I mean, python was the hot thing 5 years ago and people said the same thing you're saying here. Even the node js package manager is hard to ditch as its incredibly convenient. Personally I'd prefer to see more Rust examples of it replacing audio tools but thats just me.
In Rust WASM builds and JavaScript apps, one can easily fall into the trap of “including a large library for a single function and your final bundle size includes the entire library rather than the only functions you use”. Are Rust/WASM bundle sizes easier to optimize than Webpack JS bundle sizes?
This specifically is a harder trap to fall into because dead code elimination is built into the way Rust compiles, especially compared to JavaScript where dead code elimination is often treated as a special process or is actually not possible, as was the case with a lot of commonjs code that used a more dynamic require style compared to esm. on the more general question of whether its easier to, I'd say yes but obviously this is dependent on the person doing the optimization, their own experience, and specific goals. wasm doesn't currently "code-split" for example. I say yes specifically due to the fact that when you make such changes in Rust they tend to persist rather than be accidentally reversed, and Rust has the ability to work in highly restricted environments like embedded and no_std. This means there are both very general automatic tools, like dead code elimination or upping an optimization flag, as well as concrete steps you can take to move closer to a no_std style program. Here's a decent overview of techniques: rustwasm.github.io/docs/book/reference/code-size.html
after building in rust did you feel that the website was more resilient? do you have any data on if it crashed / errored less? (no disrespect just curious)
Over time I've noticed that issues with data are basically gone. I never have to worry about a field existing or not existing, which I often had to double check in the live site when using JavaScript. Leptos is also getting better and better. The 0.7 release is really exciting and I've been working with the Islands features more and more which reduces the payload to the browser and such. The servers have been incredibly stable. They don't randomly go down at all and any issues in the application logic are pretty easily traceable to an .unwrap() or similar. They also use very little resourcing. I'm at a conf right so so don't have any numbers, but I also changed the architecture on a few sites from being static to running a Rust server and it's been just as low effort operationally.
I'm working on a video about stream processing to give some background using arroyo to contextualize it. What do you find interesting about Surreal and Fluvio?
Surreal is multimodal and supposedly fast. Saw some demos where they smoked financial data. It's easier to manage database and API schema. They just closed a phat funding round Then fluvio has crushed as a Kafka replacement in the cloud, helping save a node operator 10x on their data fees. This huge saving was a result of the increased memory efficiency of Fluvio They're both written in Rust 💜🦀
Amazing video! 15 minutes passed by easily. One thing I'd like to mention is the possibility that the Rust ecosystem might possibly go down the same track as npm; and the reason being the lack of a strong STD like .NET. We're already seeing rust packages that have 400s of dependencies for small-sized projects, let alone bigger ones. With it comes the risk of exactly what made you leave JS, which I do hope I am wrong about (and willing to get corrected if so).
glad you enjoyed it! The Rust crates I see that have that kind of dependency graph are the ones that typically make good use of them, like Bevy for example, so while I can see the concern (especially if you're familiar with the JS ecosystem) I do think its less of an issue with such a well-typed language compared to JS. I have two thoughts really: 1) we never really know how an ecosystem will evolve over time. It may turn out that Rust develops some of the same problems for whatever reason. I'm pretty happy with the ratio of "stdlib" to "3rd party" right now. Things in the stdlib are generally super stable and reliable, which I really like. I'd rather not end up in the situation where the stdlib is somehow "out of date" and no longer the recommended approach like has happened in other languages. 2) there will be another language after Rust. Rust is not the "ultimate language" (or however you'd phrase that) and language design research has kept going regardless of what the industry is using. Rust is great and I feel that it will be around for a long time, but it won't be the last language I ever learn. Also I don't consider myself having "left JS". I do prefer Rust these days, but JS is still a language that I keep up to date in my toolbelt.
I'm literally doing this right at this moment 😆. I know RIIR has become a meme, but things are just infinitely better when written in Rust. But the biggest thing for me was, rewriting my own code in Rust has improved my knowledge in Rust exponentially.
I also feel that a major benefit of Rust is actually _not_ having to rewrite everything in Rust, and instead binding rust within an existing application, basically the exact opposite of the meme.
I just did a research regarding doing a GUI in Rust. I found that this still is rather bleeding edge, while many other other aspects in the rust universe seem much more advanced. In fact I would like to see a single well supported tool that can be used for both local UI (Desktop and portable) and for WEB UI. I do see that it does not make much sense to only provide a "one fits all" workflow that results in a program source code runnable everywhere. But for very simple (ugly) GUIs, this should in fact be possible. For more complex applications the tool should provide a decent workflow for each OS / widget library (including DOM). Optionally a WYSIWIG Gui Builder should be provided. On top of that, a well defined internal (e.g. Websock based) API should allow for easy and flexible separation of server based and client based parts of the user application (both of course done in pure Rust code.) Is something like this only possible in a payed product or will the community be able to provide something like this (in contrast to the many smart but bleeding edge projects currently in the works) ?
if your codebase initialy come from JS/TS, try to move to bun first, i just do it for my React Native Codebase, and run faster for install dependency/update or etc
Stack is Leptos/Rust/MySQL/sqlx/axum. Source for the app is not available but I'm working on some Leptos workshops that will go up on rustadventure.dev
Many thanks or the very instructive video As you asked for such :) : I would like to see Video (series) about building an example for a two-tier application completely written in Rust providing: A server part running in native ARM or X86 Linux A client part running on the Browser in WASM A GUI (supposedly DOM based) Connecting the two parts using RPC over WebSockets (is there a standard protocol ? ) Being able to "scale/manage" the project (i.e. decide which modules are to be compiled to which of the two "parts" by rather easy to do configuration. What do you think ?
Yeah I can do that. That's basically a Leptos site. Scaling websockets is probably its own topic, but picking/choosing what goes where (server/client) and otherwise managing the project would definitely be covered.
@@chrisbiscardi That sound very promising... :) The Leptos Video seems to get very near to what I suggest. But why do I need an additional different framework on the server. Other than the RPC mechanism, I would suggest that on the server just some business code runs (not GUI related) , and what needs not directly project related "framework" stuf is only at the browser site. OK, some basic HTML supposedly needs to be pushed to the browser with the WASM binary. but that should be all that needs to reside on the server.
I gave a talk on why at Rust Conf this year (I don't think the videos are up yet though). Strictly speaking you don't need leptos on the server if you're not going to do any modern web development work or hydrate any client state from the server. If you want to fetch some data and send html you can do that without leptos (and only use axum or whatnot), but it becomes increasingly problematic the more complicated the client gets and the more server-rendering you want to do. You end up with effectively two separate locations to maintain similar rendering code with differing behaviors. Leptos is a formalization of the approach you'd end up at to solve the problems inherent in that same-logic-separate-implementations architecture (as are many ui frameworks today), and includes a bunch of nice-to-haves towards that effort. It also supports a variety of approaches, including client-side only, server/client hydration, islands, etc so you don't have to re-work the implementation to switch between the options. If you're shipping statically rendered html then you really don't need a server at all, and if you're shipping html that is intended to be hydrated on the client it makes sense that you'd want to unify those rendering/data/etc paths in a single approach.
@@chrisbiscardi In fact I am doing embedded development. As I am going to do new developments on Rust, I am doing this research. My goal for new devices is do have them (i.e. a simple built-in web server) accessible via a Browser to allow for monitoring and configuration. These devices usually don't feature a full-blown OS such as Linux (some might, some don't). Hence all GUI related stuff should be done completely within the browser and RPC should be used to have the Browser ""App" talk with the embedded device (in a way sophisticated enough to allow for any devices that might be planned in the future). I know that in the past, Java Script frameworks were used for such projects. As I am converting to Rust, it's obvious that the code to run on the Browser should be generated by Rust programming, as well.
is there rust ecosystem for vst plugins to use with DAWs on macs or does has its own better DAW and ecosystem matching industry standards in music space
I haven't built any VST plugins myself, but if you go to lib.rs there's definitely bindings to vst APIs. There's also larger synthesizer type crates like hexodsp lib.rs/crates/hexodsp lib.rs/search?q=vst
Yes, but actually no. VST API is unfortunately so closely coupled to C++ that it's very unergonomic to use in Rust. Overall, Rust's audio ecosystem is one of its weakest.
I started to learn Rust as complementary language to Raku. Raku itself is mindblowing, very feature-rich out of the box. Like do you know other language that has built in grammars? But that comes with performance penalty. Rust fills this performance gap and it can be called from Raku, so those two make perfect combo. Whipuptitude and speed.
I guess it depends on what you mean by "effective go" or "proper rust". A program has to do what its supposed to before it can be effective, and I found myself spending a decent amount of time in Go-land trying to make sure I covered the cases I needed to, or used interfaces correctly. It felt like Go was easy to pick up but hard to become a true expert in, whereas I feel like Rust is a bit different. When I write Rust I'm confident my programs are working correctly, but that also means the compiler is checking my work (borrowing/ownership/mutability/etc) more than it was in Go. That has the benefit of meaning I can rely on the compiler/error messages/etc a lot more, but it also means more wrong programs won't compile. I think becoming an expert in any language is a lot of work, but not necessarily harder work for one language or another. The amount of work depends on what your past experience is.
Would you recommend Rust to someone learning programming for the first time? The possibility of writing both web and desktop applications as well as the possible speed gains made me interested in this language. Would becoming proficient at it mean I can grasp most programming concepts, or is Rust lacking in specific departments? I manly want to learn as a hobby and tool for myself, so time is not a problem. Thanks!
In my opinion, learning Rust would give you access to build the widest possible set of applications that a single general-purpose mainstream language can give you: everything from operating systems, to embedded software, to web applications, and games. Any first language tends to be the hardest to learn, but Rust is no different than others in that respect. It being your first language might even make it easier for you to learn Rust compared to someone who learned another language first because you won't have as many ideas about "this is how programming is supposed to work" from that other language. That said if you get into specific domains you will find a lot of domain-specific languages too. If you want to write web applications, Rust will help you write servers, APIs, and render web UI, but you'll still find uses for CSS for styling web applications and understanding HTML will help you write better and more usable web applications. Talking to databases can be done with a rust-only library, but understanding SQL will also help you write better database queries. If you want to write GPU-based programs Rust can set up all of the data and pipelines, but you will have to also learn a shader language like wgsl. Basically, Rust is a general purpose programming language and can be your default choice for a lot of things, but you will also run into domain-specific languages as well that are meant for more specific purposes.
You are my favourite Rust content creator, I'll be following the Rustlings series soon, thank you so much for putting this out there it's really inspiring.
I deployed the site (and APIs) on a combination of Fly.io and Netlify. Netlify hosts the static assets, and Fly.io hosts all of the running Rust code (API and website services). Fly has you specify your application as a docker image, but it runs in production as a Firecracker microvm and Fly.io does a conversion behind the scenes.
How does it feel in terms of productivity writing Rust vs let's say Javascript/Typescrip/Go (I know it depends on experience, familiarity, etc...but trying to get some reference point).
For me Rust is just as productive as any other language these days. The main comparison I'd make to the languages you mentioned is generally the Rust type system and compiler help me write better code and find issues earlier. The Rust type system and compiler are high-signal, reliable sources of information about my program and actually when teaching Rust I have to find ways to convince people who have lived in these other ecosystems to even read the errors because they've gotten so used to them not being reliable sources of information. This is in contrast to the information I get when writing JavaScript, where error messages can often be skipped or point in the wrong direction. When I wrote production TypeScript I felt like I was double checking the type system to make sure its doing what I thought it was doing. I don't dislike TypeScript, but the type system being built the way it is on top of JavaScript doesn't give me the same level of confidence as type systems that are built into languages from the beginning. I'm not saying Rust is better than these other languages, but I do feel more confident in my programs when I'm writing Rust.
@@chrisbiscardiTypeScript problem that you've mention is exactly what I had experienced a lot of times. TypeScript can give you a false confidence in broken code or push you back from other actually normal code. If the types you write has errors or not completely describe factual data structures in the code - you can't be confident in anything. At the end of the day you must never be confident in TypeScript even if your code is perfect... because you never might be confident that programmer of some package among dependencies had properly defined TypeScript interfaces. TypeScript was born for the purpose to deal with large JS codebase problems inside one corporation. It does its job well in that specific situation : - all code and types is yours - for every 3rd party dependency you has enough resources to completely check its code and types - checking the types/interfaces that you may rely on during automatic code checking, is a manual task. TypeScript paradox : to be confident in typechecker, you must check all the types against code manually beforehand. It's kind of writing tests: you write some type hints to test against it, but if you made mistakes in tests itself - be ready for the all kind of falsy test results.
I have a mostly low level experience which i was hoping rust would allow me to branch out to web development at some point. The official tutorial was to create a conways game of life with web assembly. But it used a graphics library in js to create the grid array. So then i got pretty confused about why i was using web assembly and rust in the first place and gave up that tutorial... I'll have to take a second look at it.
For what it's worth, I've seen a lot of people bounce off of that Conway's game of life wasm introduction. I think that tutorial should be much simpler and the next levels should be dependent on what a user wants to do, for example integrating bindgen with existing js libraries, doing some *useful* computation, or directly going to wgpu or leptos (or yew, etc).
I left some comments about zig in another reply when someone asked. tldr; I don't really have anything against zig, but it doesn't seem targeted at a problem I have so I don't really intend to use it at this time. ruclips.net/video/vL2nB1VwX1M/видео.html&lc=UgzSb-1nrAPkAWmQXbl4AaABAg.9tROJrnyJmP9tRRrnG3znN
im now fascinated in golang all i did was javascript and changing things a bit is really awesome. fiber is exactly like express and its really nice how db implementation and project structure is
The largest benefits for me relate to the maintainability of the codebase. When I come back to the project, it still works and I can rely heavily on the type system to make sure that I can refactor without breaking the site. The performance of the site is largely comparable to any major javascript-based site, which was enough for me to switch to gain the maintainability improvements. Part of the switch for me is also a bet on the future of the technology. Its "good enough" today IMO, but Leptos also has an "islands architecture" branch that would cut out the majority of the wasm payload for me too.
@@chrisbiscardi Very good to know. I was wondering about performance to estimate if the cost/overhead of switching is worth it. Seems unlikely to take off unless someone is already deep in the rust ecosystem. Thank you for your insight and the video
@@mrcjm yeah, I mean, without knowing anything about what you're using or the architecture, or what problems you need to solve, its pretty impossible it make any decisions or suggestions about whether to use anything. If you're wondering about performance, my best suggestion is to build something small but comparable to what you already work with and see what the differences are. The performance characteristics of wasm are different than javascript (for example, wasm can be compiled as it streams down from the server, whereas javascript generally has to be fully downloaded before compiling and running)
A huge plus of rust is reducing the long tail of problems, which can really help you move on to the next thing, and thus get through a long list without constantly going back to fix "oops, that was nil sometimes" kinds of problems.
While I want to believe that Rust's a great choice for front-end UI, your website doesn't leave me with that impression. There's a significant and noticeable delay when loading the pages where the background is grayed out, and overall the loading times are long. That may be latency/data-fetching more than Leptos, but I feel like you could've made a better product using Astro or htmx or even just a regular MPA.
The background loading is very specifically an image-loading delay, which isn't going to improve by using any framework. You can prove this to yourself if you disable JavaScript entirely on the homepage and reload the page. Not being able to tell the difference between a framework issue and an unrelated image issue *is* how most people are going to experience the site, but its not a reflection of Leptos and would be just as "slow" in Astro. Its a reflection on the time I had to develop the site and how important I thought it was to spend time on optimizing that over developing more workshops, or other features.
@@jaredkelnhofer it's fine, I don't have strong opinions. I do think that using something other than node.js for a js runtime requires some justification, but there are reasons for certain projects.
I think I understand all of the web components especially with Js, TS and GoLang, I just want to be good with RUST to understand lal that you have covered here and become a solid personnel who can offer this as contract work or build tools to sell them out as services.
Hey Chris. Great video as always! Do you use server functions to retrieve data for frontend or rather requesting api directly? Also does your api live on the same axum instance as leptos?
I use Server Functions on Rust Adventure to inject the cookie/session-related auth to access the API from the server-side of the Leptos app, and I use Server Functions in the admin app to directly call SQL to the database. The API runs as a separate service, which I feel is generally the right move if you're going to have an API.
@@chrisbiscardi thanks for reply. I'm considering to use rust on our new SaaS project with classic JS framework on frontend (with dedicated dev) communicating with API on axum. Thing is we also need some kind of service admin and there's nothing ready-to-use in rust. I wonder if using Leptos is a good idea here. Also using Leptos (+axum) with server side functions brings it's own set of urls, right?
leptos server functions do indeed set up their own URLs. You have some control over this, but I wouldn't depend on those URLs outside of using them for server functions themselves personally.
Hey Chris, great video! Was wondering, did you manually write your axum routes, or did you let leptos generate the routes? I guess I was kind of confused by how that works when looking at their documentation.
routes on the rust adventure site are mostly generated by leptos. There's the typical Router from leptos_router and then also the routes for server functions. There's an integration package for each server-side framework that includes a generation function that walks your leptos application tree: docs.rs/leptos_axum/0.4.8/leptos_axum/fn.generate_route_list.html There's an example of it in the axum starter: github.com/leptos-rs/start-axum/blob/f963c514fb2c9412ccd38e8f3025cd4dca833c0a/src/main.rs#L20
yeah, I didn't replace software like davinci resolve for the final editing process, but I use some Rust crates to process audio and remove silent portions of a recording, then spit out an xml file that I can import into davinci to finish the edit on. I also use Rust for generating subtitles and transcripts when necessary.
thanks a lot for sharing your experience, very helpful. Between I head over to your website immediately in the middle of video , seems like there is a bug, I didnt entered my anything and hit enter, it successfully subscribed me , with the message `subscribed` . Seems like empty check is not working or missing.
For me it's mostly the Symphonia crate alongside some metadata to pull timecode out, the writing out fcpxml to pull into davinci. I'll put a video on my list for it.
Haskell is awesome though, its crazy how it is just so much better than anything else. Its on a different level. Rust is second but not a close second.
I have. It was less developed when I was doing this work and I have a heavy web focus here so I used Leptos instead. Dioxus has been progressing rapidly though.
Nice presentation. Of course it's up to the individual whether or not to learn a new language or revert to our old favorites. For me, I'm keeping with C and Javascript.
Your video was really, good and i'm impressed with the work you made, as a mainly low level C/Cpp/ASM/Zig aficionados, I've always despised web, for the reason that most of the stack is typeless which I hate, because If you were to look at my code, everything is littered with assert() everywhere, but I've been tinkering about learning rust, to contribute to the text editor that I use, and seeing that this might also be a step in the door to also be able to do web stuff, rust start to be very compelling. Thanks for sharing your story.
Sorry but I had to start laughing so hard at around 8:00. Imagine someone who is not into computer science trying to decipher what you are saying. And crate rayon is just the cherry on top.
Always pushing out consistantly amazing videos, thanks for sharing your knowledge Chris! Just subscribed to rust adventure looking forward to diving into the workshops.
nice! I'm looking forward to 0.5. Between Server Functions not needing registration in the last version and passing scope around going away in the next version, I'm feeling good about how much progress is happening.
Yes rust is empowering. Why? It's horizontal to vertical. You can go low level to high level. And wide implementation from supercomputers to front-end web. :)
I'm learning Haskell as my first language, and I feel a bit sad about the fact that few people try it, I don't know how devastatingly impracticable it makes the language. I intend to learn Rust after; and also some mainstream languages for the sake of having to, but it's still hard to swallow the pill that I can't develop with the language I want, and the thought of the initial difficulty of Haskell being the reason a lot of people get repelled by it is disturbing, it could have been a pretty powerful language, but since the very beginning it was "too much of a hassle to deal with", instead they would prefer to follow the easier path, even if they could have avoided a lot of problems and learn important concepts.
Haskell is interesting as a language and I'm happy I learned it because it definitely affected my view of other languages. You can definitely do productive things and get paid to do so, but the pool of people paying for Haskell work is much smaller than other languages, so if "getting a job" was the task, I wouldn't suggest Haskell. IMO the initial difficulty is really more of a documentation/teaching material issue added to the fact that most people's first language isn't purely functional, so they have to "unlearn" things in addition to "learning" things.
I still think there is value in not having to know which particular number type you are using, or where exactly the lifetime and "ownership" start, change or end, or where exactly data is copied. All those are valid concerns - for latency-conscious or resource-conscious tasks. Not for things like the usual website apis and so on.
The new Rust/WASM powered Rust Adventure site is live now at www.rustadventure.dev/
and the discord server is now open if you want to learn Rust: discord.gg/2FwB9EqCGs
Please add Rust + HTMX
Trunk has a problem while running with ARM processors
Reason I found was related to wasm-binaryen which is used to make trunk
Binaryen package is not optimised for ARM processors which Is causing rust developers using ARM processors struggle to get there UI frameworks work
that's interesting, I run an m1 as my primary machine and I haven't had any issues. Looking at the issue tracker it seems like this was resolved back in 0.16
@@chrisbiscardi yeah It does work with Mac but struggles with other processors
Like Raspberry Pi 4 processor or the Pine64 processor
I don't generally get into frameworks who base their marketing on being "anti-" other approaches. They don't tend to last long term.
Great story about how Node was an entrypoint to many topics. I think it is sometimes overlooked that JS as language and Node.js as ecosystem have allowed a lot of pople to learn building systems and advance into more complex domains.
Yup
javascript as gateway drug... it really is the marijuana of programming languages
Rustjerks would disagree 😂. Even though I'm gradually moving solely into Rust, I would never 💩 on the Node ecosystem because it has enabled me to do sooo much. I moved to JS back in the day from much more powerful languages simply for the ease and access that Node provided me. Yes, there's good and bad in every ecosystem but if you're a good enough dev, you know exactly how to apply the filter.
@@m4heshd Building in TypeScript was fun for me. I lacked fun with PHP, Ruby, C#. I will never shit on NodeJS, but we can leave it behind going forward. I don't believe evething in Rust though
One part of that which makes it such a great gateway is that web dev is much easier to break into without getting a Comp Sci degree first.
I’ve been interested in learning Rust but I was under the impression it was mostly for low level embedded stuff. Seeing the flexibility and usability of Rust across a wide domain has been a much needed and I’m excited to give it a go!
I was under the same impression, but after looking deeper into it that's clearly not the case. It seems to be because it can be used to replace C++, people assume that's all it's for.
Just started reading The Rust Programming Language recently and I think I'm in love.
@@nojerome497 I’ll check this out !
It's a bit clunky to use for some things due to the restrictions that are set in place, using it for an API will end up with you needing to manually register all routes for example (haven't found a way to do it dynamically at the very least). That's not really the end of the world, but it is just one of those things that makes it a bit less appealing for such work. I absolutely do recommend trying it though. Even if you don't end up using it a lot, it can teach you a lot about how to think about code.
@@CottidaeSEA yeah a month in and I’m probably still going to use typescript/Go for api stuff.
I will say I’ve really loved rust for CLI stuff and tooling tho. Replaced some old Python tools at work with rust and the increase has been nuts. I just wish the standard library was more robust like Go.
Rust is not used on microcontrollers. We use Assembler, C and sometimes C++
Great work Chris! I love how you shared your entire journey and the decisions you ended up making for the new site! I’ve been an early adopter of Rust Adventure and I’m excited to see how it will continue to evolve over time! Seems like some great bets so far.
This is awesome.
There's much more inside the video than the title says (or, I imagined seeing the title).
Thanks a lot.
In recent days, I've started learning more about Rust. This clip really sells it. I think I'll jump on the bandwagon and take your RustAdventure course.
as an amateur haskeller, I must say what attracts me of Haskell is not its direct useability but how it forces you to think of the domain problem and break it into its fundamental rules and components (types). I'll keep writing Python and probably pick up Rust soon, but I'll keep using Haskell to prototype stuff just to remind myself of how a good design should look like.
Yeah I definitely think that's the biggest utility of Haskell these days: as a language that forces you to think about problems in a different way, that you can then use to apply to the way you use other languages.
It's the same for a bunch of languages I think. If you really want to understand the actor model, then erlang is a great environment to do that in, for example.
@@chrisbiscardi It feels so absurd to me that Rust is the only mainstream language that has adopted Algebraic Data Types and Type Classes from Haskell and similar languages. It's the obvious way to model data.
I also feel that Rust's ownership model can give many of the advantages of purity by forbidding mutable aliasing, which is one of the largest sources of bugs related to impurity. Because of the lack of mutable aliasing, a Rust function that takes a mutable reference `fn foo(x: &mut Bar)` is roughly equivalent to a pure function `fn foo(x: Bar) -> Bar`.
@@asdfghyterhow is it obvious? normal programming is obvious. ifs are obvious, classes are obvious, etc. but functional programming like pattern matching and monads are not obvious at all.
@@donkey7921 monads are clearly not obvious, but pattern matching is. classes are not in any way obvious, you’re just used to them.
and as rust has shown, tagged unions/ADTs/sum types and pattern matching are not in any way specific to functional programming
what i mean is that if you would informally talk about data, you would very often do it in terms equivalent to sum and product types. “you would get either this thing or that thing” = “sum type”. and you also often write a poor man’s sum types in a program without the safety guarantees, e.g. when a function returns a status code that tells you if the other returned value is valid, instead of a Result type. and let’s not forget null pointers, which are just the Option type in disguise (but without any way for the compiler to tell if you’ve checked it). and similar to null pointers we have returning special magical values for non-pointer types to signify failures (e.g. negative number = failure), which are also Result types.
sometimes a class hierarchy can make sense, but often it feels artificial and it would be much nicer to just say “this is one of these three things”
@@donkey7921 It's much easier than it sounds. Monads are a box with a value, it gives the value a set of rules to follow so you can compose or pass it around to functions. The rules allow you to treat the box the same way regardless of what the value inside it is. It makes your program simpler because the value in the box could be null or an error, your functions don't care, you only need to handle it when you check inside the box.
If you've used promises in javascript, you probably know enough to use it.
6 months latter: I spend six month rewriting everything in zig
😂
😂
😂😂
😅😂
😂😂😂
3:26 I tend to write a lot fewer tests in Rust than I did in other languages. Maybe it's the culture of my workplace but also if it compiles, it works. Tests run in CI and I forgot when was the last time I got an email alert with a failure.
This video was the type of ecosystem overview I needed to put rust into context of all the things I do with the JVM, js/ts and python. I try to learn a new language every year or so, and this year it’s rust. Unlike most of the other languages I’ve dabbled in, I’m starting to feel like rust might be a place I could live for a little while. I haven’t felt that way since I started really loving kotlin a few years ago.
just wanted to ask a quick question as a person of mostly backend which books have you read primarily to understand the concepts like these ??? are there any list of books? or it's just a few books which gives the impact?
I was hesitating to pick a programming to adopt a programming language as I am trying to get back to software development and I was stuck and indecisive about Rust, that video help me make up my mind, I will be taking the rest of the year to embrace Rust fully. Thank you
Well, I just started going into Rust with no idea what I am doing. You did give me a whole lot of things of what I can do with it. I come from react, java, node side, apart from rust being a low-level programming, this video sure widened the scope for me, thanks :)
Your bio is so similar to mine :) I started with AS too, but skipped nodejs because I always hated JS. Erlang and clojure are in my collection too, but I did Elm instead of Haskell, and really lerned a lot from it. Now I'm learning Rust (ecosystem mostly), and I hope I won't need to learn another language in near 5+ years, because I want to become a pro in Rust. While I'm learning, I hope wasm Rust tooling for usual HTML/CSS stuff become more mature, though I don't like the idea of keeping logic/state on frontend, some glue is needed anyway.
I waited so long to be able to avoid JS on frontend completely, and last few years I noticed this is possible, and I finally can do frontend tasks and sleep well after deploy :)
Tbh i would be really interested learning about what open source crates we can use as Rust devs creating web UI, since i feel one of Rust's big strengths is how plentiful, reliable and modern its packaging system is.
I personally am learning Yew (Similar to React) to rewrite my app, using Cargo Features to either run on the web using REST APIs or run locally using Tauri depending on build. However, I haven't seen much of whats available in terms of elements, design aids and other utilities.
I've found Rust a very exciting, refreshing and comfortable language to write in, coming from a C# background. It feels like everything I wanted from C# without much compromise, and even some things i didnt know i wanted!
I'm right on the verge of diving into the Elixir garden, and learning the tools to work with Phoenix LiveView. Basically because it ticks every box when it comes to some of the projects I'm involved in. I'm really hoping that one of these WASM Rust crates will come along and do the same soon - ideally, this week 😆 Thanks, interesting video.
I am only two minutes in and I am really appreciative of the journey you've shared thus far and I am excited for the rest of the video. I've been very interested in learning Rust and have found a few folks who seem like solid folks that I've followed on Twitter for a bit and it seems to me like it's at a point where maybe Node was in its formative years?
I am curious your thoughts on where Rust is heading and your sense of how it compares to the Node Community formation! I look forward to hearing back!
@chrisbiscardi I am curious if in the future you'd be open to discussing the migration away from GraphQL and instead moving to axum+tokio with MySQL. I work in the GraphQL space and I am very much interested in understanding where it serves and where it doesn't. 🙏
I'd generally agree with that assessment. I think there's actually *literally* people coming over from JavaScript to Rust, as well as it feeling very formative in a similar way right now. There's a lot of crates that already exist, but also the opportunity to write "The X crate".
It also seems to be a further expanding of the types of software people can write beyond the expansion that nodejs offered around the time it came out. For example, writing kernel extensions in JavaScript isn't really going to happen, and embedded development has certain restrictions, but Rust supports these sorts of environments well.
The migration away from GraphQL was a migration away from AWS AppSync (and mostly Amplify specifically). GraphQL-the-concept is something I think is still very viable. At the time I wasn't sure if I could find a Relay-level client for Rust and even if I could, if that would work well with where Leptos was going. I knew REST was going to work even if it meant I made more endpoints for different use cases and such.
I don't know that I'd advocate for building GraphQL servers yourself? but Hasura is really nice if you don't want to and I think I'll get into writing GraphQL servers in Rust at some point, which will predictably turn into RUclips videos when I do.
I've been using GraphQL since it came out in a whole bunch of scenarios and I still like it, but I definitely wanted to distance myself from Amplify.
@@chrisbiscardi Thank you for the reply! I want to take a few moments to process what you've shared and I'd love to follow up. I'd love to continue short exchanges of thoughts like this in the future if you're open to it, definitely async to allow followup when time, bandwidth, want allow. I connected with you on BlueSky 🙏
I think its not just javascript that rust is competing against. Its the frameworks. I think vanilla js vs a decent frameworks is no competition. These frameworks are explosive in productivity and easy to work with in a team. I think rust has real potential in the low level hardware community. But I mean, python was the hot thing 5 years ago and people said the same thing you're saying here. Even the node js package manager is hard to ditch as its incredibly convenient. Personally I'd prefer to see more Rust examples of it replacing audio tools but thats just me.
In Rust WASM builds and JavaScript apps, one can easily fall into the trap of “including a large library for a single function and your final bundle size includes the entire library rather than the only functions you use”. Are Rust/WASM bundle sizes easier to optimize than Webpack JS bundle sizes?
This specifically is a harder trap to fall into because dead code elimination is built into the way Rust compiles, especially compared to JavaScript where dead code elimination is often treated as a special process or is actually not possible, as was the case with a lot of commonjs code that used a more dynamic require style compared to esm.
on the more general question of whether its easier to, I'd say yes but obviously this is dependent on the person doing the optimization, their own experience, and specific goals. wasm doesn't currently "code-split" for example.
I say yes specifically due to the fact that when you make such changes in Rust they tend to persist rather than be accidentally reversed, and Rust has the ability to work in highly restricted environments like embedded and no_std. This means there are both very general automatic tools, like dead code elimination or upping an optimization flag, as well as concrete steps you can take to move closer to a no_std style program. Here's a decent overview of techniques: rustwasm.github.io/docs/book/reference/code-size.html
really a great informative video chris, really wanted to get into rust. keep it up
after building in rust did you feel that the website was more resilient? do you have any data on if it crashed / errored less? (no disrespect just curious)
Over time I've noticed that issues with data are basically gone. I never have to worry about a field existing or not existing, which I often had to double check in the live site when using JavaScript. Leptos is also getting better and better. The 0.7 release is really exciting and I've been working with the Islands features more and more which reduces the payload to the browser and such.
The servers have been incredibly stable. They don't randomly go down at all and any issues in the application logic are pretty easily traceable to an .unwrap() or similar. They also use very little resourcing.
I'm at a conf right so so don't have any numbers, but I also changed the architecture on a few sites from being static to running a Rust server and it's been just as low effort operationally.
0:11 What's the tool he used to keep track of those collections etc?
Your website loads very fast and is well designed, great job.
I'm re-writing everything in css
Would love to see a video exploring rust for data science and data engineering. Things like Surreal and Fluvio are especially interesting 💜
I'm working on a video about stream processing to give some background using arroyo to contextualize it. What do you find interesting about Surreal and Fluvio?
Surreal is multimodal and supposedly fast. Saw some demos where they smoked financial data. It's easier to manage database and API schema. They just closed a phat funding round
Then fluvio has crushed as a Kafka replacement in the cloud, helping save a node operator 10x on their data fees. This huge saving was a result of the increased memory efficiency of Fluvio
They're both written in Rust 💜🦀
Your website is extremely performant. Looks great!
Amazing video! 15 minutes passed by easily. One thing I'd like to mention is the possibility that the Rust ecosystem might possibly go down the same track as npm; and the reason being the lack of a strong STD like .NET. We're already seeing rust packages that have 400s of dependencies for small-sized projects, let alone bigger ones. With it comes the risk of exactly what made you leave JS, which I do hope I am wrong about (and willing to get corrected if so).
glad you enjoyed it!
The Rust crates I see that have that kind of dependency graph are the ones that typically make good use of them, like Bevy for example, so while I can see the concern (especially if you're familiar with the JS ecosystem) I do think its less of an issue with such a well-typed language compared to JS.
I have two thoughts really:
1) we never really know how an ecosystem will evolve over time. It may turn out that Rust develops some of the same problems for whatever reason. I'm pretty happy with the ratio of "stdlib" to "3rd party" right now. Things in the stdlib are generally super stable and reliable, which I really like. I'd rather not end up in the situation where the stdlib is somehow "out of date" and no longer the recommended approach like has happened in other languages.
2) there will be another language after Rust. Rust is not the "ultimate language" (or however you'd phrase that) and language design research has kept going regardless of what the industry is using. Rust is great and I feel that it will be around for a long time, but it won't be the last language I ever learn.
Also I don't consider myself having "left JS". I do prefer Rust these days, but JS is still a language that I keep up to date in my toolbelt.
I'm literally doing this right at this moment 😆. I know RIIR has become a meme, but things are just infinitely better when written in Rust. But the biggest thing for me was, rewriting my own code in Rust has improved my knowledge in Rust exponentially.
I also feel that a major benefit of Rust is actually _not_ having to rewrite everything in Rust, and instead binding rust within an existing application, basically the exact opposite of the meme.
@@BosonCollider Agreed but not possible in every case.
Poem is really the only one I'd use for APIs because of the automatic documentation and playground. Doing playgrounds in Axum was painful.
This has to be one of the best videos on why one should give Rust a try!
Cheers from another actionscripter.
Great effort Chris! Excited to get into Rust Adventure!
I just did a research regarding doing a GUI in Rust.
I found that this still is rather bleeding edge, while many other other aspects in the rust universe seem much more advanced.
In fact I would like to see a single well supported tool that can be used for both local UI (Desktop and portable) and for WEB UI.
I do see that it does not make much sense to only provide a "one fits all" workflow that results in a program source code runnable everywhere. But for very simple (ugly) GUIs, this should in fact be possible.
For more complex applications the tool should provide a decent workflow for each OS / widget library (including DOM).
Optionally a WYSIWIG Gui Builder should be provided.
On top of that, a well defined internal (e.g. Websock based) API should allow for easy and flexible separation of server based and client based parts of the user application (both of course done in pure Rust code.)
Is something like this only possible in a payed product or will the community be able to provide something like this (in contrast to the many smart but bleeding edge projects currently in the works) ?
Im learning a lot from you Chris, thank you for sharing these.🙂
Haskell has one of the best communities I know. But yes, it has improved a lot in recent years.
if your codebase initialy come from JS/TS, try to move to bun first, i just do it for my React Native Codebase, and run faster for install dependency/update or etc
The best video about Rust I’ve seen so far
What's that software at 0:11 ?
Some software I wrote to help me manage workshops
@@chrisbiscardi What stack did you use and is it open source or source available?
Stack is Leptos/Rust/MySQL/sqlx/axum. Source for the app is not available but I'm working on some Leptos workshops that will go up on rustadventure.dev
This sort of function chaining imo is the most repelling thing in Rust.
Shared journeys are always a great trip! thx!
Many thanks or the very instructive video
As you asked for such :) :
I would like to see Video (series) about building an example for a two-tier application completely written in Rust providing:
A server part running in native ARM or X86 Linux
A client part running on the Browser in WASM
A GUI (supposedly DOM based)
Connecting the two parts using RPC over WebSockets (is there a standard protocol ? )
Being able to "scale/manage" the project (i.e. decide which modules are to be compiled to which of the two "parts" by rather easy to do configuration.
What do you think ?
Yeah I can do that. That's basically a Leptos site. Scaling websockets is probably its own topic, but picking/choosing what goes where (server/client) and otherwise managing the project would definitely be covered.
@@chrisbiscardi That sound very promising... :)
The Leptos Video seems to get very near to what I suggest. But why do I need an additional different framework on the server. Other than the RPC mechanism, I would suggest that on the server just some business code runs (not GUI related) , and what needs not directly project related "framework" stuf is only at the browser site.
OK, some basic HTML supposedly needs to be pushed to the browser with the WASM binary. but that should be all that needs to reside on the server.
I gave a talk on why at Rust Conf this year (I don't think the videos are up yet though). Strictly speaking you don't need leptos on the server if you're not going to do any modern web development work or hydrate any client state from the server. If you want to fetch some data and send html you can do that without leptos (and only use axum or whatnot), but it becomes increasingly problematic the more complicated the client gets and the more server-rendering you want to do. You end up with effectively two separate locations to maintain similar rendering code with differing behaviors.
Leptos is a formalization of the approach you'd end up at to solve the problems inherent in that same-logic-separate-implementations architecture (as are many ui frameworks today), and includes a bunch of nice-to-haves towards that effort. It also supports a variety of approaches, including client-side only, server/client hydration, islands, etc so you don't have to re-work the implementation to switch between the options.
If you're shipping statically rendered html then you really don't need a server at all, and if you're shipping html that is intended to be hydrated on the client it makes sense that you'd want to unify those rendering/data/etc paths in a single approach.
@@chrisbiscardi In fact I am doing embedded development. As I am going to do new developments on Rust, I am doing this research.
My goal for new devices is do have them (i.e. a simple built-in web server) accessible via a Browser to allow for monitoring and configuration.
These devices usually don't feature a full-blown OS such as Linux (some might, some don't). Hence all GUI related stuff should be done completely within the browser and RPC should be used to have the Browser ""App" talk with the embedded device (in a way sophisticated enough to allow for any devices that might be planned in the future).
I know that in the past, Java Script frameworks were used for such projects.
As I am converting to Rust, it's obvious that the code to run on the Browser should be generated by Rust programming, as well.
yo, what's the reason to replace javascript CLIENTSIDE?
is there rust ecosystem for vst plugins to use with DAWs on macs or does has its own better DAW and ecosystem matching industry standards in music space
I haven't built any VST plugins myself, but if you go to lib.rs there's definitely bindings to vst APIs. There's also larger synthesizer type crates like hexodsp lib.rs/crates/hexodsp
lib.rs/search?q=vst
Yes, but actually no. VST API is unfortunately so closely coupled to C++ that it's very unergonomic to use in Rust. Overall, Rust's audio ecosystem is one of its weakest.
I started to learn Rust as complementary language to Raku. Raku itself is mindblowing, very feature-rich out of the box. Like do you know other language that has built in grammars? But that comes with performance penalty. Rust fills this performance gap and it can be called from Raku, so those two make perfect combo. Whipuptitude and speed.
What would you say was harder, learning to write *effective* Go or learning to write proper Rust?
I guess it depends on what you mean by "effective go" or "proper rust". A program has to do what its supposed to before it can be effective, and I found myself spending a decent amount of time in Go-land trying to make sure I covered the cases I needed to, or used interfaces correctly. It felt like Go was easy to pick up but hard to become a true expert in, whereas I feel like Rust is a bit different.
When I write Rust I'm confident my programs are working correctly, but that also means the compiler is checking my work (borrowing/ownership/mutability/etc) more than it was in Go. That has the benefit of meaning I can rely on the compiler/error messages/etc a lot more, but it also means more wrong programs won't compile.
I think becoming an expert in any language is a lot of work, but not necessarily harder work for one language or another. The amount of work depends on what your past experience is.
really cool subject; I'd love to see more videos like this
Would you recommend Rust to someone learning programming for the first time? The possibility of writing both web and desktop applications as well as the possible speed gains made me interested in this language. Would becoming proficient at it mean I can grasp most programming concepts, or is Rust lacking in specific departments?
I manly want to learn as a hobby and tool for myself, so time is not a problem. Thanks!
In my opinion, learning Rust would give you access to build the widest possible set of applications that a single general-purpose mainstream language can give you: everything from operating systems, to embedded software, to web applications, and games. Any first language tends to be the hardest to learn, but Rust is no different than others in that respect. It being your first language might even make it easier for you to learn Rust compared to someone who learned another language first because you won't have as many ideas about "this is how programming is supposed to work" from that other language.
That said if you get into specific domains you will find a lot of domain-specific languages too. If you want to write web applications, Rust will help you write servers, APIs, and render web UI, but you'll still find uses for CSS for styling web applications and understanding HTML will help you write better and more usable web applications. Talking to databases can be done with a rust-only library, but understanding SQL will also help you write better database queries. If you want to write GPU-based programs Rust can set up all of the data and pipelines, but you will have to also learn a shader language like wgsl.
Basically, Rust is a general purpose programming language and can be your default choice for a lot of things, but you will also run into domain-specific languages as well that are meant for more specific purposes.
@@chrisbiscardi thanks for the thorough response!
You are my favourite Rust content creator, I'll be following the Rustlings series soon, thank you so much for putting this out there it's really inspiring.
1:21 psychological safety 😂 Soo trueee
It wasn't clear to me what your final hosting environment ended up being. Did you use a docker image? And where did you host the container if so?
I deployed the site (and APIs) on a combination of Fly.io and Netlify. Netlify hosts the static assets, and Fly.io hosts all of the running Rust code (API and website services).
Fly has you specify your application as a docker image, but it runs in production as a Firecracker microvm and Fly.io does a conversion behind the scenes.
What's the name of the vscode theme?
night owl
thanks!@@chrisbiscardi
have you looked into nix os ? i was thinking of, otherwise it's a comprehensive story, thanks for sharing!
Enough that I know of it and what it does, but I don't really run linux on desktop so I haven't spent much time with nixos
Great overview of the Rust web ecosystem, thanks!
What do you use for auth in rust?
I'm using aws cognito on this project. I try to not write core auth services in-house.
Amazing content Chris!! Loving it :)
How does it feel in terms of productivity writing Rust vs let's say Javascript/Typescrip/Go (I know it depends on experience, familiarity, etc...but trying to get some reference point).
For me Rust is just as productive as any other language these days. The main comparison I'd make to the languages you mentioned is generally the Rust type system and compiler help me write better code and find issues earlier. The Rust type system and compiler are high-signal, reliable sources of information about my program and actually when teaching Rust I have to find ways to convince people who have lived in these other ecosystems to even read the errors because they've gotten so used to them not being reliable sources of information.
This is in contrast to the information I get when writing JavaScript, where error messages can often be skipped or point in the wrong direction. When I wrote production TypeScript I felt like I was double checking the type system to make sure its doing what I thought it was doing. I don't dislike TypeScript, but the type system being built the way it is on top of JavaScript doesn't give me the same level of confidence as type systems that are built into languages from the beginning.
I'm not saying Rust is better than these other languages, but I do feel more confident in my programs when I'm writing Rust.
@@chrisbiscardiTypeScript problem that you've mention is exactly what I had experienced a lot of times. TypeScript can give you a false confidence in broken code or push you back from other actually normal code. If the types you write has errors or not completely describe factual data structures in the code - you can't be confident in anything. At the end of the day you must never be confident in TypeScript even if your code is perfect... because you never might be confident that programmer of some package among dependencies had properly defined TypeScript interfaces.
TypeScript was born for the purpose to deal with large JS codebase problems inside one corporation. It does its job well in that specific situation :
- all code and types is yours
- for every 3rd party dependency you has enough resources to completely check its code and types
- checking the types/interfaces that you may rely on during automatic code checking, is a manual task.
TypeScript paradox : to be confident in typechecker, you must check all the types against code manually beforehand. It's kind of writing tests: you write some type hints to test against it, but if you made mistakes in tests itself - be ready for the all kind of falsy test results.
How did you learn rust? I want to learn it as a beginner 🙏🏽
Still got questions? I can maybe help
The quality of your videos are just stellar.
I have a mostly low level experience which i was hoping rust would allow me to branch out to web development at some point. The official tutorial was to create a conways game of life with web assembly. But it used a graphics library in js to create the grid array.
So then i got pretty confused about why i was using web assembly and rust in the first place and gave up that tutorial... I'll have to take a second look at it.
For what it's worth, I've seen a lot of people bounce off of that Conway's game of life wasm introduction. I think that tutorial should be much simpler and the next levels should be dependent on what a user wants to do, for example integrating bindgen with existing js libraries, doing some *useful* computation, or directly going to wgpu or leptos (or yew, etc).
Have you tried Zig? If so, how you can compared it with Rust.
I left some comments about zig in another reply when someone asked. tldr; I don't really have anything against zig, but it doesn't seem targeted at a problem I have so I don't really intend to use it at this time.
ruclips.net/video/vL2nB1VwX1M/видео.html&lc=UgzSb-1nrAPkAWmQXbl4AaABAg.9tROJrnyJmP9tRRrnG3znN
im now fascinated in golang
all i did was javascript and changing things a bit is really awesome.
fiber is exactly like express and its really nice how db implementation and project structure is
Did you see any benefits in switching to rust? Like performance and loading times?
The largest benefits for me relate to the maintainability of the codebase. When I come back to the project, it still works and I can rely heavily on the type system to make sure that I can refactor without breaking the site.
The performance of the site is largely comparable to any major javascript-based site, which was enough for me to switch to gain the maintainability improvements.
Part of the switch for me is also a bet on the future of the technology. Its "good enough" today IMO, but Leptos also has an "islands architecture" branch that would cut out the majority of the wasm payload for me too.
@@chrisbiscardi Very good to know. I was wondering about performance to estimate if the cost/overhead of switching is worth it. Seems unlikely to take off unless someone is already deep in the rust ecosystem. Thank you for your insight and the video
@@mrcjm yeah, I mean, without knowing anything about what you're using or the architecture, or what problems you need to solve, its pretty impossible it make any decisions or suggestions about whether to use anything.
If you're wondering about performance, my best suggestion is to build something small but comparable to what you already work with and see what the differences are. The performance characteristics of wasm are different than javascript (for example, wasm can be compiled as it streams down from the server, whereas javascript generally has to be fully downloaded before compiling and running)
I see rust i click 😊
I enjoyed watching and listening to this video, mate.
Thank you for sharing all that experience! In was interesting, indeed!
Real talk .. how was all this re-written in Rust in 6 months?? That's crazy fast. I'm not sure I could do all of this work in Python that quickly.
A huge plus of rust is reducing the long tail of problems, which can really help you move on to the next thing, and thus get through a long list without constantly going back to fix "oops, that was nil sometimes" kinds of problems.
While I want to believe that Rust's a great choice for front-end UI, your website doesn't leave me with that impression. There's a significant and noticeable delay when loading the pages where the background is grayed out, and overall the loading times are long. That may be latency/data-fetching more than Leptos, but I feel like you could've made a better product using Astro or htmx or even just a regular MPA.
The background loading is very specifically an image-loading delay, which isn't going to improve by using any framework. You can prove this to yourself if you disable JavaScript entirely on the homepage and reload the page. Not being able to tell the difference between a framework issue and an unrelated image issue *is* how most people are going to experience the site, but its not a reflection of Leptos and would be just as "slow" in Astro. Its a reflection on the time I had to develop the site and how important I thought it was to spend time on optimizing that over developing more workshops, or other features.
@@chrisbiscardi That's a good point. However, if you had made a static site, you could've deployed it to a CDN, solving the issue of latency.
@@verified_tinker1818 The image assets are on a cdn
What do you think about Deno?
@@jaredkelnhofer it's fine, I don't have strong opinions. I do think that using something other than node.js for a js runtime requires some justification, but there are reasons for certain projects.
I think I understand all of the web components especially with Js, TS and GoLang, I just want to be good with RUST to understand lal that you have covered here and become a solid personnel who can offer this as contract work or build tools to sell them out as services.
what's the link of the website shown at 4:03 ?
lib.rs
@@chrisbiscardi thank you ♥
Hey Chris. Great video as always! Do you use server functions to retrieve data for frontend or rather requesting api directly?
Also does your api live on the same axum instance as leptos?
I use Server Functions on Rust Adventure to inject the cookie/session-related auth to access the API from the server-side of the Leptos app, and I use Server Functions in the admin app to directly call SQL to the database.
The API runs as a separate service, which I feel is generally the right move if you're going to have an API.
@@chrisbiscardi thanks for reply. I'm considering to use rust on our new SaaS project with classic JS framework on frontend (with dedicated dev) communicating with API on axum.
Thing is we also need some kind of service admin and there's nothing ready-to-use in rust. I wonder if using Leptos is a good idea here.
Also using Leptos (+axum) with server side functions brings it's own set of urls, right?
leptos server functions do indeed set up their own URLs. You have some control over this, but I wouldn't depend on those URLs outside of using them for server functions themselves personally.
Hey Chris, great video! Was wondering, did you manually write your axum routes, or did you let leptos generate the routes? I guess I was kind of confused by how that works when looking at their documentation.
routes on the rust adventure site are mostly generated by leptos. There's the typical Router from leptos_router and then also the routes for server functions. There's an integration package for each server-side framework that includes a generation function that walks your leptos application tree: docs.rs/leptos_axum/0.4.8/leptos_axum/fn.generate_route_list.html
There's an example of it in the axum starter: github.com/leptos-rs/start-axum/blob/f963c514fb2c9412ccd38e8f3025cd4dca833c0a/src/main.rs#L20
Thanks for the clarification!@@chrisbiscardi
This video sums up how I also fell in love with Rust
This video was very interesting to me especially due to the fact that you used rust to recreate your website
you mention at the beginning of the video that you're editing your videos in written-in-rust software? can you elaborate on that?
yeah, I didn't replace software like davinci resolve for the final editing process, but I use some Rust crates to process audio and remove silent portions of a recording, then spit out an xml file that I can import into davinci to finish the edit on. I also use Rust for generating subtitles and transcripts when necessary.
thanks a lot for sharing your experience, very helpful. Between I head over to your website immediately in the middle of video , seems like there is a bug, I didnt entered my anything and hit enter, it successfully subscribed me , with the message `subscribed` . Seems like empty check is not working or missing.
Ah yeah, I missed a required tag on the form! Thanks, taking care of that right now
12 factor CRUD App please?
inclusivity is one of my favorite parts of the Rust community as well :D
most Rust devs I've met are very nice as well
What is the website at min 4:04 ??
lib.rs/
@@chrisbiscardi thank you!
I love the idea of Psychological Safety in regards to programming language choice.
Interested to hear more about Rust for audio processing :)
For me it's mostly the Symphonia crate alongside some metadata to pull timecode out, the writing out fcpxml to pull into davinci. I'll put a video on my list for it.
Haskell is awesome though, its crazy how it is just so much better than anything else. Its on a different level. Rust is second but not a close second.
Nearly same exp but I'm did everything (including KV, DB) on cloudflare worker which I can POC in typescript and then RIIR in Rust later.
Brilliant overview, but damn it, I still need to use C for embedded (partially because SDCC is not SDRC) ...jeez!
Have you checked out Dioxus? Only half way through your vid, so maybe you mention it
I have. It was less developed when I was doing this work and I have a heavy web focus here so I used Leptos instead. Dioxus has been progressing rapidly though.
What site is he showing at 4:08 ?
lib.rs
Nice presentation. Of course it's up to the individual whether or not to learn a new language or revert to our old favorites.
For me, I'm keeping with C and Javascript.
Your video was really, good and i'm impressed with the work you made, as a mainly low level C/Cpp/ASM/Zig aficionados, I've always despised web, for the reason that most of the stack is typeless which I hate, because If you were to look at my code, everything is littered with assert() everywhere, but I've been tinkering about learning rust, to contribute to the text editor that I use, and seeing that this might also be a step in the door to also be able to do web stuff, rust start to be very compelling. Thanks for sharing your story.
Sorry but I had to start laughing so hard at around 8:00. Imagine someone who is not into computer science trying to decipher what you are saying. And crate rayon is just the cherry on top.
0:09 IDE?
Man, your videos are gem.
Bro, how do you have time to do all this?
producing videos? I worked up to it for years before being able to make videos at the pace I can today.
@@chrisbiscardiin conjunction with all the work you do for the content of your videos. In this case, rewriting all your tools.
Always pushing out consistantly amazing videos, thanks for sharing your knowledge Chris! Just subscribed to rust adventure looking forward to diving into the workshops.
Nice video. I've been friggin loving leptos lately, it's been great for building my personal site!
nice! I'm looking forward to 0.5. Between Server Functions not needing registration in the last version and passing scope around going away in the next version, I'm feeling good about how much progress is happening.
Rust made me love C# even more
Yes rust is empowering. Why? It's horizontal to vertical. You can go low level to high level. And wide implementation from supercomputers to front-end web. :)
nice video, though when going on your new website, it's quite slow, pages load slow ect
I'm learning Haskell as my first language, and I feel a bit sad about the fact that few people try it, I don't know how devastatingly impracticable it makes the language.
I intend to learn Rust after; and also some mainstream languages for the sake of having to, but it's still hard to swallow the pill that I can't develop with the language I want, and the thought of the initial difficulty of Haskell being the reason a lot of people get repelled by it is disturbing, it could have been a pretty powerful language, but since the very beginning it was "too much of a hassle to deal with", instead they would prefer to follow the easier path, even if they could have avoided a lot of problems and learn important concepts.
Haskell is interesting as a language and I'm happy I learned it because it definitely affected my view of other languages. You can definitely do productive things and get paid to do so, but the pool of people paying for Haskell work is much smaller than other languages, so if "getting a job" was the task, I wouldn't suggest Haskell.
IMO the initial difficulty is really more of a documentation/teaching material issue added to the fact that most people's first language isn't purely functional, so they have to "unlearn" things in addition to "learning" things.
Amazing video, thanks a lot Chris!
I still think there is value in not having to know which particular number type you are using, or where exactly the lifetime and "ownership" start, change or end, or where exactly data is copied. All those are valid concerns - for latency-conscious or resource-conscious tasks. Not for things like the usual website apis and so on.
Lol, my first language was ActionScript as a hobby when I was 14. Now I do JS/TS professionally, I wish I had time to change to Rust though.
Same here . I'm done with node package managers