As mentioned in the video, I'm currently working my way through a Quantum Computing course on Brilliant. Highly recommend the course and Brilliant in general. They have courses on programming, LLMs, and other domains as well. 👉 To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/CodetotheMoon/ You’ll also get 20% off an annual premium subscription.
i was confused about what this is at first but then when the code came on the screen i knew what's happening. i have used **Jinja2 for Python** to write html templates and then autogenerate them into static websites, and i can immediately recognize that is the same design pattern but now in rust, that's awesome
Thanks for this video! Really well done, you managed to capture the essence of what we're trying to do with Loco. Appreciate the coverage of the back story because that's been an important driver of the features and maturity of the framework. Thanks! 🚂♥
Yeah I agree. We can even see in the comparison shots that a method in Ruby was 3 lines, where the Rust idiosyncrasies made the method 10 lines long. It’s a worthwhile trade off for security and performance, but it absurdly thrashes the « Ruby is made for developers comfort » mantra, which is extended to Rails
This is surreal seeing how I started programming (Ruby, vaguely in 2013-2025, using RPG Maker, never rails….then seriously again in 2021-2022 with Rails.) getting to witness two paths merge together. Rust is really unstoppable. I was already kind of sold with Bevy, although I havent built anything big yet. Anyway, back to the video.
6:29 I'd argue it's the other way around. Smaller companies usually don't have a lot of traffic (yet). So having sub optimal hardware/software is less of a concern. Combine that with the overhead of complexity a language like Rust can bring in projects that are still changing a lot and it makes it even less of an argument for doing this imo.
Here's the twist. Because of Rust, this does not feel bloated, and there's no "bloatness". (1) Rust as a language has a very low to no LOC overhead (as you add more lines of code, you don't "pay" in runtime like in dynamic languages and (2) Rust has zero cost abstractions, which makes all the stuff that *feel* bloated like traits, wrappers, and so on - zero cost (3) You can compile away features or chunks of Loco you don't like, which is again a feature of Rust. So all in all, there is no need for a Sinatra, other than people having a different *taste* (which is not something that's scientific, just a matter of.. taste)
I’ve been working through a Zero2Prod and the stack is Actix-Web with SQLX and Postgres. While hilariously overkill for the actual project, scales well
I find it hilarious how he tried to build ruby in node and updates always broke his project. I feel that’s the big problem with react is that nothing is stable and your build always breaks as they just have breaking changes all the time and because everything runs client side you have to keep up to maintain the security updates and there is just this constant maintenance cost with JavaScript. To me that is the appeal of rust as a compiled language it will have way less breaking changes and way more stability
Not only that, but the tools broke too. And then, you have this peer pressure -- should you stay with Wepback although everything moves on to Vite? (and then to the next tool in the future?). Every such migration is a "break the world" event. It made me unhappy, unwanting to open the project. With Loco, every feature request -- I get this excitement, and can't wait to dive in and implement. I know Rust and the tools will always be stable, and that things I left there will stay the same.
@@julienv7031 No, Elixir and the BEAM (the VM it runs on) are fast - at least compared to Ruby - and keeps on getting faster, but they're clearly not as fast as Rust can be. There are many reason for that: running on a VM instead of being native, immutability, fair scheduling, ... But usually that's not the point. Being fast is nice but being fault-tolerant is generally what you want, at least most of the time. And in this area the BEAM is unbeaten. It offers tools like actors, supervision tree, fair scheduling, ... so your operations keep on running under unusual circumstances. Instead of crashing directly, it smoothly runs in degraded mode, but still trying to recover. If you really want speed you can optimize the parts of code that are slow and code them in another language: C, C++, Rust or Zig are the most used ones.
I've been programming since before the web, and when Rails emerged its community felt to me like a specific type of cult. Once Rust gained a following, it community felt to me like the same type of cult as if it was the Ruby cult reincarnated. Now that Rails had made it to Rust I think my gut feelings about the two communities have been validated. 😳
@@aarona3144 - Over the years, many languages. Over the past 15 years, 10 was PHP, JavaScript, and SQL - PHP & JS not by preference but that is where I could find paying clients.- and for the past 5 years I have been working in Go, Bash and SQL, primarily. Also, if the language choice doesn't tell you already, I was doing web work in PHP but now I am more of a cloud developer working on backend code and in Kubernetes.
@@aarona3144 - Over the years, many languages. Over the past 15 years, 10 was PHP, JavaScript, and SQL - PHP & JS not by preference but that is where I could find paying clients.- and for the past 5 years I have been working in Go, Bash and SQL, primarily. Also, if the language choice doesn't tell you already, I was doing web work in PHP but now I am more of a cloud developer working on backend code and in Kubernetes.
Man, this is pretty cool. I got REALLY into Ruby on Rails when it first showed up around 2006, and it was my primary work environment from 2007 to 2013. I kind of burned out on web development after that and ended up mostly doing back end stuff, so I haven't really kept up on the space since then, but I'll keep my eye on Loco.
Hmm - do you mean MVC isn't flexible enough such that you find yourself having to work around it, or you like it because it prevents you from implementing antipatterns?
Holy crap, this is really cool :D. I've been doing webdev using full stack JS frameworks (Cringe) like Svelte + Svelte Kit or whatever, but Loco looks awesome and I'm planning on using it for my next project. Also, it'll be cool not to have to update my JS packages every 2 days because of some "high severity CVE" in some obscure package that the framework depends on.
Peace of mind is what you get. While building Loco AND while building projects based on Loco -- I'm having an unprecedented experience of peace of mind. No deps breaking, no high CVE, just pure silence, joy.
I feel like using Rust as Rails is the same as using CBR on a track without turns. Rails itself hasn't had the goal to imitate Rails, and I guess that any Rails like project fall into the success trap. Futhermore when you use ruby with magic it is okay, but using rust with magic? How far you will go? What can you achieve for yourself and in general relying on miraculous rails? This MVC scaffolding really the thing after you come to rust?
oh interesting I didn't realize Rust was being used for CGI - if you don't mind me asking, what kind of CGI specifically? What frameworks / crates do you use?
Hopefully loco drops the external crates and decides to incorporate their own versions of their own services to not have the same issues like in JS ecosystem.
For very stable crates -- we take external ones. We read the code of external crates and we're very mindful of what goes inside. For other cases, we definitely implemented our own.
@@jdot this is awesome. i can see this becoming something you migrate to when costs/latency become bottlenecks. eventually it'll be something you use like rails/laravel for everything when you become fast at rust.
This was a major factor for deciding to go with SeaORM - it is sqlx based. I had initially approached with caution, saying to myself "if anything, I can always grab a db connection and go with sqlx". Turns out SeaORM is really great -- it's lightweight even though it's feature packed (much thanks to Rust being... well... Rust). And because we chose to pass a connection explicitly with every DB operation (and not keep it globally somewhere) you can always mix-n-match Sqlx and SeaORM anywhere you want. Granted, we do generate code for SeaORM.
@@jdot Hmmm, interesting. I think I will have to try it out! I actually never used SeaORM. I have a negative view of ORMs since I work with Django and oh my, sometimes it makes me struggle.
ORMs are too rigid usually, they force you into a specific modeling. When I went from the django ORM to using SQLx in Rust, it was awesome. Having the full power of SQL and of the database.
Nice project. Rails is great for how opinionated it is. Laravel, however, is the king of web frameworks. Imagine when someone makes something similar to it in Rust.
i'm noob in rust and loco coming from laravel web framework. today testing loco web framework in API Rest mode, so much need to be add, especially on validation message and auto generate api doc, but so far this framework is promising i hope you will cover more loco web framework tutorial
Yes. I've used: Rails, Rails on JRuby, Groovy and Groovy on Rails. I've also used Django, Phoenix/Elixir, and every Rails-like framework in Node (Tails, Sails, Adonis, etc.). Some of these I put in production and were my day job, some I realized shortly into using - that should never reach production, ever. PHP/Laravel is something I did not have a chance to put in production, but back in the late 90's early 00's I did a lot of PHP and what-have-you Python web frameworks of the time (cherrypy, and other relics). I then proceeded to build Loco.
Being an early user of django (which is around the same age, and I did select it over ruby/rails, while both of them were more obscure, and did not know it would be a career defining decision), I also tried around to make my own rust stack (axum, htmx, minijinja, seaorm), so loco is really on the top of my list to try working through a larger/medium project as well. However, I am not yet entirely sold, I rather like the "make it easy to code" approach django has, where I often write my models as code, over the code generation I have to use from the command line. I am also not quite happy yet with seaorm, as it sometimes feels more work with it, than simply using SQL (something you cannot say if you work a lot with django's orm), I guess the DDD focus has upsides and downsides there. I do admit, using one for years does make a skill gap, so this is just my butt feeling. I am always also a bit perplexed, why ORMs do not focus on being more focused on code as a source of truth, and instead forces one to write SQL migrations. Every time someone says he hates ORMs, but uses one, it turns out, it is one of those, that has no migration system. I do not see the point in an ORM, that does not make my code the source of truth, even if I model my system around an already existing db. I do see that at least loco tries to solve this issue in a way, but I am not sure if I like the way.
what is the problem with scaffolding though? you can easily do everything yourself if wish so, or you can just scaffold all/part. even when code is generated you will definitely touch it at one point and change it
Unike Ruby, Rust forced us to make all the magic "in the open". Because it's statically typed, and because it's safe, most of the magic is explicit. So you do have ways to start from code, no problem with that. In fact, the longer guide on the website takes the "under the hood" approach teaching you how to do manually, everything the generators does automatically. Sounds like you're a person that can join us by contributing :)
Seems cool. Not a fan of people trying to make Rust work on the front-end, but for a server language and templates, it seems like a solid choice. It just needs a good batteries-included framework, but I honestly don't like the approach of heavily leveraging community crates for that. Maybe I just have a bad taste from using npm though.
@@codetothemoon I think flexible languages work better for UI. The stakes are low and you can move faster. Designers can also pick up scripting languages much easier to help with basic implementations of UI components, which is a massive help for front-end developers who have to implement the more complex logic. Now don't get me wrong, I'm not saying JS is better for this. I'd rather see a better scripting language used. And NPM is cancer. I just don't think the benefits Rust brings to the table justify the additional overhead and skill required to use it for UI.
Time to build != performance, in most cases critical performance areas could be optimised and most of them are DB queries and not Meta layers. Rust is nice language but for fast and efficient development is not the best choice. On each change you will wait a lot of time to check all memory safe stuff while in runtime you need to check less, paradoxical thing that yet to find by those who will try to chose this tech.
From my experience only with Loco (I have other Rust experience in bigger, more complex projects) -- everytime we needed to do a major refactor -- which would have been super scary, super insane in other languages -- it's been a safe journey in Rust. The idea of the compiler checking stuff out for you, is real. Even when you have great test coverage, with major refactoring you'll get bit by stuff you didn't see because you're living in three worlds -- the modeling of a problem before refactor, the in-between work (which is where you'll do a lot of mental gymnastics), and the final and refactored modeling. Rust is fantastic for reducing that mental fatigue, I'm willing to pay some compilation time for that.
Good question - razor is a frontend wasm framework right? In that case it might be apples and oranges because loco is server side. Leptos, yew and Dioxus might be more comparable
I am not a big fan of SSR templates, that's why i would keep a Js or Rust Framework for the front part. However with an SEO perspective it might be a more convenient choice.
soooo Rusty Rails got it Loco has the advantage of building a template engine while looking at many other templating engines and seeing what works and what doesn't after many years of experience, and it does the same with all the other things that are just expected out of the box
(Edit: I should have checked the documentation first, since "Loco’s design focuses on reducing boilerplate code and providing intuitive APIs".) Neat! I just don't think generating boilerplate through CLI tooling is the solution. It can be a workaround, but the goal should be to get rid of as much of it as possible. While I've only worked on a single (and maybe not very idiomatic) Rails project, having generated code scattered everywhere was a bit of a burden. Especially when upgrading to newer versions of the framework.
For Loco, the idea is that as you progress up the ranks of experience, you would just create your own code without generators. The longer guide takes this approach, for the people who like to create stuff manually. Unlike Rails, Loco offers much more freedom. Because everything is just Rust code, you can put your models anywhere you like, just reference them properly. You can even build a full Loco app in 1 single file (we've tried this just to see that we can), compile to binary, and copy 1 file to production.
Tried loco myself, i don't really like the fact that its opinionated and since the base is done without any input its hard to grasp your own project at first.
@@vectoralphaSec If you think about it, ofc. But here its based on someone else opinions. I've made my own templates for this exact reason. Granted is more manually intensive than using loco but i feel like devs have a lots to gain by picking themself the tools they want to work with.
@@codetothemoon I've made multiple projects using Leptos! My last one is a website that download youtube video, convert them to mp3 and put them in my navidrome library. Its was really easy to do with Leptos, so much so that i've lost way more time on the styling than the backend. Can also recommend without any doubt.
1:59 at there’s the first problem with Loco… that doesn’t look like Rust in the view file… it looks like some templating language like liquid or handlebars. Ruby on Rails in the other hand uses actual Ruby code in the view file. Loco should look into that if it wants to compete properly… otherwise you way as well stick to a proper front end framework.
erb files indeed has Ruby logic and feel more like Ruby. We use Tera, which is somewhere between a declarative template language (like liquid) and a variant of a Rust script-like language. Our ViewEngine integration allows us to integrate *any* templating language Rust has to offer, so all we need is to find something closer to Ruby's Erb. I haven't personally found something like that.
@@jdot in theory it shouldn’t be hard to build if Rust has some kind of meta language capability like Ruby. I think the ERB files essentially get parsed and the HTML portions gets converted to something akin to string concatenation operations, while the Ruby stays as Ruby. C# view templates do a similar thing, and obviously PHP too. So it should be possible for Rust to follow the same process. Maybe just run the ERB gem through ChatGPT to convert it to Rust lol.
That is true. But there are other concerns. For example, going with Rust unlocks much cheaper servers, to get the same perf you'd get with Rails, or better. So you can go on the cheap (which is one of the principles I've taken -- making sure you can build apps super cheap). Another reason is that -- there may come a time, when you really need that performance. For example, scraping, parsing lots of data, as part of a background job. With Ruby, or Python -- at that point you'll start looking for a highly optimized library (which is usually written in C/C++ or even Rust), that alone will take down your productivity. There are more reasons -- but all fall into the category of "if it works for you, and you like it, why not use more power if it's free?"
@@jdot Thank you for such a detailed response. I'll try to answer just as thoroughly. No business needs such extreme optimization unless it's on the scale of Google. I work in gambling. We have over 10,000 players online. This runs on two Hetzner desktops (128 GB RAM each) - one for the Ruby on Rails application with 100 workers, the other for the Postgres database. Workers mostly wait for responses from external services, like casino balance updates. For performance-critical math calculations, we use a Rust library wrapped in Ruby, written once 3 years ago and included as a gem. We pay less than $300 monthly for this setup, with 99.99% uptime. It's extremely cost-effective. We also use horizontal sharding, creating environments globally closer to clients. If we need to support more players, we deploy a new environment within a day using automation. Additionally, Ruby on Rails backend developers are more available in the market, more affordable, and generally understand web development better than the average Rust developer. This isn't a unique case - I've been in web development for over 15 years and seen various projects from marketplaces and food delivery to flight search and media. Rust would be excessive in these scenarios and still lag behind stacks designed for web development. Whenever I needed performance as a CTO, I used separate services (like AnyCable) or small Golang services, or Elixir/Phoenix. Rust might be useful for web in 0.0001% of cases, but those likely don't justify a framework. They'd probably need something very custom. For all other cases where a popular web framework suffices, using Rust seems like "let's write a web app in Rust just because we can!" - a tech gimmick, in my opinion.
At my last job the backend was running on approximately 2000 CPU cores. The main Postgres DB was 7TB of data with ~1000 tables running on a 96 CPU machine which maxed out at 40% CPU. We could have saved a lot of machines if our backend was written in a faster language. But development speed is equally important and not having to compile is big.
the benchmark that includes a database read (covered in the video) seems to refute this theory! Order of magnitude more TPS with Loco vs Rails when both are performing the same database read. That's not to say the benchmark perfectly represents a real world situation, but it seems clear that the language / framework can have a huge impact on performance. One that is not drowned out by the DB performance.
@@codetothemoon If we're talking about just reading from the database and returning formatted responses, the issue isn't really about framework speed, but rather about properly implemented caching strategies. Effective multi-level caching - at the nginx level, application server level, and within the application itself - will typically yield far greater performance gains than switching to a theoretically faster framework. In real-world, high-load systems, this approach is usually more impactful and cost-effective than chasing raw framework performance metrics.
We have the _channels_ abstraction, which lets you use Websockets. Honestly, I haven't yet seen a reason to include gRPC or tRPC as part of the framework, but if someone makes a convincing argument (with a pull request to show), we can consider it
@@jdot thank you for your answer, I mean if we have some other solution for such things how we can include them into framework? Also it would be nice to see code examples.
yes i do! I do have an emacs video in my plans, though I'm not entirely sure when I'll get to it. re: Rust setup though, there isn't much to it, at least for me. I mainly just uncomment "rust" in the doom emacs init.el.
It was actually called that way. That's why, for example, our code generation framework which we built especially for this, is still called "rrgen" (rusty rails gen). But then I looked for a 4 letter word, that would flow out of your fingers, that would also connect with a Locomotive / Rails / etc. 🙂
Just embed Ruby into your Rails application. 😂 Also, we never rage. We are all serene like a well balanced painting until we see a Python developer in the wild. ❤ 🐍
Rust has only started. It's the only language that have a footprint in the Linux kernel, AND webdev-like projects. It's already powering hypervisor projects in Amazon (and also IIRC MIcrosoft now).
Rust has become the new Linux meme; this will be the year of Rust on the web. It's a great systems language but a terrible choice for writing backends. Go is right there, and I can pretty much guarantee that the server I'll write in Go in 10 minutes will be faster than the one you'll write in an hour in Rust.
@@codetothemoon Elixir and Phoenix is an answer to ROR performance that is mature and used by companies like Discord, Pinterest, PepsiCo, Apple. It comes from the same premises that you lay down in your intro: combining the devx of Ruby and Rails with something (way) more performant and reliable. I think Loco is sufficiently similar to be compared with Elixir, just for the general knowledge of your viewers :) Thank you for your videos BTW
They are definately different! They are both used as examples for their respective frameworks. For example on the rails site DHH walks through building this “posts” app in Rails. Though I think he goes a bit deeper than we did in this video
Checked it out awhile ago, I don’t remember a ton but I don’t think I was ultra impressed. Didn’t seem to be on the same level as Leptos and Dioxus. Would love to be proven wrong though!
Interesting video. However, looking slightly away to read your script is distracting (for me at least), either make it more deliberate i.e. completely turn your head to read another screen or memorise what you're going to say and look directly at the camera.
@@ilmuoui there are bazillion website frameworks, and like 2 viable eCommerce frameworks - wordpress & shopify (very expensive). plus you can do 100% what all the other web frameworks do with php + html + js + css. php is not that slow mind you, i doubt rust would offer any meaningful performance improvements.
Seeing the templating reminded me of how much I dislike templating. You don't know what variables to expect in the controller and you don't know what variables are provided in the template. It's pretty awful in my opinion.
As mentioned in the video, I'm currently working my way through a Quantum Computing course on Brilliant. Highly recommend the course and Brilliant in general. They have courses on programming, LLMs, and other domains as well.
👉 To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/CodetotheMoon/ You’ll also get 20% off an annual premium subscription.
Rust on Rails = Railway
Railgun
@@Дмитрий-о8м9с - Rusty Rails
😂 Isn’t railway a cloud service tho?
Ooh I love this name!
Railrust. Oxidized to the core 😂
Rust in Rails?! I'm not getting into any train going through that!!!
😂 fair enough!
Rust in Rails
🦀 🚂
i was confused about what this is at first but then when the code came on the screen i knew what's happening.
i have used **Jinja2 for Python** to write html templates and then autogenerate them into static websites,
and i can immediately recognize that is the same design pattern but now in rust, that's awesome
Rusty Rails 😊
Thanks for this video! Really well done, you managed to capture the essence of what we're trying to do with Loco. Appreciate the coverage of the back story because that's been an important driver of the features and maturity of the framework. Thanks! 🚂♥
A lot of the value in Rails *is Ruby*, in that it enables very rapid slop / prototyping.
Yeah I agree. We can even see in the comparison shots that a method in Ruby was 3 lines, where the Rust idiosyncrasies made the method 10 lines long.
It’s a worthwhile trade off for security and performance, but it absurdly thrashes the « Ruby is made for developers comfort » mantra, which is extended to Rails
@@COLAMAroro you might like Amber or Lucky in the Crystal language, if syntactic ergonomics are your thing...
This is surreal seeing how I started programming (Ruby, vaguely in 2013-2025, using RPG Maker, never rails….then seriously again in 2021-2022 with Rails.) getting to witness two paths merge together.
Rust is really unstoppable. I was already kind of sold with Bevy, although I havent built anything big yet.
Anyway, back to the video.
6:29 I'd argue it's the other way around. Smaller companies usually don't have a lot of traffic (yet). So having sub optimal hardware/software is less of a concern. Combine that with the overhead of complexity a language like Rust can bring in projects that are still changing a lot and it makes it even less of an argument for doing this imo.
This is great, now I will wait till everyone complains on how bloated this is and Rust Sinatra comes out using just Axum, SQLX and Maud
Rust Sinatra sounds like an awesome name!
Here's the twist. Because of Rust, this does not feel bloated, and there's no "bloatness". (1) Rust as a language has a very low to no LOC overhead (as you add more lines of code, you don't "pay" in runtime like in dynamic languages and (2) Rust has zero cost abstractions, which makes all the stuff that *feel* bloated like traits, wrappers, and so on - zero cost (3) You can compile away features or chunks of Loco you don't like, which is again a feature of Rust.
So all in all, there is no need for a Sinatra, other than people having a different *taste* (which is not something that's scientific, just a matter of.. taste)
Prefer sailfish to maud
I’ve been working through a Zero2Prod and the stack is Actix-Web with SQLX and Postgres. While hilariously overkill for the actual project, scales well
'til*
The first time I used Rails I remember thinking « we need that in rust », anyways great video
Thanks glad you liked it!
Rust on Rails, alias Hungarian State Railways (MÁV)
I find it hilarious how he tried to build ruby in node and updates always broke his project. I feel that’s the big problem with react is that nothing is stable and your build always breaks as they just have breaking changes all the time and because everything runs client side you have to keep up to maintain the security updates and there is just this constant maintenance cost with JavaScript. To me that is the appeal of rust as a compiled language it will have way less breaking changes and way more stability
Not only that, but the tools broke too. And then, you have this peer pressure -- should you stay with Wepback although everything moves on to Vite? (and then to the next tool in the future?). Every such migration is a "break the world" event. It made me unhappy, unwanting to open the project.
With Loco, every feature request -- I get this excitement, and can't wait to dive in and implement. I know Rust and the tools will always be stable, and that things I left there will stay the same.
Uhm rust does have dependencies as well??????
The mentality in the JavaScript community to break things ALL THE DAMN TIME is insane!...
@@QefxPeak job security
I would just use Elixir/Phoenix and use Rust only if needed, with the help of Rustler.
Heard amazing things about Phoenix, can’t wait to try it myself. Hadn’t heard of Rustler, will look into that as well!
Isn't that what Gleem is supposed to be? A rust-esque language in the Erlang-VM space.
@@gljames24 Yeah, Gleam is ML-inspired, as is Rust. But the ecosystem isn't ready yet, IMO. So I'd stick to Elixir.
But is the phoenix performance as good as loco ?
@@julienv7031 No, Elixir and the BEAM (the VM it runs on) are fast - at least compared to Ruby - and keeps on getting faster, but they're clearly not as fast as Rust can be. There are many reason for that: running on a VM instead of being native, immutability, fair scheduling, ...
But usually that's not the point. Being fast is nice but being fault-tolerant is generally what you want, at least most of the time.
And in this area the BEAM is unbeaten. It offers tools like actors, supervision tree, fair scheduling, ... so your operations keep on running under unusual circumstances. Instead of crashing directly, it smoothly runs in degraded mode, but still trying to recover.
If you really want speed you can optimize the parts of code that are slow and code them in another language: C, C++, Rust or Zig are the most used ones.
I've been programming since before the web, and when Rails emerged its community felt to me like a specific type of cult. Once Rust gained a following, it community felt to me like the same type of cult as if it was the Ruby cult reincarnated. Now that Rails had made it to Rust I think my gut feelings about the two communities have been validated. 😳
yeah, pretty much. look up Steve Klabnik
@@knowledgedose1956 - Yeah, no need. That was exactly one of the cult members I was thinking of. 🤷♂
What languages and domains do you work with?
@@aarona3144 - Over the years, many languages. Over the past 15 years, 10 was PHP, JavaScript, and SQL - PHP & JS not by preference but that is where I could find paying clients.- and for the past 5 years I have been working in Go, Bash and SQL, primarily. Also, if the language choice doesn't tell you already, I was doing web work in PHP but now I am more of a cloud developer working on backend code and in Kubernetes.
@@aarona3144 - Over the years, many languages. Over the past 15 years, 10 was PHP, JavaScript, and SQL - PHP & JS not by preference but that is where I could find paying clients.- and for the past 5 years I have been working in Go, Bash and SQL, primarily. Also, if the language choice doesn't tell you already, I was doing web work in PHP but now I am more of a cloud developer working on backend code and in Kubernetes.
Man, this is pretty cool. I got REALLY into Ruby on Rails when it first showed up around 2006, and it was my primary work environment from 2007 to 2013. I kind of burned out on web development after that and ended up mostly doing back end stuff, so I haven't really kept up on the space since then, but I'll keep my eye on Loco.
After about 8 years of doing MVC I learnt MVC is a challenge in breaking the MVC pattern as much as you can while still having the app compile.
Hmm - do you mean MVC isn't flexible enough such that you find yourself having to work around it, or you like it because it prevents you from implementing antipatterns?
Yo carlitos, this framwork is loco man!
Ahahah 😂
Holy crap, this is really cool :D. I've been doing webdev using full stack JS frameworks (Cringe) like Svelte + Svelte Kit or whatever, but Loco looks awesome and I'm planning on using it for my next project. Also, it'll be cool not to have to update my JS packages every 2 days because of some "high severity CVE" in some obscure package that the framework depends on.
Nice! Loco seems great but If you want something a little more similar to SvelteKit, maybe check out Leptos!
Peace of mind is what you get. While building Loco AND while building projects based on Loco -- I'm having an unprecedented experience of peace of mind. No deps breaking, no high CVE, just pure silence, joy.
@@jdot poetic
I feel like using Rust as Rails is the same as using CBR on a track without turns. Rails itself hasn't had the goal to imitate Rails, and I guess that any Rails like project fall into the success trap. Futhermore when you use ruby with magic it is okay, but using rust with magic? How far you will go? What can you achieve for yourself and in general relying on miraculous rails? This MVC scaffolding really the thing after you come to rust?
I use currently Rust on CGI. It works pretty well. But this tool looks quite good and similar to a framework I used for Java.
oh interesting I didn't realize Rust was being used for CGI - if you don't mind me asking, what kind of CGI specifically? What frameworks / crates do you use?
Hopefully loco drops the external crates and decides to incorporate their own versions of their own services to not have the same issues like in JS ecosystem.
For very stable crates -- we take external ones. We read the code of external crates and we're very mindful of what goes inside. For other cases, we definitely implemented our own.
@@jdot this is awesome. i can see this becoming something you migrate to when costs/latency become bottlenecks.
eventually it'll be something you use like rails/laravel for everything when you become fast at rust.
i build my first real estate business using ruby and angular years ago. it is still live without any issues
Nice, if it’s not broken don’t fix it!
@@codetothemoon indeed, we tried to use dynamodb and appsync instead for a serverless backend but it didnt work. my simple code worked better :)
Rust on Rails: Rawr
🦀😎
I would prefer just SQLx instead of an ORM...
Understandable, that is typically my preference as well
This was a major factor for deciding to go with SeaORM - it is sqlx based. I had initially approached with caution, saying to myself "if anything, I can always grab a db connection and go with sqlx". Turns out SeaORM is really great -- it's lightweight even though it's feature packed (much thanks to Rust being... well... Rust). And because we chose to pass a connection explicitly with every DB operation (and not keep it globally somewhere) you can always mix-n-match Sqlx and SeaORM anywhere you want.
Granted, we do generate code for SeaORM.
@@jdot Hmmm, interesting. I think I will have to try it out! I actually never used SeaORM. I have a negative view of ORMs since I work with Django and oh my, sometimes it makes me struggle.
@@arcstur why, can you elaborate?
ORMs are too rigid usually, they force you into a specific modeling. When I went from the django ORM to using SQLx in Rust, it was awesome. Having the full power of SQL and of the database.
Damn what a coincidence. I was looking into loco like 4 days ago lol!
Nice!
Nice project. Rails is great for how opinionated it is. Laravel, however, is the king of web frameworks. Imagine when someone makes something similar to it in Rust.
hah, I still need to check out Laravel. Lots of buzz about it in the past few years.
Hey @codetothemoon - which IDE and plugins do you use for the RUST ? Thanks
DOOM Emacs 😎
Thanks @@codetothemoon
i'm noob in rust and loco
coming from laravel web framework.
today testing loco web framework in API Rest mode, so much need to be add, especially on validation message and auto generate api doc, but so far this framework is promising
i hope you will cover more loco web framework tutorial
perfect timing after Rails conf and Rails 8 announcement
HTML is faster than Rust and C++
quite a bit less flexible though!
Does it have support for websockets ?
Let's hope Loco knows what a horrible nightmare Groovy on Grails is and don't make the same mistake
hah didn't realize Groovy on Rails was a thing!
Yes. I've used: Rails, Rails on JRuby, Groovy and Groovy on Rails. I've also used Django, Phoenix/Elixir, and every Rails-like framework in Node (Tails, Sails, Adonis, etc.). Some of these I put in production and were my day job, some I realized shortly into using - that should never reach production, ever. PHP/Laravel is something I did not have a chance to put in production, but back in the late 90's early 00's I did a lot of PHP and what-have-you Python web frameworks of the time (cherrypy, and other relics).
I then proceeded to build Loco.
@@codetothemoon also Sails.js was inspired by rails
Solid video, very cool to see Rails inspire another framework
thank you!
The miserable experience of rails with the difficult syntax of rust. Great idea😂
🤣
I did not look at it that way...😅
RustyRails! Finally!
😎
"On, Ruby don't take you love to town"
🎶
Being an early user of django (which is around the same age, and I did select it over ruby/rails, while both of them were more obscure, and did not know it would be a career defining decision), I also tried around to make my own rust stack (axum, htmx, minijinja, seaorm), so loco is really on the top of my list to try working through a larger/medium project as well. However, I am not yet entirely sold, I rather like the "make it easy to code" approach django has, where I often write my models as code, over the code generation I have to use from the command line.
I am also not quite happy yet with seaorm, as it sometimes feels more work with it, than simply using SQL (something you cannot say if you work a lot with django's orm), I guess the DDD focus has upsides and downsides there.
I do admit, using one for years does make a skill gap, so this is just my butt feeling.
I am always also a bit perplexed, why ORMs do not focus on being more focused on code as a source of truth, and instead forces one to write SQL migrations. Every time someone says he hates ORMs, but uses one, it turns out, it is one of those, that has no migration system. I do not see the point in an ORM, that does not make my code the source of truth, even if I model my system around an already existing db. I do see that at least loco tries to solve this issue in a way, but I am not sure if I like the way.
what is the problem with scaffolding though? you can easily do everything yourself if wish so, or you can just scaffold all/part. even when code is generated you will definitely touch it at one point and change it
Unike Ruby, Rust forced us to make all the magic "in the open". Because it's statically typed, and because it's safe, most of the magic is explicit. So you do have ways to start from code, no problem with that. In fact, the longer guide on the website takes the "under the hood" approach teaching you how to do manually, everything the generators does automatically. Sounds like you're a person that can join us by contributing :)
Ok, I wasn't expecting this to be honest, this is great
Glad you liked it!
Seems cool. Not a fan of people trying to make Rust work on the front-end, but for a server language and templates, it seems like a solid choice. It just needs a good batteries-included framework, but I honestly don't like the approach of heavily leveraging community crates for that. Maybe I just have a bad taste from using npm though.
Why don't you like Rust on the frontend?
@@codetothemoon I think flexible languages work better for UI. The stakes are low and you can move faster. Designers can also pick up scripting languages much easier to help with basic implementations of UI components, which is a massive help for front-end developers who have to implement the more complex logic.
Now don't get me wrong, I'm not saying JS is better for this. I'd rather see a better scripting language used. And NPM is cancer. I just don't think the benefits Rust brings to the table justify the additional overhead and skill required to use it for UI.
Time to build != performance, in most cases critical performance areas could be optimised and most of them are DB queries and not Meta layers. Rust is nice language but for fast and efficient development is not the best choice. On each change you will wait a lot of time to check all memory safe stuff while in runtime you need to check less, paradoxical thing that yet to find by those who will try to chose this tech.
From my experience only with Loco (I have other Rust experience in bigger, more complex projects) -- everytime we needed to do a major refactor -- which would have been super scary, super insane in other languages -- it's been a safe journey in Rust.
The idea of the compiler checking stuff out for you, is real. Even when you have great test coverage, with major refactoring you'll get bit by stuff you didn't see because you're living in three worlds -- the modeling of a problem before refactor, the in-between work (which is where you'll do a lot of mental gymnastics), and the final and refactored modeling. Rust is fantastic for reducing that mental fatigue, I'm willing to pay some compilation time for that.
I've been meaning to work on something like Symfony in Rust, but honestly this seems more promising.
What’s the difference between this and something like C# and razor? Speed wise
Good question - razor is a frontend wasm framework right? In that case it might be apples and oranges because loco is server side. Leptos, yew and Dioxus might be more comparable
Rail my Rust Backend
I am not a big fan of SSR templates, that's why i would keep a Js or Rust Framework for the front part. However with an SEO perspective it might be a more convenient choice.
soooo Rusty Rails got it
Loco has the advantage of building a template engine while looking at many other templating engines and seeing what works and what doesn't after many years of experience, and it does the same with all the other things that are just expected out of the box
iam really love your vim config!, its so simple yet powerfull
thanks, it's actually DOOM emacs!
@codetothemoon whoaaa, can i see your dotfiles?
Nice video!
Thank you Adrian!
Randomly brings up quantum computing 😂
Today it might sound random, in 5-10 years maybe not!
(Edit: I should have checked the documentation first, since "Loco’s design focuses on reducing boilerplate code and providing intuitive APIs".)
Neat! I just don't think generating boilerplate through CLI tooling is the solution. It can be a workaround, but the goal should be to get rid of as much of it as possible. While I've only worked on a single (and maybe not very idiomatic) Rails project, having generated code scattered everywhere was a bit of a burden. Especially when upgrading to newer versions of the framework.
For Loco, the idea is that as you progress up the ranks of experience, you would just create your own code without generators. The longer guide takes this approach, for the people who like to create stuff manually.
Unlike Rails, Loco offers much more freedom. Because everything is just Rust code, you can put your models anywhere you like, just reference them properly. You can even build a full Loco app in 1 single file (we've tried this just to see that we can), compile to binary, and copy 1 file to production.
@@jdot Thanks! Sounds good.
Elixir Phoenix should be the focus
I've been wanting to do a Phoenix video for quite some time!
haven't seen your channel in ages man and i love the beard on you very good look
Rust on Rail, interesting 🤔
indeed!
Tried loco myself, i don't really like the fact that its opinionated and since the base is done without any input its hard to grasp your own project at first.
Opinionated is best for fast productivity
@@vectoralphaSec Agreed. I'm tired to reinvent the wheel. Just use the common one even it's not perfectly match.
I can totally understand this perspective! The approach is definately polarizing.
Highly recommend Leptos if you haven’t tried it already 😎
@@vectoralphaSec If you think about it, ofc. But here its based on someone else opinions. I've made my own templates for this exact reason. Granted is more manually intensive than using loco but i feel like devs have a lots to gain by picking themself the tools they want to work with.
@@codetothemoon I've made multiple projects using Leptos! My last one is a website that download youtube video, convert them to mp3 and put them in my navidrome library. Its was really easy to do with Leptos, so much so that i've lost way more time on the styling than the backend. Can also recommend without any doubt.
Rust + Ruby = Rusberry
It's Rust + Rails though!
@@codetothemoon Do you have it to be Rustail's Jinchuriki ?
Thank you for the video!
My pleasure!
1:59 at there’s the first problem with Loco… that doesn’t look like Rust in the view file… it looks like some templating language like liquid or handlebars. Ruby on Rails in the other hand uses actual Ruby code in the view file. Loco should look into that if it wants to compete properly… otherwise you way as well stick to a proper front end framework.
erb files indeed has Ruby logic and feel more like Ruby. We use Tera, which is somewhere between a declarative template language (like liquid) and a variant of a Rust script-like language.
Our ViewEngine integration allows us to integrate *any* templating language Rust has to offer, so all we need is to find something closer to Ruby's Erb. I haven't personally found something like that.
@@jdot in theory it shouldn’t be hard to build if Rust has some kind of meta language capability like Ruby. I think the ERB files essentially get parsed and the HTML portions gets converted to something akin to string concatenation operations, while the Ruby stays as Ruby. C# view templates do a similar thing, and obviously PHP too. So it should be possible for Rust to follow the same process. Maybe just run the ERB gem through ChatGPT to convert it to Rust lol.
No one needs such performance from the web framework. In real life the DB will be a bottleneck.
That is true. But there are other concerns. For example, going with Rust unlocks much cheaper servers, to get the same perf you'd get with Rails, or better. So you can go on the cheap (which is one of the principles I've taken -- making sure you can build apps super cheap).
Another reason is that -- there may come a time, when you really need that performance. For example, scraping, parsing lots of data, as part of a background job. With Ruby, or Python -- at that point you'll start looking for a highly optimized library (which is usually written in C/C++ or even Rust), that alone will take down your productivity.
There are more reasons -- but all fall into the category of "if it works for you, and you like it, why not use more power if it's free?"
@@jdot Thank you for such a detailed response. I'll try to answer just as thoroughly.
No business needs such extreme optimization unless it's on the scale of Google.
I work in gambling. We have over 10,000 players online. This runs on two Hetzner desktops (128 GB RAM each) - one for the Ruby on Rails application with 100 workers, the other for the Postgres database. Workers mostly wait for responses from external services, like casino balance updates. For performance-critical math calculations, we use a Rust library wrapped in Ruby, written once 3 years ago and included as a gem.
We pay less than $300 monthly for this setup, with 99.99% uptime. It's extremely cost-effective. We also use horizontal sharding, creating environments globally closer to clients. If we need to support more players, we deploy a new environment within a day using automation.
Additionally, Ruby on Rails backend developers are more available in the market, more affordable, and generally understand web development better than the average Rust developer.
This isn't a unique case - I've been in web development for over 15 years and seen various projects from marketplaces and food delivery to flight search and media. Rust would be excessive in these scenarios and still lag behind stacks designed for web development. Whenever I needed performance as a CTO, I used separate services (like AnyCable) or small Golang services, or Elixir/Phoenix.
Rust might be useful for web in 0.0001% of cases, but those likely don't justify a framework. They'd probably need something very custom. For all other cases where a popular web framework suffices, using Rust seems like "let's write a web app in Rust just because we can!" - a tech gimmick, in my opinion.
At my last job the backend was running on approximately 2000 CPU cores.
The main Postgres DB was 7TB of data with ~1000 tables running on a 96 CPU machine which maxed out at 40% CPU.
We could have saved a lot of machines if our backend was written in a faster language. But development speed is equally important and not having to compile is big.
the benchmark that includes a database read (covered in the video) seems to refute this theory! Order of magnitude more TPS with Loco vs Rails when both are performing the same database read.
That's not to say the benchmark perfectly represents a real world situation, but it seems clear that the language / framework can have a huge impact on performance. One that is not drowned out by the DB performance.
@@codetothemoon If we're talking about just reading from the database and returning formatted responses, the issue isn't really about framework speed, but rather about properly implemented caching strategies. Effective multi-level caching - at the nginx level, application server level, and within the application itself - will typically yield far greater performance gains than switching to a theoretically faster framework. In real-world, high-load systems, this approach is usually more impactful and cost-effective than chasing raw framework performance metrics.
Really interensting to hear about how does it support modern stuff like websocket, communicating with third-party stuff as MQ, gRPC etc.
We have the _channels_ abstraction, which lets you use Websockets.
Honestly, I haven't yet seen a reason to include gRPC or tRPC as part of the framework, but if someone makes a convincing argument (with a pull request to show), we can consider it
@@jdot thank you for your answer, I mean if we have some other solution for such things how we can include them into framework? Also it would be nice to see code examples.
5:20 yep... js in a nutshell
Please check SpringRS is very new but looks great. A real alternative of Spring of Java compatible with Axum and Tower middlewares.
Thanks for putting this on my radar, hadn’t heard of it!
20 years and people still completely misunderstand what made Rails great.
Let us in on it! Part of my goal here was to understand the rails mindset in general. If there’s something I missed please let me know!
BTW, do you still use Emacs ?
If yes then, can U make a video on setting up Rust for Emacs ?
yes i do! I do have an emacs video in my plans, though I'm not entirely sure when I'll get to it. re: Rust setup though, there isn't much to it, at least for me. I mainly just uncomment "rust" in the doom emacs init.el.
There is Phoenix, no need for RUST RAILS.
Ow I was thinking about a full fledged web framework for very long time I am happy some people are making it a reality
I’ll stick to ol’ reliable Ruby on Rails, no need to replace the first part of that.
Fair enough, seems like the Loco author would approve!
Long time viewer, I've always wanted to ask what IDE, theme, and font you use. It is all so crisp and easy to read and the colors have great contrast.
i do love Ruby
Missed chance to name it RustyRails
I think at one point at least there was a project called "Rust on Nails"
😂
@@killersquirel11 Indeed, Rust on Nails was a kind of a blog post
It was actually called that way. That's why, for example, our code generation framework which we built especially for this, is still called "rrgen" (rusty rails gen). But then I looked for a 4 letter word, that would flow out of your fingers, that would also connect with a Locomotive / Rails / etc. 🙂
Couldn't even be bothered to add the link to Loco in the description or comments...
Sorry about that, should be pretty easy to find though! 🙃
An order of magnitude in CS is 2, so if half as fast would be the same as ruby and NOT at all impressive.
I’m referring to a base 10 order of magnitude, which would be a factor of 10
you should make a video on leptos 0.7
good idea, I just may!
Instead Ruby on Rails, we got here Rust on Rails.
indeed!
missed opportunity to not call it Railgun
😂 agree 💯
Rubyists are going to ragequit
Like Dotan, I say if you enjoy Ruby and cloud compute costs aren’t an issue, stick with it!
Just embed Ruby into your Rails application. 😂
Also, we never rage. We are all serene like a well balanced painting until we see a Python developer in the wild. ❤ 🐍
Now can he do that for V too?
This is the end for Rust. Rails already killed Ruby, now it will finish off Rust. It's over.
it seems like most would argue it carried Ruby! How do you think it killed Ruby?
Rust has only started. It's the only language that have a footprint in the Linux kernel, AND webdev-like projects. It's already powering hypervisor projects in Amazon (and also IIRC MIcrosoft now).
IMO, no more template. Reason: the amount of time used to learn templates can be used to learn vuejs (simpler than Angular and React, IMO).
Vue has templates too, doesn’t it?
@@codetothemoon correct 😊
Rusted rails... stay safe out there 😂
So, I should learn Ruby *and* Rust?
That depends on your particular situation, but I find it hard to imagine one where learning both simultaneously would be necessary!
Rusted Rails
You must learn Rust first, which means you need to delve into hell.
🔥👹🔥
The first problem is not performance but how to get users
indeed, if only they would make a framework that optimizes for user acquisition! 😎
Sic transit gloria mundi
Rust has become the new Linux meme; this will be the year of Rust on the web. It's a great systems language but a terrible choice for writing backends. Go is right there, and I can pretty much guarantee that the server I'll write in Go in 10 minutes will be faster than the one you'll write in an hour in Rust.
Go is a forced meme by Google. Learn lisp. Clojure is a bliss. Common Lisp is fantastic because of its interactive experience.
Why is Elixir not mentioned here?!
Love what I’ve seen of Elixir so far, which is admittedly very little - was there something here that was ripe for comparison to it?
@@codetothemoon Elixir and Phoenix is an answer to ROR performance that is mature and used by companies like Discord, Pinterest, PepsiCo, Apple.
It comes from the same premises that you lay down in your intro: combining the devx of Ruby and Rails with something (way) more performant and reliable.
I think Loco is sufficiently similar to be compared with Elixir, just for the general knowledge of your viewers :)
Thank you for your videos BTW
Rusty Rails? Hmm.
interesting right?
Those two templates you show at the start are not really the same. For one the b is not the same as strong
They are definately different! They are both used as examples for their respective frameworks. For example on the rails site DHH walks through building this “posts” app in Rails. Though I think he goes a bit deeper than we did in this video
The issue is getting people to learn rust
Classic Ruby RoR devs will cry, when them will meet trait bounds...
Checkout sycamore when you can
Checked it out awhile ago, I don’t remember a ton but I don’t think I was ultra impressed. Didn’t seem to be on the same level as Leptos and Dioxus. Would love to be proven wrong though!
Interesting video. However, looking slightly away to read your script is distracting (for me at least), either make it more deliberate i.e. completely turn your head to read another screen or memorise what you're going to say and look directly at the camera.
Thanks for the feedback, I was experimenting with something new for this video, so this is exactly the sort of thing I need to hear!
@@codetothemoon I actually just watched your old video about Rust on AWS and it was so much more natural. Keep it up man!
will it help me write ecommerce shops? if not its useless.
Why wouldn't it?
@@ilmuoui there are bazillion website frameworks, and like 2 viable eCommerce frameworks - wordpress & shopify (very expensive). plus you can do 100% what all the other web frameworks do with php + html + js + css. php is not that slow mind you, i doubt rust would offer any meaningful performance improvements.
I don’t think Loco would be the first thing I’d reach for when building an e-commerce site. But I don’t think that makes it “useless”….
rust on nails
I think this was the name of a "meta" framework proposed in a blog article right?
Ruby doesn't perform well - Ya thats true HM GITLAB!!
it looks like laravel
really? never tried Laravel myself. maybe it's time to take a look.
yep... Laravel and Rails are quite similar. the DX with Laravel is great
Seeing the templating reminded me of how much I dislike templating. You don't know what variables to expect in the controller and you don't know what variables are provided in the template. It's pretty awful in my opinion.
Honestly, I doubt anyone enjoying Rails would want to write in Rust. One is fun, the other is just tedious.
IDK man, C is the King, Rust is a hype for me
who the f does a web server in C
Use whatever gets you excited to build things!
Longer beard please
If this is for me -- you have a sharp eye. I'm on beard diet.
Working on it! maybe.
OMG I hate Rust!