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.

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

@@CottidaeSEA Have you tried using macros? They can reallyt abstract these boilerplates

😂

😂

😂😂

😅😂

😂😂😂

@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 UKposts 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'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 💜🦀

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.

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

The Rust Adventure site (which is about 4500 loc, with two projects, one for server and one for client, which has to compile about 550 crates) does a full hot-reload from html edit to seeing it on a webpage in about 8 seconds. This involves doing the incremental build for both the server and the client, so I'd assume if you were only doing a client site the time would drop by half easily. I haven't done any dependency optimization such as feature selection, etc. so this could probably easily be faster from that. The axum leptos starter, which is doing a similar thing, only takes 3 seconds from edit to seeing it in the browser. Other frameworks also have hot-reload (like Dioxus) but I haven't measured them.

​@@chrisbiscardi Wow! that's absolutely amazing !! thanks a lot 🔥

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.

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

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.

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

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.

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.

nothing wrong with picking a language you like and using it, zig or otherwise.

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

Ah yeah, I missed a required tag on the form! Thanks, taking care of that right now

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.

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.

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.

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.

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!

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.

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'm using aws cognito on this project. I try to not write core auth services in-house.

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. ukposts.info/have/v-deo/rnxjonhoja2JkoE.html&lc=UgzSb-1nrAPkAWmQXbl4AaABAg.9tROJrnyJmP9tRRrnG3znN

Maybe. Accessibility in a canvas app is significantly harder than using a dom

oh I know. it's pure pain. I guess we should stop describing the problem through before this turns into a top masochistic git repo of all time.@@chrisbiscardi

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.

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)