I was surprised not to see Rocket (https://rocket.rs/) mentioned among the frameworks the author listed; I haven’t used it myself because I _like_ the more unopinionated axum/actix-web, but as I understand it its goals are much more in the vein of what the author wants in a batteries-included framework and it’s been around for a while now.
While Rocket was one of the earliest Rust frameworks that really pushed for good UX (via proc-macros), I think it has largely fallen out of favor in many parts of the community. For a very long time it required nightly Rust versions to build, which is a no-go for many people wanting to use a framework in a production setting. Also for a period of ~2 years it was stuck in a 0.5.0 release candidate limbo where the latest stable released version was significantly lagging behind the rest of Rust web frameworks (requiring nightly; no async support yet).
Maybe it will be better now after the 0.5 hump, but in general the development history of Rocket is something that dissuades me from using it when compared to e.g. Axum.
When I asked them about that 2 year limbo, they said the release candidate was feature complete, and simply had incomplete documentation (also some plans for a new management structure).
So, it wasn't actually lagging, it had that async for quite some time... But yeah, being in a "release candidate" did scare people off.
The author mentions flask but looking at the "What we need section", I don't think flask covers those. I hate Djago with a passion but if those are the requirements, I think Django is the one that closely resembles what the author is describing. So Poem is not a good candidate either in that regard. Poem is all in all, something that closely resembles FastAPI, which is actually a complement. I've tried half a dozen rust web frameworks and they all come with a ton of boilerplate fiddling with the initial setup. Which is a problem if you want to get things done fast. In that regard, poem nails it. Yes, actix has a considerably better performance but unless you are aiming for sub-30 millisecond responses, then actix is not what you should be looking at to begin with. Also if you crave a Pydantic, there is a crate that sort of does that for you: https://crates.io/crates/poem-openapi
This article makes several different points that would ideally each be tackled on their own.
You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need)
Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily
CSS/JS tooling makes no sense for many frontend Rust frameworks like Dominator, which is in Rust (not JS) and has its own approach to styling that works for it (e.g. attaching styles to signals, so they change on the fly)
I get what the author is saying - in fact I've been around the block a couple times solving all the different points in the article and it is painful. For example, see https://github.com/dakom/dominator-workers-fluent-auth which does a lot of the stuff here on the Cloudflare workers framework (also adds another wishlist item - localization with Fluent)
A "batteries included" full framework that does _everything_ is nice to have, but many real-world projects will want to replace those opinionated decisions and go the DIY route anyway. Rust is more than mature enough, even on the frontend web, to tackle all of that - if you know where to look (wasm-bindgen, etc.)
Doing my web stuff in Rust was fine but concurrency was a pain. A crate that abstracts web workers with transferrable types would help. After that you have to pick a component library of which there are few, and all are experimental. Making pretty, performant things is hard. Switching compontent libraries isn't easy. The backend stuff is a breeze, I think Rust is doing fine there.
I'm switching to Flutter for my UX needs. There's flutter-rust-bridge that binds Rust code concurrently without any headaches in the client, and I can deploy to the web, android, Linux, etc. with ease. Looks p. good out of the box. Got GRPC working quickly, am happy.
Using Rust in the client is nice because I have a single workspace that contains all of my business logic. Backend changes will cause errors in the client code if changes are necessary. The codebase is easy to refactor and trust. Dart ain't half bad.
I stayed away from Flutter at first because it doesn't respect the DOM etc but at this point I'm willing to sell my soul to the devil for how easy it is to make a great UX that deploys anywhere.
I don't love relying on something Google made, though. Feels a little like building a foundation on sand.
Take F# for a spin. It offers nearly all of the type system tomfoolery one craves and all the tooling and nice-to-haves one wants. The big drag is that the async story and memory management aren't as big as a time vampire as Rust, so you do run the risk of actually solving business needs. I am sure some part of dealing with Microsoft can fill that void, though.
Possible unpopular opinion: Rust is a systems language, doing "web work" in Rust is a waste of effort as there are much better languages and ecosystems for that.
The advantages of a language like Rust where most interactions are blocked on either user input or network IO are fairly limited. Rust shines when things are CPU or memory bound primarily. Web applications are mostly IO bound. Which is why people have been getting away with fairly poorly optimized interpreted languages for decades. Even when computers were a lot slower than they are today, this worked fairly well.
IDK I use C/C++ all the time for web servers. It's lightweight and lets you pretty easily/quickly call C/C++ and low-level code and gives you a lot of control in terms of networking. You can pretty much "do anything" in a straightforward generic way without having to learn some application specific language like PHP or through nginx/apache configuration files.
Having a rust alternative to something like libmicrohttpd would be nice and I would use it.
> You can pretty much "do anything" in a straightforward generic way without having to learn some application specific language like PHP or through nginx/apache configuration files
Not having to learn something like PHP? Do we not count learning C++? I would guess most people would agree learning PHP + Nginx is going to be a lot less complicated, which will be preferable for people just trying to build something. I'm not sure dropping down to such a low level is something most web developers will have to deal with.
I think that you find it easy speaks more to an already existing familiarity with C++, not that it would be a path of less resistance.
Counter-point: developing web services in Rust is just as easy as doing it in Go or Java, yet you now have an excellent type system (sum types!), an excellent package manager, and extremely good performance.
You can do dependency injection in Rust to share connection pools just like you would in Java, and it's super simple to write threaded background tasks.
Google gave a talk recently that said they measured Rust developers as no less efficient or productive than Go developers [1].
It's a fantastic language and you shouldn't ever limit yourself to systems programming with Rust. It can do so much more than that.
> "We have at this point rewritten a large number of systems [..] have some very concrete things that we can say"
> "When we've rewritten systems from Go into Rust, we've found that it takes about the same sized team about the same amount time to build it. [...] no loss of productivity when moving from Go to Rust."
> "We do see some benefits [...] we see reduced memory usage in the services that we've moved from Go. [...] We see a decreased defect rate over time in those services that have been rewritten in Rust"
> "Within two months about a third of the folks were feeling as productive, within four months about 50%."
> "People do indeed feel as productive in Rust as they do in their original language. C++, Java, Python, Go."
> "One of the biggest latencies is code review time [...] How hard is it to review code in Rust? [...] A little over half said that Rust is easier to review. The most incredible question [...] The confidence that people have in the correctness of the Rust code that they're looking at. [...] 85% of people believe that their Rust code is more likely to be correct."
No mention of loco-rs? poem? rocket? There's already a lot of projects that aim for a batteries-included experience.
What sets these projects apart from frameworks like leptos is that there's a CLI guiding you. That's what I love about Symfony, and what I consider the 'lazy' part.
Python has Django, C# has ASP .NET Core, Ruby has Rails, and so on... If you want to really make Rust take off with web development, build up a full-feature solution.
Rocket is maybe the closest? But it's not as batteries included as any of the frameworks I've mentioned.
If the post were C++ focused instead of Rust would it make the same, more or less sense?
A systems language with a high cognitive barrier to entry, compile times and less than a decade of wide adoption can’t reasonably be expected to compete with something like Rails in terms of approachability
I wouldn't mind a Rust based web framework that provides the same features as the base Servlet API. Everything else should be an optional library. When I look into it the rabbit hole goes too deep. It hasn't been immediately clear what the templating looks like. Usually they start talking about some "Reactive" framework, features I don't want and I lose interest. Afterwards, I realize that I'm already satisfied with my current web stack.
Jetty, HAProxy, JSTL, commons db connection pooling and Postgres.
It’s really not clear what you mean by “basic servlet API”, because the main rust web frameworks are pretty much just routing by default, with (largely opt-in) parsing and serialisation support.
It “hasn’t been clear what the templating looks” like because there isn’t any just as AFAIK servlets provide no templating.
Spring Boot, Django, Rails, Laravel, ASP, ... it's not unreasonable to expect Rust to have an equivalent to something that most popular languages have.
"Not every" is not the same as "none" and the discussion is about the majority, so I think your refutation is only of the absolute case and not of the original premise.
For me, the type system and the performance without having to do any optimization. The complete lack of runtime errors when your code compiles (*if you choose to write code that way)
Rust has some great and useful web frameworks that are a joy to use, once you understand what is going on. For example, in Axum, they use traits cleverly to allow you to use dependency injection the same way that fastapi uses it. But at least when I started using it, that wasn’t an insight made bluntly clear with tutorials as good as tiangolo’s. Instead, I had to piece it together via examples in the axum repo as well as from watching a youtube video.
Don’t fear, Rust can be as simple and clever as any other language. And the Rust core OSS developer community has spent at least the last ten minor versions improving dev ex considerably.
FWIW I prefer the pile of libraries. Big frameworks are good for scrappy startups trying to push their product out asap, but in most of situations, I’d like a lower abstraction system to build on.
What makes Rails (and similar frameworks in other languages) great is the large number of companies using it in production and having many people contribute to it. It therefore is very feature complete and works for a lot of use cases and edge cases. For everything that Rails does not do out of the box, there is a great ecosystem of libraries.
Rust has no such framework. There is often just one person pulling the whole project and the number of active contributors is very small.
This carries some risks and might mean that you end up having to do a lot of plumbing yourself.
Least error-prone and JavaScript in one sentence, I’m not sure about that, to be honest. JavaScript alone without any types in a big project is a shot in the foot, let alone the quirks JavaScript has. Apps crash when a thrown error is unhandled, etc.
I would say JavaScript is easy, but it’s definitely not the type for a least error-prone app.
I think there's a scale/complexity thing to be considered.
If your web app is simple, then frameworks and "safe" languages are unnecessary.
At some stage though, that flips around. There's no way I'd choose to write, say, gmail or Trello in "plain javascript". The learning curve of a suitable framework for projects like that are well worth the eventual productivity, and the number of feet to shoot in your project will way exceed the number of feet added by the framework, and hopefully the framework will prevent way more foot shooting opportunities than it adds.
I consider myself a lazy developer: I like to write code that minimises the amount of code I'll need to write to incorporate new features in the future.
Laziness isn't necessarily a bad thing, depending on how it's implemented.
Prototype is easy and fast. Scales well to very large user base on a single node. Interactive client side without even writing JS.
I love rust, I really do, I use it for all kind of things. But for web app, the Erlang architecture is so well designed and mature you cannot compete.
Also we use rust and zig from Erlang with native modules for video processing and AI, the elixir/Erlang "skin" gives you immense flexibility and productivity with almost no performance hit.
for those folks suggesting php/laravel, give cakephp a try. I've used both extensively: years and large, complex projects. Cake is just much faster to work in. In the initial phase and the long run.
I think dhh said, great frameworks/libraries are extracted, not created from scratch. That would mean, someone building a (successful, money making) web application in Rust and building their own framework as they go, open sources that framework and then continues using it for their production applications.
I have not seen such a success story for any Rust web framework yet. Although I would love to see one (or more!)
- Regular Web / Services: IMHO, Go, Java, .NET are better candidates there
- IoT devices with Web or API interfaces: Rust is good there. Access to I/O resources etc.
- Extreme high-performance services: Something like a DNS-over-HTTP or wall street data brokers. But for that you need a VERY solid server (but most likely not a framwework).
The regular web case will not produce a framework (out of commercial success), it is much easier to opt for a traditional languages/frameworks and hire inexpensive developers for that. The extreme high-performance services will not produce the framework you want and the likelihood is very small because the number of companies doing that is very low. Leaves the IoT space, which, IMHO, has the best chances BUT will not be the one optimized for your big server machine scenario.
100%! I love Rust, but I will still use Python for backends because of Django. Rocket, Actix, Axum etc are more like Flask, but without Flask's integrations for the services. I don't understand why there are so many competing microframeworks; one of them should have IMO pivoted to a Django-like a while ago.
The whole "I want to do everything in the language I already know" is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
But surely "making silly things" in Rust counts as learning Rust?
I remember writing a 2.5D "Doom style" renderer thing that let you move around in a bunch of rooms/corridors in real time in MacPerl/Quickdraw back in the Mac OS9 and Perl4 days. Probably taught me more about Perl than I'd learn in several years doing it for a job.
Not everyone wants to be jack of all trades - master of none or have time, energy or capacity to waste their life in hamster wheel of constant relearning of the same thing.
> is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
If they’re dominating our field they can’t be terrible by definition.
I'm a lazy developer and I love languages with an "if it compiles it works" feel. I'd much rather hack around in rust or typescript with half my brain switched off and a beer in hand and eventually get working software than hack around in javascript with half my brain switched off and a beer in hand and get more and more broken software until I eventually give up.
I don't think the dichotomy is between types and not-types - it's between Rust and other typed languages.
Most people here appear to agree that types are useful, but some people are claiming that a language that forces you to do memory management is somehow as ergonomic/lazy as others that manage memory for you (with equivalently good type systems - TypeScript, ~Python).
TypeScript sure, but Rust? Half your brain switched off? There is a middle ground between unfettered madness and the Rust compiler's strict regime. Maybe try Elm.
Yes, really. I've found Rust to be the easiest language to use while cognitively impaired (i.e. drunk) because the compiler can maintain all of the invariants that my conscious mind would need to manually maintain in any other* language.
*: There are simpler FP languages that can offer a similar experience, but they come with their drawbacks: I don't think I'd want to set up OCaml on Windows under such a state
Larry Wall (the Perl guy) had "The three virtues of a great programmer", in which the "Laziness" virtue wasn't putting minima<l effort into _building_, instead it was about building stuff that created minimal effort for people to use. I can easily see a definition of a "lazy Rust developer" which is about writing things that work properly for everybody all the time. It's being lazy about minimizing the future effort you'll need to put in fixing bugs or answering questions about it, instead of the "throw together something that looks kinda like it meets the requirements" in the minimal amount of time/effort sort of lazy.
I am so glad I moved away from the web. I remember spending lots of time playing with different frameworks for Node.js and Java and PHP and Python, all with different tradeoffs, and all of them suck the fun out of programming out of me.
Yeah yeah I know <whatever> Framework is great and good for stability or something, but using a framework makes something that I enjoy (programming) feel more like filing out my taxes, just so I can end up with a mediocre CRUD application that more or less works for the project I am working on.
I have removed myself to from the web and programming almost instantly became more fun for me again.
That's interesting! I absolutely don't feel the need for a massive framework.
I think a good part of the devs community has been burned by some framework at some point and doesn't feel the need for web frameworks, hence why nobody bothered to make Rails for rust.
In a professional setting, all the services I interact with, have been implemented on top of express (node.js) or fast-api (python).
I know people working in ecommerce who rely heavily on django or woocommerce, but rust usage among them is pretty low.
Rust is also one language where there are very little junior people, so you'll see wire-it-yourself library more than frameworks. Eg. sqlx is imho the best compromise in the ORM vs query builder vs plain sql debate: you get typechecked plain sql.
I think axum is very well architected and type checked routes offer a great DX (except for the tower::Service compatibility - sure, it's nice to have compatibility but the resulting code is quite clunky), and I'd rather have smaller components I understand over a huge black box.
Whatever you do, don't make this an RFC in a Rust repo/something up for debate and discussion. 500+ messages and literally years later, no one will agree on a single thing. Just make the thing you want and if people don't like it, they can stick with Actix.
Go is stuck in the eighties and replies like this are a good demonstration why it's very difficult to engage in intelligent discussion with many from Go communities.
As someone who mainly specializes in .NET, I have had incomparably better time participating in Java and C++ ones because people there are usually able to acknowledge pros and cons of various platforms, how they evolved and where are their strengths and weaknesses.
The average level of understanding and ability to consider what is the dev flow and how the language of choice impacts it in Go ones seems to be just so much worse it's not even funny.
That is to say, goroutines are discount futures/tasks which force you into synchronizing the "yielding of result" manually either via a channel or a waitgroup and a collection, or similar. Not to mention they are also much more expensive than .NET Tasks. I have not measured the cost of Java's new green threads yet but assume they are going to be in the same ballpark of memory cost as Goroutines, but with drastically better steady state performance provided by OpenJDK HotSpot when it comes to regular application code.
And lastly - Go requires you writing heaps of boilerplate for simplest things, Go channels come with a lot of footguns and gotchas you have to learn, standard library has weird omissions, type system is static but weak and as the demands put onto Go continue to become more complex, as more and more developers are forced into it, the language becomes the kind of unreadable soup you accuse other languages of. Just look at range over funcs and iterators discussions recently. It's ugly and token-heavy. And you will see a lot of code like this if you browse random libraries on Github - it's unnecessarily bulky, in a way that is excusable for true system programming languages but not in Go which has even higher level of abstraction runtime than .NET.
The author is I think conflating laziness for joy. We don’t care to be lazy because that won’t do it. But we do want to have a language that we like to use. To look at, to play with, to understand and to rally behind.
There is no one web framework that will satisfy all criteria and all layers of what a web framework needs. Every so often we have to migrate as technology catches up and changes the ecosystem, like wasm did with Blazor.
I’d rather have a language that programming is a joy in. The laziness is a nice side benefit. I can adapt such a language to changing landscape any day. I know Ruby is such a language, and hence Rails adopts it’s joyful mentality. But is Rust a joy to program for? That I can’t say for sure.
It really doesn't, actix is already there. Recently built my startup code over the past couple years with Actix and it had literally everything we needed easily. We just need more documentation and reference code bases demonstrating how to do these things. Rust devs tend to be fairly advanced and seemingly don't write enough docs or shares.
>Routing/handlers
Actix has it.
>Templates
Minijinja or liquid-rust[1]
>Static file serving
actix-files[2]
>Logins
Actix with oidccore is fantastic and easy[3]
>Permissions
Actix FromRequest is literally perfect. We have perm levels (admin, owner) and per-route perms for more fine-grained control.[4]
> Database interface
Diesel with diesel_async for connection pooling has been flawless at scale.
> Admin tooling
We didn't do this, but it would be simple with a bin/load-data.rs file that runs via a docker start command or tmuxp pane.
> Hot reloading
Cargo watch is getting deprecated, but was great. Bacon and and Watchexec are fully qualified successors. CSS watch systems work with the templates already same way as they do for SPAs.
> Background tasks
Make a bin/worker.ts file which defines a single binary and then use redis or another queing sytem to communicate between the worker and core server. We loaded all of HN (40M docs) into a search index with this approach and it was easy.
> Monitoring/observability
There's a decent story here with structured logging. Zero to production in Rust has a good chapter on it (2020) [5]. Lots of progress has been made since and exposing prom metrics endpoint is straightforward [6]. Sentry support is also decent and they sponsor actix.
> Caching
Imo, the story with Redis + actix is fine. We do this with our auth middleware to reduce latency on that operation since it happens with every route and I think it's smooth with FromRequest.
> Emails and other notifications
What's wrong with SMTP? Plus, Keycloak will handle your password reset infra out of the box. SDKs here could be better, but the APIs are fine and not too bad to do with Reqwest yourself.
> Deployment tooling + CSS/JS bundling
Imo, both of these things are the same as with other languages. Rust could use more documentation, but I don't think there's anything making it particularly hard to use.
Her point is that she wants a batteries-included framework that comes with integrated choices for these out of the box, similar to Rails or Phoenix or Laravel, so that you can hit the ground running without spending the first few weeks of the project picking crates and gluing them together.
He’s looking for the Rust equivalent of ASP.NET Core and there’s nothing wrong with that.
Sure, some people like choices and tinkering, but in many settings it’s much more productive to have the choices curated for you.
“But what if you want a different X instead? It might be Y% better!” is the typical comment, which ignores that the integration itself provides enormous value. Discrete libraries may be best of breed individually, but may be a heap of garbage if they don’t fit together smoothly.
I love programming in ASP.NET 8 specifically because I never have to think about whether a templating system will play nice with authentication, injection, routing, or anything else.
If you want to make a silly, minimal effort hobby project simply don't use Rust. I'm gonna be honest I don't understand this entire genre of using extremely complex, highly optimized systems languages for tools that don't need them. Your flow chart should basically go like this:
"Do I need zero cost abstractions because I'm writing a computationally expensive very serious project?" If the answer is no use a garbage collected, runtime managed language.
I write my hobby projects because writing them is fun. I don't find writing Ruby, Python, Go, and a host of other so-called "more appropriate" languages fun.
If someone enjoys writing Rust, it's natural that they'll reach for it when they're looking to write something for fun. If the tools/libraries in that language exist to make writing a particular type of thing more fun or easier, then more the better.
I don’t know about that. I already knew a little Rust last month when I wanted to write a REST API server that would benefit from being deployable as a single executable. I probably spent a grand total of 2-3 hours researching which framework to use (actix-web for me), reading the code, and implementing the endpoints I needed. The end result ended up looking an awful lot like a Python Flask app. The actual code writing part of the project wasn’t any more complicated than using any other language might’ve been.
Learning Rust and learning web service programming at the same time would have a steep curve. If you already know the basics of Rust and have written web services before, writing a new one in Rust needn’t be stressful.
Yesod has most of the things on this wishlist (though it's Haskell, not Rust), and Yesod is generally awesome. I've been working with it for the past several years, and I look forward to the next several years with it.
“Slow” scripting languages worked in the 90s for the web and they work even better for now, plus you have more to choose from. The key is to shell out to other tools for heavy lifting, like a database. Multi process architectures are where Linux really shines.
Rust can fit in that picture, but it doesn’t need to be routing http.
I'm struggling to see a usecase for rust. If I want to do something as high level as a web app, GC is fine. If I want to do something at the systems level, Zig is much more at home there.
And development in rust is glacial. It's no one language featurep (not complaining about the borrow checker in particular), but the accumulative overhead of all of them acting in weird ways.
I will say the tooling is absolutely amazing, it's nice to span "app level" and "systems level" concerns in a single language. But it is a lot of language.
> I like to make silly things, and I also like to put in minimal effort for those silly things. I also like to make things in Rust…
I think this part is perhaps the silliest part of a very silly article. If you really like to put in a minimal effort then why on earth would you use Rust? If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the standard library for what you want to do. Or… use Django as you suggest?
Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?
I am a fan of Rust for systems programming, but so many people are using Rust for things that are nothing even remotely close to systems programming. So many projects you see being written (or rewritten) in Rust are projects where I just think 'wait, why can't this just have a GC'? And then you look at the code base, and it's all Arc<Mutex<RefCell>>s, and you can't help at marvel at this, since that's just GC, so what's the benefit of Rust here, exactly? (Don't @ me, ARC is GC.)
I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. People will brag about Rust's memory safety, and then you find out that they don't really know how lifetimes work, they just .clone() or Arc<Mutex<RefCell>> everything. Which is totally valid, but Rust is hardly necessary for that.
Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right.
> What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc.
I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation. Most of the time I bring this up, someone will suggest something like Swift or OCaml, but I think the part people miss is how even despite all of the complexity that comes with being a systems programming language, Rust really goes out of its way to try to be developer friendly despite that.
Yes, it's a meme that Rust programmers are zealous evangelists and want to rewrite the world in it (which is a bit of an exaggeration in terms of lumping all Rust enthusiasts into that group, but there's certainly an element of truth in it), but no one seems to talk about how _weird_ of an idea it is for a language notorious for having a terrible learning curve to be so popular with people perceived to be lacking real-world experience with the domain. How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? You might chalk some of it up to marketing, but I think people undervalue how much effort is put into the little details in Rust to try to make it more approachable, like error messages, standard library documentation, first-class support for all major platforms, and high-quality introductory materials (e.g. both the original and rewritten The Rust Programming Language book, Rust by Example, Rustlings). I don't think the same experience is there if you want to use Swift on Linux (where the support isn't nearly as strong, and a lot of the fancy new things coming out won't be available) or OCaml (from googling right now, a debate on reddit about "which stdlib should I use as a beginner" is on the first page of results when I search "ocaml std" or "ocaml stdlib").
One issue is that with GC, you lose prompt finalization of resources. A lot of code is written with this assumption in mind (e.g., file buffers are flushed if the last reference to the file is dropped—which is arguable incorrect due to the lack of error checking). And the borrow checker is the only thing that keeps everything from being mutable in place in Rust today. Having GC would open the possibility for alternatives to the borrow checker without compromising memory safety, but even Pony-style reference capabilities probably won't lead to a language where abstractions compose much more easily than in Rust today.
Maybe a language with a similar syntax, traits, monomorphization, and macros would still be interesting to many people? Would people prefer traits and macros over ad-hoc polymorphism (in the style of C++, which could subsume the macro use cases, too)?
> but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation
I dream about a Rust subset that's exactly that. What would be even better is if you could just use Rust packages directly with it. Since these libraries already do compile, correctness has been verified.
I gladly take the whole rust "package" because overall it's just so good, at least for opensource / hobby stuff. I wish there was an equivalent but with GC, to use for work.
> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?
I think Rust is especially popular with a demographic that was not previously exposed to lower level programming. Meaning younger programmers (because modern languages are higher level) and web centric programmers (because we're in a boom of web development).
This demographic had a hard time entering systems programming, because while fascinating, its exposure is lower (less jobs, less projects), and entry cost (learning C, or C++<11) is harder.
Rust made systems programming more accessible, and systems programming, just as anything related to how things work under the hood, is fascinating.
Now Rust is hard, as you noted, but not hard in the same sense than C is hard.
C is hard because low level stuff bites you immediately. You can't quite easily just use a random library in C if you don't understand your build system, linkage, etc. If you mess up in C, the compiler will not tell you either, you will have to debug your way out of it.
Rust is different, in the sense that its difficulty is limited to the compiler saying "nope". If you can get the compiler to say "yep", then you're 99.9% of the time safe. Now getting that compiler to say "yep" may take time, indeed, but all in all you most often can just get away with sprinkling unwraps, clones and Arcs all over the place until it works.
In that sense, I think Rusts popularity essentially lies in the fact that it is a way to do low level stuff with a barrier of entry limited to being stubborn in learning it.
Having learnt C in high school, and doing Z80 Assembly prior as a 12 year old kid, only with a bunch of books from the local library, it is kind of interesting to read about fear and hard regarding C.
Yes it does corrupt memory, there are some crashes, I usually bash C, nonetheless it seems we have too much "safety playground" regarding learning processes nowadays.
> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?
Popular languages don't really have evangelism or fans pushing it aggressively. Those are traits of smaller languages that don't interop well with other ecosystems so they need a lot of evangelism to build out the library ecosystem.
> there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector
What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin? Because those have great web frameworks that address all the features requested in the article and a whole lot more, there's good first class support for all major platforms, lots of documentation etc. These languages are also famously developer friendly with good error messages.
The problem is friction. To run a rust app you can just run it. To run a java app you need to install java first. This is no problem for backends running on servers, but client apps (like Minecraft) have to include their own JVMs to reach a wider audience, and this solution still introduces a bunch of complexity.
Scala 3? It has the vast Java ecosystem available and state of the art GCs (plural), with either a focus on throughput or low-latency. Also, it can exclude the null value from the type system, marking it explicitly with a union type.
I think all NVM langs claim interoperability with Java ecosystem. The situation on the ground is never as nice as sold in my XP.
Scala is a great example where I've seen the "best" option being rewrapped libs with scala calls and types rather than a native solution and the dev XP just isn't as good overall.
You can hardly get higher quality code than what is generally available in Java, especially with their stability. Wrapping it to use the language conventions seems like a pretty solid choice to me.
The dev xp, I sorta agree on, but it has improved a lot.
Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless.
It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one?
I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.
I used to think that it was more likely that Rust would "expand upward" to provide the higher level syntax that people want in a language like I describe above, but it does seem like the language development has vastly slowed down in terms of big new features. I don't necessarily think this is a bad thing; plenty of people didn't like how much churn there was in the first several years after Rust 1.0 came out. I personally didn't mind since I never ran into any significant breakage in what I worked on, but I definitely noticed a change in how open companies seemed to be to use Rust in any capacity coinciding with Rust's releases growing smaller on average; I think "frequency of major language features" is often used as a proxy for "language maturity".
At this point, I think a new language is more likely to provide this niche than Rust, and I also don't think that has to be a bad thing. Having Rust scoped more to lower-level programming where you're more worried about things like minimizing heap usage and avoiding copying strings or whatever rather than trying to be all things to all users might end up with a better experience in the long run.
> that are nothing even remotely close to systems programming
This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably.
Sure, rust is primarily a language aimed at systems programming. But it also is so much more (and also a cult).
* Its type system is excellent. Especially the lack of a "null". Even if, like me, you're fine with a GC, the type system alone is worth dealing with this insistent borrow-checker.
* Its multithreading is stellar. The borrow checker helps a lot in making it such.
* Its mutable/immutable model is highly practical. It's what makes the threading stellar and the type system more useful than in any other language I worked with.
* Its "oop" model is uncomfortable at first (coming from Ruby and Java) but forcing the "composition over inheritance" by not having inheritance is probably the best thing that can happen to "OOP". Every solution where I used inheritance, I shouldn't have.
* Its culture of "making the good way the easy way", being opinionated, and a community that adheres to this, is worth dealing with a thousand borrow-checker WTFs. cargo fmt, clippy, etc.
* Its build system that generates binaries that can just be "plopped" onto a server, "chmod +x" -ed, and ran is unprecedented.
I come from Ruby, Java, Javascript (typescript). I do a lot of Python, maintain some go services, have decades of PHP under the belt and occasionally dabble in some C and even C++. I can find my way around in a C# codebase and Objective-C.
All have their strengths and weaknesses. Their place and use-cases.
But rust, for me, is the only "ecosystem" that ticks all checkboxes in nearly all situations. It has downsides, and I consider the borrow-checker to be one of them in a lot of my use-cases, but it's something I'm willing to deal with gladly, because rust's other benefits.
a few months ago there was an article linked here on HN (iirc about rust game dev) that argued that while rust is great, it's virtue of being mostly correct every time can also be a weakness.
the argument was that in early dev and prototyping phases you don't want to write good, clean, correct code but move fast and break things while not caring about edge cases - and this, the author argued - is relatively hard in rust.
I agree with you on the borrow checker... Part if me wants a simplified(distilled?) Rust ... All of the good stuff, but remove the bad... Not sure how that looks but it is something I know I want
A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone!
My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.
I much prefer rust to go for many reasons, but IME go gets this part much better. Darwin / Linux cross compilation, armv7, FreeBSD, oh sorry you don't have a linker for that toolchain, wait where are those OpenSSL headers... lots of cross-compilation targets I've done in minutes with go that scp and run right away that end up being days / weeks of adventures to cross compile in rust, in spite of me knowing rust much better than go at this point.
I'm just really leery of using languages that don't have a clear separation between immutable and mutable state. Having it in Rust catches so many bugs.
I also want to write code in languages where you don't have to engage in bad software engineering practices to get optimal performance. That usually means aggressive inlining, something that Rust excels at.
edit: the other thing I wanted to mention is that rust's features cause dependencies to be pretty high quality.
If I pass in a slice of something, I'm no longer worried that something ten layers down will change it.
Error handling is explicit and panics are rare, so I'm not worried that dependencies will start throwing exceptions after an update. (This is the reason functions should indicate errors in type signatures—a better ecosystem.)
ADTs mean dependencies represent fewer illegal states internally.
It's just really nice to write code where the bugs are a couple levels up from bullshit like this.
I think this is a legit sort of reasoning, but in an interesting way it's something where OCaml could fill the gap. It has its ergonomics issues, but I think the issues are basically the same/worse in Rust (except I guess Rust's macro system is better).
I say this as a Rust enjoyer, but I take the pain because I _really_ want what I'm working on to be fast.
I like OCaml a lot as a language, but the tooling is very, very poor by modern standards. Poor enough that I think it’s a total blocker on wider adoption.
OCaml is definitely something I'd consider using if I didn't already live and breathe Rust :)
I use Rust often for things that aren't possible in other languages, so I also use it for things that are possible in other languages. (Though I used Python for a production and an art project recently -- with uv it's quite nice.)
I think RC and clone are the way people begin to use Rust. While lots of criticism are against this usage for not idiomatic, it should be acceptable. Coming from Python, nodejs or Ruby, even RC and clone or stack based variables is still a magnitude faster than those languages. When it's about absolute control for performance you can drop down a notch to the borrow checker behavior.
That's an interesting perspective I'd not considered before. Maybe there are different "registers" of Rust, in the same sense that linguists talk about registers in human languages, where you use your language differently for different purposes.
And thus, maybe if you're writing something that doesn't need to be screamingly fast absolutely all the time there's a register of Rust where putting lots of things in Rc<Box<T>> is completely acceptable, in much the same way that you might use a lot of impolite words around your friends but you don't in front of your employer.
Having written some Rust and a lot of Ruby, I find Kotlin to be a really nice "typed Ruby". Just like Ruby, Kotlin is an OO language in the core that is really friendly to FP. It's terse (not as terse as Ruby, as there are types to specify); but MUCH terser that Java.
Don’t know if you intended this joke, but some time before Rust 1.0, @ was the sigil for garbage collection types (@T, like &T these days). Which I think was just reference counting, without even a cycle collector, because was shown to be undesirable before it could be improved.
> I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story.
F#is not C like and it's tooling and packaging is not as good as rust. Last time I checked it had multiple packaging solutions like paket and nuget. The tooling on vscode can be buggy
Yes F# has come along for the ride with modern .NET and it's as cross-platform as C# is. However, a lot of the really shiny .NET stuff is tooled up mostly for C# users, so it can be a challenge if you wanted to do something like a .NET MAUI (cross-platform GUI library) application in F# because the tooling and the content out there to teach you about it assumes C#.
F# can usually handle C# things - they put a lot of work into ensuring interop with new C# features - but the languages are from different paradigms so it is sometimes a bit awkward despite F#'s comprehensive OO support.
Personally I struggle a bit with F# because it doesn't have typeclasses, and a language that looks that much like Haskell but doesn't have typeclasses just feels weird to me.
Although it might get them... C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed), so F# could presumably piggyback on that if they wanted.
> C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed)
> - Phoenix on Elixir! Yes, it's not quite so blazing fast
As someone running a fairly cpu heavy SAAS application for users who literally dog pile our whatsapp support forums if it goes down for even a second, Phoenix is pretty damn fast in production. I won't claim its as fast as rust but it will run circles around ruby or python and for IO bound tasks, competes perfectly fine with go. Its never been a bottleneck (database is another story)
After reading endless insufferable comments on HN a la “this should have been written in Rust” I realized that there is a very strong possibility that the people making those comments do not know another language. We saw this with JavaScript a decade ago. Before that it was Ruby.
I would say it shines when you have systems constraints, for example embedded & robotics work well with Rust. You cannot have a GC (either you don't have a heap or you cannot tolerate a GC pause resp.) but you still have the benefits of a good functional programming language to write your algorithms in.
The benefits are less obvious if you have less of those constraints: go is way way simpler to write large codebases for cloud applications in and still provide an excellent concurrency support. Python is way better for experimenting.
I agree the type system is the best feature of Rust but neither Ruby or Elixir have the level of type safety and type expressiveness of Rust.
I'd recommend Haskell as an alternative, but Rust "fixes" plenty of long term Haskell annoyances (especially around laziness by default, concurrency, unsafe std).
Being able to use Arc<Mutex<T>>, Rc<RefCell<T>> and other smart pointers gives you granularity and control over what happens to your memory. I think it's a nice feature to have to mentally reason about your memory usage (incidentally a weak point in Haskell); even if it were on-par with a GC implementation-wise, why use a GC over this?
I like to have control over my code (and I'm probably one of the few who think monad transformers in haskell were a good feature - despite their clunkiness) and I'd pick explicit code over "magic garbage collection in the background" any day. This is not to say I like verbosity for verbosity's sake (eg. think React Redux in JS vs the implementation of the same idea in Elm) but in some cases I think it's justified and it brings extra value.
If Rust had no borrowing at all, just Rc<> everywhere I'd lose maybe 5% interest in it, maybe less. Value orientation and Traits system, close to bare metal speed and stellar stdlib are what's most interesting for me.
You gave a long list of benefits of Rust - which should have answered your own question - and then suggested people use an ecosystem with almost none of those benefits.
Let's just say different people have different opinions on this one. Personally, I find Go to be a big regression in language design given modern PLT research, and wouldn't use it unless forced (e.g. terraform providers). Other people have other opinions: a friend I respect a lot has great success in the Go community.
I'm telling you that because if, as a Go enjoyer, you're baffled by the writings of a Rust enjoyer, it's very likely the result of different perspectives rather than silliness. And if your conclusion is "just use go", you're probably the one being silly.
This is definetly something the article should have drilled down on. Why Rust? I'm sure everyone's tired of hearing why rust is an excellent alternative to c/c++ for new projects, but as an alternative against Python it gets muddier. Rust has a clear advantage in performance and memory footprint and a much better multithreading story, but those are things that aren't high priorities for 95% of web development.
That basically leaves you with Rust's type system. Rust's type system is pretty great, and if we pretend we can't hear the Haskell developers it's one of the best type systems out there. That might seem to get in the way of quick prototyping, but on the other hand it would mesh really well with a framework like Django. One of the great things of Django was that you define your data schema, and Django takes care of both the database and a passable admin area. I'm sure you could greatly expand on that principle, with data types driving a lot of behavior and conveniences that the framework just handles for you.
Maybe a bit like .NET, but without the enterprisy coat of paint and without putting dependency injection everywhere.
The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result<T, E> where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps.
Do they really have better economics? (EDIT: ergonomics!)
Last time I looked into OCaml, I struggled to find a way to interact with the database in a type-safe way, I never figured out which standard library I was meant to install, I was being encouraged to use 2-3 different project management tools (Dune + Esy + OPAM), and I gave up on writing tests. But at least there's a garbage collector!
I realise these are all problems that I'll wrap my head around over time, and eventually they'll seem completely trivial to me, but the introductory documentation on getting started as a professional (and not as a first-year student doing a French-language compsci degree, which is what most of the documentation assumes), is pretty dire.
Meanwhile, much as I'm sure I overuse `.clone()` and `[A]Rc<_>`, the ownership model of Rust is deeply useful. It's something I often find myself missing in Javascript - not necessarily because I want to produce the most performant code, but because it's useful to understand the lifetimes of the objects I'm keeping around. Am I accidentally storing a reference to something in a closure that I forgot about? When this object gets deleted, have I checked that it's the last possible reference to this object? Etc.
Like, I don't think everyone needs to learn Rust. It's a great language, but there's lots of other great languages out there, depending on your personal and business contexts. But I think this idea that Rust can and should only be a low-level language feels absurd to me. It is a fairly ergonomic language with a fantastic ecosystem, a powerful type system, and an ownership model that will be useful even if you do try and opt partly out of it with GC-like wrapper types.
Thanks for pointing the typo out! I've fixed the comment.
In fairness, I think a lot of this comes down to familiarity. I'm fairly familiar with `.clone()` and Arcs at this point, so they don't really change much in terms of ergonomics. Usually their usage is fairly obvious, and quite often my editor literally does magically type the `.clone()` calls through LSP fix commands. It's the same as, say, OCaml's insistence that recursion is better for complex loops than, say, `while` — it's not necessarily wrong, but if you're unfamiliar with the idea, it's going to feel weird.
More important to me is the ergonomics of the broader ecosystem, and that's something that Rust has done well, that other languages just don't seem to be interested in at all. Things like integrating testing into the standard workflow; working hard on getting the stdlib in good condition; having an excellent ecosystem of well-documented, usable libraries; or designing error messages and lints with a focus on getting people to understand how the language works and not just what they've done wrong this time. I've really missed that stuff whenever I've tried MLs. You mention, for example, REPLs, but a unit test is basically a saved REPL session that you can repeat every time you make a change.
I'm not trying to convince anyone that Rust is the best language in the world or something. I really like it, but I find it helpful to think in terms of object ownership even in non-Rust languages, and I can understand why for other people that sort of approach is unhelpful. But I would love to see other languages embrace its ergonomics more, or new languages created with that as their focus.
A unit test has nothing to do with a REPL, a proper REPL provides something similar to jupiter notebooks in feel, alongside debugging and hot code reload experience.
Maybe we have different understandings of REPLs. For me, a REPL is a tool that I can use to try out some portion of my code, see how it responds to various inputs, see how it handles certain cases, and explore the internals of it via debugging tools.
But... that's what I do in a unit test anyway. A unit test is essentially a REPL session that I've frozen in time, can replay whenever I want, can debug, can trigger a fresh run whenever changes occur (which isn't quite hot reloading, but often a darn sight more useful), and can keep track of and share with my team. Which means I'm not just able to explore things on my own, but I can see the explorations that other people have made with their code.
Typing in modern days is effectively moving the task of debugging to compile/ide annotations process instead of testing for correctness.
Albeit it makes the process easier compared to a really shittly written code without strict typing, but against good codebases, it takes the same amount of time.
1. refactoring are in my experience still much faster (and reliable doable) with rust compared to e.g. Js/Python even in presence of a lot of tests. This is a bit less of an point with Java/TS/C# etc. through I had some very bad (and also some good) experiences with refactoring in TS. And to be clear I don't just mean pure refactoring but any larger changes affecting many places in code which might be needed to idk. impl. some feature.
2. especially with Js,Py and similar there are way to many edge cases you can have to test for all of them. Sure most times this mainly matters when writing libraries but on larger projects does apply too. Stupid stuff like you expecting a `list[int]` and someone (externally i.e. outside of your tests) passes a `dict[int, int]` and that happens to work as you current impl. is only linearly iterating it as if it's a `Iterable[int]` but then you change the impl to require a `Sequence[int]` as you access it by index in some corner case and now you customer has really strange subtle bugs. Can't be caught by your tests as the problem is the customer but still breaks the customer which is always bad and can't happen with rust. Sure also won't happen if everyone uses type annotations and mypy correctly and strictly. Through you can't rely on your customer using mypy, but you can rely on your customer running compiler checks (as it's the only way to build the code). Also while mypy is much much much better then pylance it is still prone to issues as both `cast` and `ignore[..]` are things you sometimes need but which easily can hide bugs if the code changes (cast doesn't pin the "from" type and ignore is scoped by place not by what is wrong)
If you think about correctness of a program, (i.e for any combination of given input , it changes a state in a determinstic way, including no state change for invalid input).
Strict typing is one way to accomplish this. The cpu does not give a shit about types. It cares about memory registers and locations. The unique code built into the compliers/transpilers is the thing that validates the correctness of the program in this case.
You can move that code into the testing suite without relying on the complier, and just do testing. Generally, given competent programming skills, this takes about the same amount of time as designing a well structured program - your tests are pretty much your design document for the thing itself.
This is a very anti-pragmatic way of looking at things in my opinion. The program is not a snapshot that exists in a vacuum. Most programs are going to grow over time and have things added and removed in various places by many people. They're going to have many interfaces and operations.
I think you're arguing that tests and types can both be used to check a particular case for correctness. Sure, this is true. However "moving type checking code into the test suite" means nothing—that would just be type checking.
When you make a code change, there's a difference in the kinds of feedback you get from your tests and your types. Tests usually cover business logic or stories—things that you want or don't want. Types ideally cover everything. They check every operation applied to a given piece of data. Of course types are rarely precise enough that they can catch every logic bug (e.g. strings with semantics not encoded in types, like email addresses).
This is just scratching the surface. You might just have to try out both to get a better sense of how they feel to work with.
Types [1] can only reason about categories of values, not about values. Tests and types do have an overlap, but the best option is both. Especially when combined with fuzzing, types can exclude large number of cases, making it even more efficient at covering a huge range of code paths.
[1] yeah, there are type systems like lean, coq that can do both, but the proving process is just currently not realistic for everyday applications
People who say copilot is useless.... I can only imagine they're in a dynamically typed language. Copilot + Rust makes boilerplate go fast. Strong typing is force multiplier for code gen.
I suspect that’s true. I never blindingly copy LLM generated code (that would be recklessly stupid), but I often only quick skim rust code generated this way, just to make sure the general task it is solving is what I asked for. If there is an unhandled edge case or or memory handling bug, rust will catch it.
It's also easier to implement a generate_code -> check_for_errors -> give_error_to_llm -> fix_code loop, because the errors that rust throws at you are most of the time really well thought out, and as succint as usefully possible. Comparing it with python, where you have to write custom parsing to trim it down and even then it's hit and miss on where the actual error lies, it's not even funny.
Rust does not skirt around the fundamentals. You can still handle errors however you want, you can still blast side effects all over the place, and you still have to uphold an arbitrary set of invariants specific to the task at hand. But the ecosystem as a whole is filled with things being done the right way because the language and its linters have always been quite helpful.
In any program there are errors you can handle and errors you can't, errors whose vary existence suggests something has gone horribly wrong. What else should you do in that situation but panic?
Interesting, great example. This kind of compile time safety can't be achieved without borrow checker, I guess? I'm now thinking hard if there's some type magic similar to the exhaustive checks for Typescript discriminated unions ("kind satisfies never" checks in switch statements).
I've been trying to come up with a similar pattern in TS many times but I think you cannot do this due to the lack of moves (bindings do alias, pass by reference).
But TS has so many dark magical patterns that I'm still hoping to be proven wrong.
Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over)
> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?
You can typically accomplish the same thing with enums/proc macros/traits of course—with the additional benefit that the type system is designed to be sound. Soundness is an explicit non-goal of TypeScript[1], so once you start layering on those kinds of overly-clever types, you soon reach a point where you're just lulling yourself into a false sense of security.
JS has concurrency (but not parallelism) despite being single-threaded, though.
If you ever put an await anywhere in your code, an arbitrary amount of random stuff might run between the time you await and the time the awaiting finishes.
Same applies to older mechanisms like callbacks and promises.
Race conditions are more rare there because as long as you aren't doing any IO, there is indeed no concurrency, so you can't e.g. get two threads trying to increment a single variable at the same time. They can still happen, though, especially if you accidentally do a partial change to an object, put it in an illegal state, and do IO before you finish that change.
> The vast majority of errors caused by shared mutable state are related to concurrency.
Concurrency, like async-await, you mean?
> TypeScript's type system contains features that Rust's does not have
Sure, and likewise Rust's type system contains features TypeScript's does not have—for example, just try expressing anything close to traits with TS's type-erased generics. Since the feature sets aren't the same, I suppose it's a matter of opinion which type system is preferable. But I know which one is more helpful for me for sure (especially considering the aforementioned soundness issues).
idk. many years ago through stuff like service workers, having shared memory through TypedArrays and similar.
But for the discussion more relevant is that shared mutability constraints do not only matter with threading, they matter with any form of concurrency (like JS async/await/promises and before that callbacks). And even without that you still have other single threaded and single tasked concurrency with the classic being changing a collection while iterating over it. So even without classical forms multi threaded concurrency still very helpful.
> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?
Rusts type system is mainly nominal typed while TS is mainly structural types so it's a bit hard to compare. Like if you nitpick then you could maybe argue that based on TS type system having "features rust types system doesn't have" it's more powerful (but you also could argue the other way around it depends on how you count them). But that would be misleading as it ignores that not only are they two fundamentally different approaches to typing it also ignores that some features are implemented through other means outside of the type system.
Practically having used both I can say that while TS has some things in the typing which are a bit cumbersome to do in rust when it comes to helping me having correct code in context of changes, especially larger changes, and especially libraries Rust still yields better results in my experience. Naturally assuming you don't abuse the TS in either case.
(and to technically answer the question, type unions == yes but different, intersection == no but also make little sense in rust, interfaces == yes but different, mapped types ~= depends on the aspect in some yes and better then TS in other no but implicitly through derives so worse then TS, conditional type ~= again handled through different features depending on usage either associated types or feature gates)
For what I hack on I often run into issues with the FFI performance between go/c# <-> c/c++. I’d rather not write C or C++ and Rust is one of the few languages that allows me to mess around with obscure libs at native performance and yet slap a web interface in front of it. cxx/bindgen is stellar in how fast they allow you to wrap libraries. These cases is where I would want like the simplest most opinionated web framework (like gin in Go).
Have you had real success with cxx? I've been trying to FFI a C++ lib (that I have limited control over) and it's been a real PITA. At this point I'm thinking of just making a pure-c interface for what I want on the C++ side and using C bindgen or just straight "extern C" because C++ FFI seems so painful.
FFI can be a source of performance issues in Go but not in C# (at least not to the same extent), unless you go out of your way to fight the happy path approach.
Sometimes you do have to rethink what you marshal vs what you just manage manually, but that’s what pointers are for (that can be turned into ref Ts for single values and into Span<T>s for slices/arrays/etc). The idea is that performance ceiling of FFI in .NET is as cheap as direct calls.
> but as an alternative against Python it gets muddier
For me, a clear advantage of rust (and also Go) over Python (or Ruby, or PHP) is not having to deal with runtimes.
With Python, the server needs all sorts of setup. Exactly the right version and configuration of the runtime. Pip. Or Pipenv. Or Pyenv. Or Conda. Or... and so on. Then it needs the libraries installed. Some of which must be built natively; so just packaging them in some CI is often not even possible. These native builds need lib-something-dev packages.
Then with an update of the underlying server, suddenly nothing works anymore.
Having a single binary that I can plop onto almost every linux box and which "just runs" regardless of the exact version of Ubuntu, cargo, rust-toolchain on the server/hosting machine is invaluable.
I'm so done with maintaining the fragile card-house that my Ruby-on-rails apps require, or that my python/flask services need, that my nodejs insists upon: with rust this is no longer needed.
And yes, docker/containerization is a solution to it. And yes, I know about the options to package up a python app with runtime included. But all that adds extra complexity. It merely makes it easier sometimes. Not simpler. And it inevitably makes troubleshooting, upgrading, etc even harder in some future.
Between Rust and Python there are a huge distance full of options with managed compiled languages, with AOT, JIT, or even both AOT and JIT as standard toolchain feature.
> and if we pretend we can't hear the Haskell developers it's one of the best type systems out there
Eh, Rust's type system isn't one of the best out there. It's lacking higher kinded types, etc. It's abilities in type level programming are frustratingly limited as well.
So it's advanced aside from from Haskell, OCaml, Idris, Scala, etc. Compare to OCaml's effect system for an advanced type system feature.
I 100% agree with you (I really miss HKTs), but I don't think the GP was using "best" to mean "most fully-featured".
And with that in mind, I do agree with the GP. Scala's type system, for example, is full of warts (well, Scala 2; I still haven't tried Scala 3). Rust's is cleaner and has fewer gotchas. I very rarely have to look up how to express something in Rust's type system, but I remember when I last did Scala, I often ran into weird type-system related errors that I just didn't understand and had to dig into to figure out. Some of that, sure, is likely due to Scala's type system having more features, but some of that is because it's just more complex. And I would usually rate something of lower complexity as better than something with higher complexity.
One of the major things about Scala 2 vs Scala 3 is the removal of many of the type system warts, in particular the type hierarchy now forms a lattice (if I'm getting my terminology right) rather than being rather adhoc in various places.
Lots of other small annoyances like the whole tuple situation have also been fixed.
EDIT: Plus: intersection types, sane macros/inlining, etc.
Unfortunately (for me), some of our projects still have to cross-compile to 2.x, but that's irrelevant for greenfield.
I'd give it a whirl -- it's a great improvement over Scala 2.x.
OCaml's effects are fairly new, and the Rust maintainers are also looking into effect systems. Who knows, we might also get HKTs and dependent types too in the future.
The author is clearly building things for the joy of it. If she gets the most joy from Rust, that's what she should use!
> See, if I want to make something for the web, I could use Django but I don't want that. I mean, Django is for building serious businesses, not for building silly non-commercial things!
Personally, I spent the first decade of my career switching between languages, believing that I should use the best tool for any given job. I spent the last ~five years doing mostly Rust, and I've learned that there's a level of mastery of a language you can never quite reach if you're always context-switching between them, especially a language as “deep” as Rust. This means I write things in Rust that Rust is not the best language for.
> If she gets the most joy from Rust, that's what she should use!
In the past I’d try to justify why I’d done something a certain way when another way would’ve been faster / better / cheaper, but I now realise that (at least for personal pursuits) an acceptable answer to “why?” is simply “because I wanted to”.
I feel like this is where I've personally landed with Rust. For many applications, it's at least good enough. It gets the job done. It looks and feels professional. Fit and finish are rarely a material concern. It rarely causes active problems (except where there isn't native coverage yet) and reduces or eliminated many more. And... well, I like it.
If I were putting together a web development team, would I recommend Rust? ...probably not. But that's because I'm putting together a team, not a playground. I'm paying people. I want to use common, well-supported, time-tested methods, unless steering away from that is truly needed to make the project successful. For web dev, that assuredly ain't Rust ("yet," some may add).
But for me? Just for me? I think it's a language I'll always enjoy. Within that line of thinking, I do feel there's room for better web dev tooling in Rust, though what's already there is probably enough to at least get started.
What kind of logic is this... The Rust language is quite rigorous, so web frameworks on it should also be equally laborious to work with? You have to roll your own authentication, you have to do your own routing, you have to do ad-hoc string manipulation instead of templates?...
The person likes writing in Rust, and would like to have a batteries-included web framework so they can tie together a web app quickly on the language they like to use... And I know they did not include https://rocket.rs/ in their 'existing ecosystem' section.
If you find the language rigorous, a web framework can't magically do away with that. It's genuinely illogical to believe so. There are plenty of web frameworks on Rust that are quite nice to use, but they are still Rust, with all its shortcomings in the same way Django is still Python with all its shortcomings.
What you're asking for is a DSL built on top of Rust for the purpose of creating web apps.
Show me where I asked for a framework that magically turns Rust into Ruby. The person has created a list of (high-level!) features that they need. None of them are 'no borrow checker'.
It'd be cool to have an out of the box "90% of what a website needs" toolkit that means writing your 10% custom code/secret-sauce in a modern code security obsessed language. Even if it is opinionated and "batteries included" in ways that make some things annoying.
I have built many projects that start with a WordPress install, to piggyback it's CMS, user management, and admin backend. I then inevitably end up making a choice between writing the project in php, or jumping through hoops to use the WP features (like auth and user accounts) in some other language that's more appropriate to the task at hand.
I mean, OP is working on such a "magical" web framework now. Time will tell how it turns out, and how usable and magical it ends up being. But at least the author isn't just whining; she's put her hands to the keyboard and is going to try to get it done.
> What you're asking for is a DSL built on top of Rust for the purpose of creating web apps.
I don't think that's necessary, personally, but if someone really wanted that, I'm sure they could come up with something that can be wrapped in a Rust macro invocation, that gets expanded to something smaller and faster (compiled-code-wise) than anything you can get in a Rails app.
For what it’s worth, for me, the time-to-first-attempt-to-run-it is faster in Python or Node than Rust (sometimes), but the time-to-first-working program is generally not, and by the time I have the Rust one working, it handles most of the corner cases with clear error messages. There are rarely unexpected cases not handled.
In other words, I find it faster to produce working stuff in Rust and much faster to produce quality stuff.
I don't as a rule web dev, so when I do I fall into the same category as the author: lowest effort to get something mostly right.
An explanation for "why bother try to have a low effort web server in Rust?" that I haven't seen mentioned: Once you're past the introductory phase of being familiar with Rust, if you don't need to pedantically handle every error case, it can be _very_ simple.
A low effort "doesn't have to be very flexible" web server would be terrific & easy to use in Rust.
Having said that, I'm not aware of the actual offerings available. Maybe there is one, other posts have suggestions.
Rust has benefits besides just memory safety and being efficient, it has great language design and a great toolchain. I chose (learning) rust over golang for quite simple projects with no performance requirements, out of sheer frustration with the toolchain/design of go, golang came off to me as "let's try to be special and make bizarre design decisions" which made it confusing to learn, not only that but I very quickly ran into pain points, whereas rust felt like everything just took the most logical straightforward path, and everything "just worked". It, to me, genuinely feels simpler, because things were what I expected. Kind of like apple simplifying their mouse to have no buttons and thinking it's very simple and easy, but then its just more complicated because it's so unusual, whereas everyone knows exactly how a normal mouse works. Just my view. I use typescript and needed a language to make a couple simple programs that could compile to a single executable, I'd love another option but don't want to use one that's not matured enough.
Strange - my experience was the opposite for Rust. The extreme plethora of String types, the way life time annotations made refactorings very difficult with very high cognitive overhead, no batteries included standard library, even error handling needing external support, string slicing panicking in Rust, async is a mess to debug - Go in contrast is a far more comfortable and consistent developer experience.
Basically the type system, most rust projects usually don’t come near “The advanced Reason there’s rust” and if they do need that there’re hardcore libraries for that, an ecosystem like that usually suffers from exhaustion cause no dev will want to maintain just a library and this is also the good apart of rust cause it lessens the barrier into the language as the ecosystem gets bigger
I use Rust primarily due to the type system. I could use OCaml of course but its a tooling nightmare compared to cargo. The fact that Rust is fast by default is just a plus.
Go look at job boards. The competition for Go, Rust, Django or whatever is Java+Spring. That's pretty much the industry standard unless you're in a Microsoft-only shop.
It’s disingenuous to leave out C# and F# out of this, given how much closer they are to Rust in language features and how much more “close to the metal” capabilities they offer while also having opinionated web frameworks, better CLI tooling and package management and being generally very productive languages.
From a technical point, you are absolutely correct. From a developer heavy business, it's a little more complicated.
If Rust had a good full-fledged web framework, it would enable more developers to justify why the business should use Rust. The culprit is that it would require a heavy education budget, but it would in turn enable the business to allow using Rust for other parts of the business which could benefit from Rust, e.g. middleware, small components, CLIs and systems programming in general.
Having a little bit of Python here, a little bit of Go there and a bit of Java elsewhere can become chaotic. There is a huge benefit for a small company to only have 1 programming language everyone agrees on using.
If your goal is to use just one language then why wouldn’t you pick JavaScript (likely Typescript), C# with Blazor, Go with templates or basically anything on the JVM? Rust is a bad general purpose language in my opinion, and its performance isn’t actually good enough compared to C# to really justify the added headaches. I say this as someone who really, really, doesn’t like C# by the way.
If your goal is easy web development, Django, Ruby on Rails and Laravel are frankly going be extremely hard to beat. I prefer Go with templates, but that’s still much worse than those options.
It could beat using C/C++ for using an embedded web server. I remember I tried that once and a lot of the work was using aho-corasick for working with paths, handling cookies and dealing with a bunch of nasty error handling all of which in theory would be easier in rust.
My problem wasn't so much dealing with memory management, but trying to put an upper bound on memory usage and failing nicely when that upper bound is met. I generally don't like working with garbage-collected languages, or having to use some niche application-specific language when I can just use a general-purpose language instead.
Seems like a good enough reason to use it to me, but perhaps I’m just another cult member.
> we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++
I think rust is just safer period, regardless of your level of expertise or background. Or are you saying that every memory safety bug was written in by someone inexperienced?
Not to mention the concept of “sharing code.” See I may write garbage tier rust code that basically glues together a bunch of libraries, many of those libraries are written by programmers way better than me, and I can gain performance and safety from using their work. The performance difference between languages like Rust and JS is huge, even if I, tainted by my background in Java, write dogshit code.
> I think rust is just safer period, regardless of your level of expertise or background. Or are you saying that every memory safety bug was written in by someone inexperienced?
I think you're reading too much into that and creating conflict where there isn't any. GP just meant that they had a bunch of interpreted language OOP developers (probably Java or C# or something like that), and they wanted them to start writing code in an AOT-compiled language (yes, I know about Graal native image; not the point). And that teaching them Rust is probably going to result in safer code than if they were to teach them C or C++.
> GP just meant that they had a bunch of interpreted language OOP developers (probably Java or C# or something like that), and they wanted them to start writing code in an AOT-compiled language (yes, I know about Graal native image; not the point).
JIT vs. AOT is not the same as being an interpreted language. For most applications, running on top of the virtual machine is a good thing, I don't see JVM developers turning to different languages just to escape the JVM, outside of some niche projects.
Also, without claiming that experienced c/c++ developers never write memory safety bugs, I don't think it's at all controversial to say inexperienced c/c++ developers write a lot of them (and hopefully experienced ones write way fewer).
I was trying to out that wanting to take the easiest path was rather contradictory to working with Rust.
> I think rust is just safer period, regardless of your level of expertise or background.
Yes, I’m not sure how you think I was implying something different. We (specifically) adopted it because it was easier for our (specifically) developers who weren’t familiar with low level languages to work with compared to c/c++.
> many of those libraries are written by programmers way better than me
You shouldn’t sell yourself so short in my opinion.
> If you really like to put in a minimal effort then why on earth would you use Rust
Because it's a fun language and you really do get to avoid the borrow checker nowadays if you just use `Arc` and `Clone` all over the place. I'm the same as OP.
Also, I love the package ecosystem. I know it (rightfully) gets some of the flack that the JS ecosystem gets, but most of the time, I truly don't care. I enjoy C programming as well, but C not having a common packaging system / cargo equivalent has really hurt it a bit in my opinion.
I feel like my Rust code takes 3x as long to write as my Python code, but the gpt results for rust are about 10x better, because the tooling is a backstop against hallucinations.
I really like the Rust tooling and I like exhaustive pattern matching. Python post-dev debugging time is probably 10x vs Rust. That's why I choose Rust.
> Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?
Rust is great, high level language that's super convenient for implementing arbitrary algorithms on arbitrary huge, complex data structures safely and quickly. Value semantics is absolutely unique and useful. The system of traits and standard library using traits like Ord or Hash means that it's enough for your type to implement one of those and suddenly it can be a key in a HashMap or BTreeMap and can be a part of even larger and more complex data structure. Adding a web to that easily could be super useful.
As a Linux user I’ve had to deal with these kind of people who wouldn’t use something new unless it was made the same of what they’re currently using, all my life, they just are not able to get it
I wish the author success in their endeavor, but Rust is pretty far down the stack of languages I'd use to deliver a webserver.
I look at Rust for serving web-traffic and I see: dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), weak client library stories (if I'm writing a service layer for a db, etc.), high barrier to entry, thin overlap with the core Rust value proposition (correctness around memory access, performance).
That's not even addressing the "what happens when my entry-level dev has to write something that interops with a web framework written in Rust." My heart can't take those code reviews, I might as well just write that shit myself without a framework for all the pain that's going to cause.
Note: I don't write a ton of Rust, for reasons that are maybe kind of obvious. I reach for it whenever C seems correct, which is rare but not never (for me).
> dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang),
Rust supports golang style message-passing concurrency if you want it[1]. I'd argue Rust mpsc channels are actually more powerful than Golang's and add richness to message-passing concurrency modeling.
Yeah, I don't get the hate here. Rust's channels are just as powerful as Go's, and there are even implementations of them in the futures crate that implement the Future trait, so you can await on them and effectively get the same behavior as "blocking" on a channel in a goroutine, without having a bunch of blocking native threads.
Wait, what, you think we need another web framework?
.....buuuut, if you spend more than 5 second actually reading the article...
> This doesn't exist right now, and I'm not sure if anyone else is working on it. All paths seem to lead me toward "whoops I guess I'm building a web framework." I hope someone else builds one, too, so we can have multiple options.
...
> My toolkit is called nicole's web toolkit, or newt. It's available in a public repository, but it's really not usable (the latest changes aren't even pushed yet). It's not even usable for me yet—this isn't a launch post, more shipping my design doc
Is where you can find the code, for what they're trying to make, to fill this gap.
Sure. Not a web framework. An all in one opinionated good out of the box defaults like rails.
Yes, there's no django/rails for rust.
Or go. Or clojure.
In fact, a lot of people have tried to make all-in-one frameworks, but usually the way the wind blows is that doing something specific is easy, but doing something flexible and generic is hard, a lot of work, and unless you're being paid to do it, it's a loveless job that eventually you get sick of and abandon.
I feel like if you're really going to go and write a rails clone, you need to spend a little bit of time digging into some of the other failed attempts and reasons they failed (eg. 1, 2, 3) first.
The landscape is littered with aborted rails clones.
It's perhaps... fun, but ultimately futile and naive, to think you can be 'the one that makes it' when so many others have failed, if you don't take the time to understand why so very very veryVERY many attempts to do this in many languages has failed.
(NB. Not to pick on clojure; I could have picked a bunch of go examples instead, but I guess the clojure failures have been particularly visible to me since I use clojure, and it's a place where, like rust, currently there are a lot of 'bits and pieces you can assemble yourself' and it feels like, surely just slapping them all together in one package can't be that hard...)
> I feel like if you're really going to go and write a rails clone, you need to spend a little bit of time digging into some of the other failed attempts and reasons they failed (eg. 1, 2, 3) first.
The idea of creating a "one man framework" like Rails in a systems programming language like Rust is a very tricky one. I don't think you can mimic the best productivity features of Rails without metaprogramming. Yes, you can do something like it, but the abstractions would leak all over the place making it uncomfortable for a Rust developer and not good enough for a Rails developer.
So strange reading all the comments here saying that Rust is not a language for "lazy developers".
I'm an incredibly lazy developer and Rust only makes me lazier. I can pretty much turn off the part of my brain that deals with "programming language" stuff and put all that energy towards the part of my brain that deals with "building stuff" whenever I write code in Rust, because I have a high level of confidence that the language itself isn't trying to make me shoot myself in the foot at every turn.
Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes. It doesn't get any lazier than that.
On the web framework topic: Rocket is the greatest "lazy developer" web framework I've ever used.
> I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice).
Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load.
My second paragraph is pointing out that "where I can open something like Notepad without an LSP or highlighting" is a strange qualifier. Why does it matter if you don't have semantic analysis in your editor? You certainly didn't explain it.
Again, not my experience at all. I simply don't think about any of that stuff when I write Rust, all my mental energy can safely go towards working on whatever I'm building.
If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.
> Again, not my experience at all. I simply don't think about any of that stuff when I write Rust
Your subjective perception is not reality. You have to think about it, or your programs will be incorrect. The mental load may be low to an experience Rust programmer, but it is there, and it's very intrusive to Rust beginners like myself.
> If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.
That's not relevant. Lack of external indicators of cognitive load does not mean that it's not happening.
In most Rust code I write, I never have to use an explicit lifetime marker other than ‘static (which is more of a global const thing). It’s really only something you have to worry about under certain conditions.
> Watch the literally hundreds of hours of me live coding in Rust on YouTube
Your definition of "lazy" seems quite different from the standard definition.
In my view, the average "incredibly lazy developer" of 2024 tries to have an LLM write most code for them (probably in JS/TS/Python), doesn't notice the subtle bugs introduced by said LLM, and ships straight to prod. If using an LLM fails, they go back to StackOverflow to look for an answer that they can copy-paste. When that fails they give up and ask a less lazy developer for help. At no point in this process did they read the documentation for the language/framework/etc they are using to accomplish their goals.
> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load.
As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. If you know that using global variable is often a bad idea, then you are, in some sense, worrying about lifetimes.
I first learned this in the mid/late 90s as my Perl4 cgi scripts started to grow
beyond about a screens worth of lines, and it really solidified into an almost unconscious background task as I wrote code once I started writing a lot of Perl5 apache mod_perl stuff a few years later.
These days, I find myself experiencing slight cognitive dissonance writing tiny Arduino sketches with a bunch of global vars declared right up the top.
> As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though.
Yes, to a much smaller extent. Rust's object lifetimes, for all the performance gains you get, add on a layer of additional cognitive and development overhead that is simply not present in memory-managed languages.
> Rust's object lifetimes, for all the performance gains you get
Lifetimes are not about performance gains. They're about correct behavior under concurrency, which you have even on JS with async-await.
Heck, let me correct that: even under programs without concurrency it's very easy introduce subtle bugs due to shared mutable state (something as simple as having a global mutable variable, you don't even need concurrency to mess that up, concurrency just introduces more issues like race conditions).
> cognitive and development overhead that is simply not present in memory-managed languages
No, the cognitive overhead is there, you're just ignoring it (and thus more likely to introduce subtle bugs).
If anything, Rust lowers the cognitive overhead by taking care of that for me statically at borrow check time.
Lifetimes are just types (literally). If you think lifetimes are cognitive overhead, so are regular types. Same argument could be used there since types are "cognitive and development overhead that is simply not present in dynamically typed languages". But I wouldn't write anything beyond a few thousand lines of code without them.
When I write Rust I spend more time thinking about types than about lifetimes.
Laziness with a long view: I probably won't have to rewrite it, and if I do, it will be easy. I can write code like that in Python or something, but I have to be on my best behavior to do so and that's not lazy.
Using notepad for code is just masochistism though
> You can't be that lazy, or you would use a language that doesn't force you to do memory management.
Eh, depending on what you're building you don't do much if any memory management in Rust. You just declare what you want and it's automatically released at the end of scope.
Yes I know the borrow checker. With experience it stops getting in the way while catching the occasional bug.
And no, building linked lists or recursive data structures are edge cases that you don't need to develop for most applications.
I'm the other way around I guess - a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python and JS at work. Part of it might be the terrible tooling story in each of those language ecosystems as well.
Last week I deployed a Ruby change where a missed comma between two strings in an array did not get picked up by any of the automated tooling or by 3 other team members who code reviewed my change, and ended up cutting 50+ sev2s at 10pm.
AWS folks can probably guess which internal tool I had to touch that requires Ruby.
> I feel a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python, and JS.
I resonate with you even with TypeScript, since it's just annotating types but not the true value under the variable. You would have to go to a greater extent to make sure that everything from outside (library code, parsing HTTP responses, database queries, etc.) conforms to your annotated types. Even in the same project code created by other people, I often doubt the validity of the types, asking myself questions like: Should I validate this? What if this has already been validated, thus making mine a performance waste? Does this object contain extra sensitive information that could be leaked when used in a logger?
After having experience with Rust, working with TS feels like navigating a minefield where every refactor could detonate hidden bugs or behavior collectively accumulated by all the historic code and dependencies, small or large.
I haven't had this experience with TypeScript. In the projects I've worked with, we turn on strict mode and heavily discourage using `any`. I generally feel pretty confident that the type annotations match the runtime values.
> Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes.
> anxiety when I'm forced to touch fragile bits written in Ruby
Wild, because the first sentiment is exactly how I feel about Ruby.
A lot of commenters are really getting hung up on the author's use of 'lazy'.
When she says lazy, she just means that she'd like a web framework that takes care of the most common and obvious schleps that are needed to create a web framework, like routing and so on. Once you get those schleps out of the way, there's still tons of work that needs to be done. Nothing lazy about that.
I wrote my first web app in Pascal as a CGI because that was what I knew. That app turned out to become the most popular Turkish social platform for the following 25 years.
I coded that app in 3 hours. It was very crude as you can imagine. But, it did its job. If I had to start with a “better” platform that I didn’t know, I could have spent days or weeks to learn and may not have released anything in the end because I got bored.
Don’t discount a language for a certain type of application because you think it’d be harder to work with than something else. Familiarity goes a long way.
1. Lots of dead ends. Fetch cache limit for example. Cant replicate prod page caching behaviour in dev. Etc. Many issues with 100 thumbs get abandoned.
2. NodeJS. Not everyone likes it.
3. It is slow. Yes it is! Try to get good web metrics with Next I dare you!
4. Premature release of App Router. Will they do something like that again.
React, like Haskell creates new problems you need sophisticated solutions for.
CDN is for content. Useless for say a Google search type problem. So I call an API endpoint for data in my component. But what if I get rendered 600 times? Well luckily I have memoized the call! As long as it was under 2Mb that is.
I appreciate that you’re getting to the crux of the matter instead of downvoting.
In our experience elevating the web metrics in Next.js takes the same expertise as doing it in any other framework. Our experience with Vertx and Microsoft’s dotnet web frameworks have been good, but Next.js got us to a fast, featureful, performant website sooner and with more flexibility around requirements. I won’t pass judgement on rust frameworks I haven’t used, but it’s just to say that in an honest accounting, a naked backend framework is less than half the product when you’re talking about web applications actually worth making with original ideas. Unless you work at Google.
I know TypeScript is available but not everyone can be convinced to adopt JS. I was part of that group until recently as I have been using strongly-typed language all my life.
The npm dependency ecosystem is extremely tangled. I work with node frequently, but there's plenty of opportunities for bad actors to introduce abuse and I'm wondering when the other shoe will drop.
I am wondering why there is resistance to adopt GraphQL and a React-like front-end. Essentially, you no longer have routing/templating/web-server/etc... and you get lots of things handled for you (like authorization). You pretty much remove the web framework concept and just work directly on your application functionalities. With stitching, you have a gateway that add up various graphql gateways. So you could mix and match rust with other microservices or whatever.
I don't see myself doing it any other way these days.
I was surprised not to see Rocket (https://rocket.rs/) mentioned among the frameworks the author listed; I haven’t used it myself because I _like_ the more unopinionated axum/actix-web, but as I understand it its goals are much more in the vein of what the author wants in a batteries-included framework and it’s been around for a while now.
While Rocket was one of the earliest Rust frameworks that really pushed for good UX (via proc-macros), I think it has largely fallen out of favor in many parts of the community. For a very long time it required nightly Rust versions to build, which is a no-go for many people wanting to use a framework in a production setting. Also for a period of ~2 years it was stuck in a 0.5.0 release candidate limbo where the latest stable released version was significantly lagging behind the rest of Rust web frameworks (requiring nightly; no async support yet).
Maybe it will be better now after the 0.5 hump, but in general the development history of Rocket is something that dissuades me from using it when compared to e.g. Axum.
When I asked them about that 2 year limbo, they said the release candidate was feature complete, and simply had incomplete documentation (also some plans for a new management structure).
So, it wasn't actually lagging, it had that async for quite some time... But yeah, being in a "release candidate" did scare people off.
I 100% agree. I'm just a casual multi-language programmer these days, but I'm familiar with Rocket.
There is one: Poem[1]
The author mentions flask but looking at the "What we need section", I don't think flask covers those. I hate Djago with a passion but if those are the requirements, I think Django is the one that closely resembles what the author is describing. So Poem is not a good candidate either in that regard. Poem is all in all, something that closely resembles FastAPI, which is actually a complement. I've tried half a dozen rust web frameworks and they all come with a ton of boilerplate fiddling with the initial setup. Which is a problem if you want to get things done fast. In that regard, poem nails it. Yes, actix has a considerably better performance but unless you are aiming for sub-30 millisecond responses, then actix is not what you should be looking at to begin with. Also if you crave a Pydantic, there is a crate that sort of does that for you: https://crates.io/crates/poem-openapi
[1] https://github.com/poem-web/poem
Not just Django, probably Rails, ASP .NET Core, and many other full-feature, batteries included web frameworks. Emphasis on framework.
This article makes several different points that would ideally each be tackled on their own.
You don't need a router when you have pattern matching (just split the url and match on static and dynamic vars however you need)
Auth is typically DIY in any language, or SaaS like Firebase/Auth0. It's not a language or framework problem, necessarily
CSS/JS tooling makes no sense for many frontend Rust frameworks like Dominator, which is in Rust (not JS) and has its own approach to styling that works for it (e.g. attaching styles to signals, so they change on the fly)
I get what the author is saying - in fact I've been around the block a couple times solving all the different points in the article and it is painful. For example, see https://github.com/dakom/dominator-workers-fluent-auth which does a lot of the stuff here on the Cloudflare workers framework (also adds another wishlist item - localization with Fluent)
A "batteries included" full framework that does _everything_ is nice to have, but many real-world projects will want to replace those opinionated decisions and go the DIY route anyway. Rust is more than mature enough, even on the frontend web, to tackle all of that - if you know where to look (wasm-bindgen, etc.)
Doing my web stuff in Rust was fine but concurrency was a pain. A crate that abstracts web workers with transferrable types would help. After that you have to pick a component library of which there are few, and all are experimental. Making pretty, performant things is hard. Switching compontent libraries isn't easy. The backend stuff is a breeze, I think Rust is doing fine there.
I'm switching to Flutter for my UX needs. There's flutter-rust-bridge that binds Rust code concurrently without any headaches in the client, and I can deploy to the web, android, Linux, etc. with ease. Looks p. good out of the box. Got GRPC working quickly, am happy.
Using Rust in the client is nice because I have a single workspace that contains all of my business logic. Backend changes will cause errors in the client code if changes are necessary. The codebase is easy to refactor and trust. Dart ain't half bad.
I stayed away from Flutter at first because it doesn't respect the DOM etc but at this point I'm willing to sell my soul to the devil for how easy it is to make a great UX that deploys anywhere.
I don't love relying on something Google made, though. Feels a little like building a foundation on sand.
Take F# for a spin. It offers nearly all of the type system tomfoolery one craves and all the tooling and nice-to-haves one wants. The big drag is that the async story and memory management aren't as big as a time vampire as Rust, so you do run the risk of actually solving business needs. I am sure some part of dealing with Microsoft can fill that void, though.
I've been on the fence w.r.t giving it a try. How does it compare to Ocaml and haskell?
Possible unpopular opinion: Rust is a systems language, doing "web work" in Rust is a waste of effort as there are much better languages and ecosystems for that.
I do almost completely agree. But I just want to point out that the intersection between system programming and web programming is not empty.
Neither is the intersection between embedded programming and web programming.
But either way, if something like Django, .Net, or go is an option, Rust is probably a bad idea.
It's an investment in energy efficiency
The advantages of a language like Rust where most interactions are blocked on either user input or network IO are fairly limited. Rust shines when things are CPU or memory bound primarily. Web applications are mostly IO bound. Which is why people have been getting away with fairly poorly optimized interpreted languages for decades. Even when computers were a lot slower than they are today, this worked fairly well.
IDK I use C/C++ all the time for web servers. It's lightweight and lets you pretty easily/quickly call C/C++ and low-level code and gives you a lot of control in terms of networking. You can pretty much "do anything" in a straightforward generic way without having to learn some application specific language like PHP or through nginx/apache configuration files.
Having a rust alternative to something like libmicrohttpd would be nice and I would use it.
> You can pretty much "do anything" in a straightforward generic way without having to learn some application specific language like PHP or through nginx/apache configuration files
Not having to learn something like PHP? Do we not count learning C++? I would guess most people would agree learning PHP + Nginx is going to be a lot less complicated, which will be preferable for people just trying to build something. I'm not sure dropping down to such a low level is something most web developers will have to deal with.
I think that you find it easy speaks more to an already existing familiarity with C++, not that it would be a path of less resistance.
> Do we not count learning C++?
No, because they presumably already know it. They wouldn't be using it otherwise.
Counter-point: developing web services in Rust is just as easy as doing it in Go or Java, yet you now have an excellent type system (sum types!), an excellent package manager, and extremely good performance.
You can do dependency injection in Rust to share connection pools just like you would in Java, and it's super simple to write threaded background tasks.
Google gave a talk recently that said they measured Rust developers as no less efficient or productive than Go developers [1].
It's a fantastic language and you shouldn't ever limit yourself to systems programming with Rust. It can do so much more than that.
[1] https://www.ardanlabs.com/news/2024/rust-at-google/
The developers they measured, were they using the languages for the exact same tasks?
Otherwise it's just stating that they assign the languages to categories of problems they are equally efficient in.
https://www.youtube.com/watch?v=QrrH2lcl9ew
> "We have at this point rewritten a large number of systems [..] have some very concrete things that we can say"
> "When we've rewritten systems from Go into Rust, we've found that it takes about the same sized team about the same amount time to build it. [...] no loss of productivity when moving from Go to Rust."
> "We do see some benefits [...] we see reduced memory usage in the services that we've moved from Go. [...] We see a decreased defect rate over time in those services that have been rewritten in Rust"
> "Within two months about a third of the folks were feeling as productive, within four months about 50%."
> "People do indeed feel as productive in Rust as they do in their original language. C++, Java, Python, Go."
> "One of the biggest latencies is code review time [...] How hard is it to review code in Rust? [...] A little over half said that Rust is easier to review. The most incredible question [...] The confidence that people have in the correctness of the Rust code that they're looking at. [...] 85% of people believe that their Rust code is more likely to be correct."
Anyone on JVM has already Kotlin or Scala for that.
Likewise on CLR with F#.
No mention of loco-rs? poem? rocket? There's already a lot of projects that aim for a batteries-included experience.
What sets these projects apart from frameworks like leptos is that there's a CLI guiding you. That's what I love about Symfony, and what I consider the 'lazy' part.
Python has Django, C# has ASP .NET Core, Ruby has Rails, and so on... If you want to really make Rust take off with web development, build up a full-feature solution.
Rocket is maybe the closest? But it's not as batteries included as any of the frameworks I've mentioned.
There is https://shuttle.rs. Not only a framework but a tool that can generate all the web boilerplate around it, sounds lazy enough for me!
If the post were C++ focused instead of Rust would it make the same, more or less sense?
A systems language with a high cognitive barrier to entry, compile times and less than a decade of wide adoption can’t reasonably be expected to compete with something like Rails in terms of approachability
I wouldn't mind a Rust based web framework that provides the same features as the base Servlet API. Everything else should be an optional library. When I look into it the rabbit hole goes too deep. It hasn't been immediately clear what the templating looks like. Usually they start talking about some "Reactive" framework, features I don't want and I lose interest. Afterwards, I realize that I'm already satisfied with my current web stack.
Jetty, HAProxy, JSTL, commons db connection pooling and Postgres.
It’s really not clear what you mean by “basic servlet API”, because the main rust web frameworks are pretty much just routing by default, with (largely opt-in) parsing and serialisation support.
It “hasn’t been clear what the templating looks” like because there isn’t any just as AFAIK servlets provide no templating.
just out of curiosity: why commons db connection pooling instead of hikari? i've only ever used the latter.
Basically, the author wants Spring Boot for Rust
Spring Boot, Django, Rails, Laravel, ASP, ... it's not unreasonable to expect Rust to have an equivalent to something that most popular languages have.
What make rust better than any language when the bottleneck is the network or the database?
Not every application or even web application bottlenecks at the network or database level.
Doesn't really answer the question. Most webapps are this way and people are still surprisingly unaware of this.
It is a refutation of the premise which invalidates this particular question as it was posed.
"Not every" is not the same as "none" and the discussion is about the majority, so I think your refutation is only of the absolute case and not of the original premise.
Rust would be overkill for most web applications.
The bottle neck depends on the amount of CPU resources you throw at something
For me, the type system and the performance without having to do any optimization. The complete lack of runtime errors when your code compiles (*if you choose to write code that way)
The bottleneck is mostly developer hours.
Rust has some great and useful web frameworks that are a joy to use, once you understand what is going on. For example, in Axum, they use traits cleverly to allow you to use dependency injection the same way that fastapi uses it. But at least when I started using it, that wasn’t an insight made bluntly clear with tutorials as good as tiangolo’s. Instead, I had to piece it together via examples in the axum repo as well as from watching a youtube video.
Don’t fear, Rust can be as simple and clever as any other language. And the Rust core OSS developer community has spent at least the last ten minor versions improving dev ex considerably.
>once you understand what is going on
I think this is the big issue. We as members of the Rust community should be doing more to explain all the patterns for webservers in particular.
Support is there, but it's non-obvious.
Curious which YouTube video you watched that helped learn Axum.
https://youtu.be/Wnb_n5YktO8?si=lCGrH36DvXATdyEs
I think I've seen this exact discussion in Clojure community.
Isn’t there a rust rails clone?
Yeah, it’s called loco https://loco.rs/
FWIW I prefer the pile of libraries. Big frameworks are good for scrappy startups trying to push their product out asap, but in most of situations, I’d like a lower abstraction system to build on.
Rails clones in modern languages don’t get wide adoption. I wrote about why I think that is: https://hermanradtke.com/why-your-rails-like-framework-is-no...
For what it's worth, Phoenix is quite rails like, as is the ash framework, and both are quietly popular
What makes Rails (and similar frameworks in other languages) great is the large number of companies using it in production and having many people contribute to it. It therefore is very feature complete and works for a lot of use cases and edge cases. For everything that Rails does not do out of the box, there is a great ecosystem of libraries. Rust has no such framework. There is often just one person pulling the whole project and the number of active contributors is very small. This carries some risks and might mean that you end up having to do a lot of plumbing yourself.
This needs to be higher up. Loco seems to be exactly what OP is looking for, yet it wasn’t mentioned in the article.
My first thoughts. Before writing the piece, maybe they should look into what already exists.
The http server in the std library is one of the things Go got right and improved it's adoption, rust needs something similar
Something like https://sinatrarb.com/ for rust would be cool.
Axum + minijinja is quite close to this I would say. Been using it for a little while and I am very happy so far.
Seconding the recommendation, it's really great when paired with HTMX on the frontend too.
It is always a good idea to write a library, not so for frameworks https://www.brandons.me/blog/libraries-not-frameworks
Please no. Frameworks are the breeding ground of accidental complexity.
Rust already has excellent libraries that are easy to use in many different stacks.
https://deno.com/
I guess I'm just "weird" for thinking the laziest and least error prone way to write a web app is in plain javascript?
Any framework is too much extra work to learn and going to eventually get you shot in the foot.
Least error-prone and JavaScript in one sentence, I’m not sure about that, to be honest. JavaScript alone without any types in a big project is a shot in the foot, let alone the quirks JavaScript has. Apps crash when a thrown error is unhandled, etc.
I would say JavaScript is easy, but it’s definitely not the type for a least error-prone app.
Slap TypeScript on it.
I think there's a scale/complexity thing to be considered.
If your web app is simple, then frameworks and "safe" languages are unnecessary.
At some stage though, that flips around. There's no way I'd choose to write, say, gmail or Trello in "plain javascript". The learning curve of a suitable framework for projects like that are well worth the eventual productivity, and the number of feet to shoot in your project will way exceed the number of feet added by the framework, and hopefully the framework will prevent way more foot shooting opportunities than it adds.
Servo is in Rust.
I want to make an app in Rust that hosts Servo in it with my business logic in maybe SciterJS - like electron but hopefully lighter?
Something, just a business software guy who wants something with more control than an webapp and not so heavy like electron.
Tauri?
https://tauri.app
Its pretty awesome and almost there. Actually, I'm sure if we could find the time it would be there. (We $DAYJOB)
Rust and ‘minimal effort’ have to business being in the same room.
panic: something something upper or lower boundary of that "'minimal" lifetime you tried to use
^^^^^^^^^^ expected lifetime<Ref<Rc<Arc<&mut str>>>>, found Ref<Cell<&mut<lifetime<mut str>>>>
I consider myself a lazy developer: I like to write code that minimises the amount of code I'll need to write to incorporate new features in the future.
Laziness isn't necessarily a bad thing, depending on how it's implemented.
Just use Phoenix and live view.
Prototype is easy and fast. Scales well to very large user base on a single node. Interactive client side without even writing JS.
I love rust, I really do, I use it for all kind of things. But for web app, the Erlang architecture is so well designed and mature you cannot compete.
Also we use rust and zig from Erlang with native modules for video processing and AI, the elixir/Erlang "skin" gives you immense flexibility and productivity with almost no performance hit.
No types in Elixir, I think a better comparison is actually Gleam, it is Rust-like in type system but is built on and interoperable with Erlang/OTP.
Both are exceedingly slow and memory-hungry. The average user of Rust might get shocked and never touch these again.
Now F# on the other hand…
for those folks suggesting php/laravel, give cakephp a try. I've used both extensively: years and large, complex projects. Cake is just much faster to work in. In the initial phase and the long run.
I think dhh said, great frameworks/libraries are extracted, not created from scratch. That would mean, someone building a (successful, money making) web application in Rust and building their own framework as they go, open sources that framework and then continues using it for their production applications.
I have not seen such a success story for any Rust web framework yet. Although I would love to see one (or more!)
IMHO, there are three scenarios:
- Regular Web / Services: IMHO, Go, Java, .NET are better candidates there
- IoT devices with Web or API interfaces: Rust is good there. Access to I/O resources etc.
- Extreme high-performance services: Something like a DNS-over-HTTP or wall street data brokers. But for that you need a VERY solid server (but most likely not a framwework).
The regular web case will not produce a framework (out of commercial success), it is much easier to opt for a traditional languages/frameworks and hire inexpensive developers for that. The extreme high-performance services will not produce the framework you want and the likelihood is very small because the number of companies doing that is very low. Leaves the IoT space, which, IMHO, has the best chances BUT will not be the one optimized for your big server machine scenario.
I'd rather see Crystal on Rails. Combines the elegance of Ruby with the performance of a compiled language. And of course: macro support.
Languages with automatic resource management are much better option for distributed computing scenarios that one with strong focus on affine types.
100%! I love Rust, but I will still use Python for backends because of Django. Rocket, Actix, Axum etc are more like Flask, but without Flask's integrations for the services. I don't understand why there are so many competing microframeworks; one of them should have IMO pivoted to a Django-like a while ago.
Loco.rs?
"Right tool for the right job," no?
Learn multiple languages.
The whole "I want to do everything in the language I already know" is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
But surely "making silly things" in Rust counts as learning Rust?
I remember writing a 2.5D "Doom style" renderer thing that let you move around in a bunch of rooms/corridors in real time in MacPerl/Quickdraw back in the Mac OS9 and Perl4 days. Probably taught me more about Perl than I'd learn in several years doing it for a job.
> Learn multiple languages
Not everyone wants to be jack of all trades - master of none or have time, energy or capacity to waste their life in hamster wheel of constant relearning of the same thing.
> is why the least interesting--and straight-up pretty terrible albeit very capable--languages are dominating our field.
If they’re dominating our field they can’t be terrible by definition.
Rust is not for lazy developers and there are other languages if you want to put minimal effort in building things.
I'm a lazy developer and I love languages with an "if it compiles it works" feel. I'd much rather hack around in rust or typescript with half my brain switched off and a beer in hand and eventually get working software than hack around in javascript with half my brain switched off and a beer in hand and get more and more broken software until I eventually give up.
Then just use Ocaml or F#. You are welcome.
For a person just curious about all three, how do the ecosystems compare?
I don't think the dichotomy is between types and not-types - it's between Rust and other typed languages.
Most people here appear to agree that types are useful, but some people are claiming that a language that forces you to do memory management is somehow as ergonomic/lazy as others that manage memory for you (with equivalently good type systems - TypeScript, ~Python).
TypeScript sure, but Rust? Half your brain switched off? There is a middle ground between unfettered madness and the Rust compiler's strict regime. Maybe try Elm.
Yes, really. I've found Rust to be the easiest language to use while cognitively impaired (i.e. drunk) because the compiler can maintain all of the invariants that my conscious mind would need to manually maintain in any other* language.
*: There are simpler FP languages that can offer a similar experience, but they come with their drawbacks: I don't think I'd want to set up OCaml on Windows under such a state
Larry Wall (the Perl guy) had "The three virtues of a great programmer", in which the "Laziness" virtue wasn't putting minima<l effort into _building_, instead it was about building stuff that created minimal effort for people to use. I can easily see a definition of a "lazy Rust developer" which is about writing things that work properly for everybody all the time. It's being lazy about minimizing the future effort you'll need to put in fixing bugs or answering questions about it, instead of the "throw together something that looks kinda like it meets the requirements" in the minimal amount of time/effort sort of lazy.
I am so glad I moved away from the web. I remember spending lots of time playing with different frameworks for Node.js and Java and PHP and Python, all with different tradeoffs, and all of them suck the fun out of programming out of me.
Yeah yeah I know <whatever> Framework is great and good for stability or something, but using a framework makes something that I enjoy (programming) feel more like filing out my taxes, just so I can end up with a mediocre CRUD application that more or less works for the project I am working on.
I have removed myself to from the web and programming almost instantly became more fun for me again.
in case someone really need it like in the article https://github.com/spring-rs/spring-rs
That's interesting! I absolutely don't feel the need for a massive framework.
I think a good part of the devs community has been burned by some framework at some point and doesn't feel the need for web frameworks, hence why nobody bothered to make Rails for rust. In a professional setting, all the services I interact with, have been implemented on top of express (node.js) or fast-api (python). I know people working in ecommerce who rely heavily on django or woocommerce, but rust usage among them is pretty low.
Rust is also one language where there are very little junior people, so you'll see wire-it-yourself library more than frameworks. Eg. sqlx is imho the best compromise in the ORM vs query builder vs plain sql debate: you get typechecked plain sql.
I think axum is very well architected and type checked routes offer a great DX (except for the tower::Service compatibility - sure, it's nice to have compatibility but the resulting code is quite clunky), and I'd rather have smaller components I understand over a huge black box.
Whatever you do, don't make this an RFC in a Rust repo/something up for debate and discussion. 500+ messages and literally years later, no one will agree on a single thing. Just make the thing you want and if people don't like it, they can stick with Actix.
No harm if all these requirements are met by some framework to cater to the Rust community.
In my opinion you should for 99% of cases use Golang for your web backend. Any other languages there are tradeoffs you are making.
Go:
- very easy to learn and grok Go code
- static typing
- fast compilation
- single binary (easier deployment)
- strong standard library
- large library ecosystem
- go routines for concurrency
- highly performant
Maybe Java,Kotlin and C# but they are still an order of magnitude more complex and resource heavy than Go.
Go is stuck in the eighties and replies like this are a good demonstration why it's very difficult to engage in intelligent discussion with many from Go communities.
As someone who mainly specializes in .NET, I have had incomparably better time participating in Java and C++ ones because people there are usually able to acknowledge pros and cons of various platforms, how they evolved and where are their strengths and weaknesses.
The average level of understanding and ability to consider what is the dev flow and how the language of choice impacts it in Go ones seems to be just so much worse it's not even funny.
That is to say, goroutines are discount futures/tasks which force you into synchronizing the "yielding of result" manually either via a channel or a waitgroup and a collection, or similar. Not to mention they are also much more expensive than .NET Tasks. I have not measured the cost of Java's new green threads yet but assume they are going to be in the same ballpark of memory cost as Goroutines, but with drastically better steady state performance provided by OpenJDK HotSpot when it comes to regular application code.
And lastly - Go requires you writing heaps of boilerplate for simplest things, Go channels come with a lot of footguns and gotchas you have to learn, standard library has weird omissions, type system is static but weak and as the demands put onto Go continue to become more complex, as more and more developers are forced into it, the language becomes the kind of unreadable soup you accuse other languages of. Just look at range over funcs and iterators discussions recently. It's ugly and token-heavy. And you will see a lot of code like this if you browse random libraries on Github - it's unnecessarily bulky, in a way that is excusable for true system programming languages but not in Go which has even higher level of abstraction runtime than .NET.
PHP's Laravel can do everything in that list. I'd just stick with that and focus on whatever you're trying to do, especially as a lazy developer.
The author is I think conflating laziness for joy. We don’t care to be lazy because that won’t do it. But we do want to have a language that we like to use. To look at, to play with, to understand and to rally behind.
There is no one web framework that will satisfy all criteria and all layers of what a web framework needs. Every so often we have to migrate as technology catches up and changes the ecosystem, like wasm did with Blazor.
I’d rather have a language that programming is a joy in. The laziness is a nice side benefit. I can adapt such a language to changing landscape any day. I know Ruby is such a language, and hence Rails adopts it’s joyful mentality. But is Rust a joy to program for? That I can’t say for sure.
> Rust needs a web framework for lazy developers
Write one?
You'll never believe what the end of the post says.
It really doesn't, actix is already there. Recently built my startup code over the past couple years with Actix and it had literally everything we needed easily. We just need more documentation and reference code bases demonstrating how to do these things. Rust devs tend to be fairly advanced and seemingly don't write enough docs or shares.
>Routing/handlers
Actix has it.
>Templates
Minijinja or liquid-rust[1]
>Static file serving
actix-files[2]
>Logins
Actix with oidccore is fantastic and easy[3]
>Permissions
Actix FromRequest is literally perfect. We have perm levels (admin, owner) and per-route perms for more fine-grained control.[4]
> Database interface
Diesel with diesel_async for connection pooling has been flawless at scale.
> Admin tooling
We didn't do this, but it would be simple with a bin/load-data.rs file that runs via a docker start command or tmuxp pane.
> Hot reloading
Cargo watch is getting deprecated, but was great. Bacon and and Watchexec are fully qualified successors. CSS watch systems work with the templates already same way as they do for SPAs.
> Background tasks
Make a bin/worker.ts file which defines a single binary and then use redis or another queing sytem to communicate between the worker and core server. We loaded all of HN (40M docs) into a search index with this approach and it was easy.
> Monitoring/observability
There's a decent story here with structured logging. Zero to production in Rust has a good chapter on it (2020) [5]. Lots of progress has been made since and exposing prom metrics endpoint is straightforward [6]. Sentry support is also decent and they sponsor actix.
> Caching
Imo, the story with Redis + actix is fine. We do this with our auth middleware to reduce latency on that operation since it happens with every route and I think it's smooth with FromRequest.
> Emails and other notifications
What's wrong with SMTP? Plus, Keycloak will handle your password reset infra out of the box. SDKs here could be better, but the APIs are fine and not too bad to do with Reqwest yourself.
> Deployment tooling + CSS/JS bundling
Imo, both of these things are the same as with other languages. Rust could use more documentation, but I don't think there's anything making it particularly hard to use.
[1]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-...
[2]: https://github.com/devflowinc/hn-search-RAG/blob/main/actix-...
[3]: https://github.com/devflowinc/trieve/blob/main/server/src/ha...
[4]: https://github.com/devflowinc/trieve/blob/main/server/src/ha...
[5]: https://www.lpalmieri.com/posts/2020-09-27-zero-to-productio...
[6]: https://romankudryashov.com/blog/2021/11/monitoring-rust-web...
Her point is that she wants a batteries-included framework that comes with integrated choices for these out of the box, similar to Rails or Phoenix or Laravel, so that you can hit the ground running without spending the first few weeks of the project picking crates and gluing them together.
He’s looking for the Rust equivalent of ASP.NET Core and there’s nothing wrong with that.
Sure, some people like choices and tinkering, but in many settings it’s much more productive to have the choices curated for you.
“But what if you want a different X instead? It might be Y% better!” is the typical comment, which ignores that the integration itself provides enormous value. Discrete libraries may be best of breed individually, but may be a heap of garbage if they don’t fit together smoothly.
I love programming in ASP.NET 8 specifically because I never have to think about whether a templating system will play nice with authentication, injection, routing, or anything else.
If you want to make a silly, minimal effort hobby project simply don't use Rust. I'm gonna be honest I don't understand this entire genre of using extremely complex, highly optimized systems languages for tools that don't need them. Your flow chart should basically go like this:
"Do I need zero cost abstractions because I'm writing a computationally expensive very serious project?" If the answer is no use a garbage collected, runtime managed language.
I write my hobby projects because writing them is fun. I don't find writing Ruby, Python, Go, and a host of other so-called "more appropriate" languages fun.
If someone enjoys writing Rust, it's natural that they'll reach for it when they're looking to write something for fun. If the tools/libraries in that language exist to make writing a particular type of thing more fun or easier, then more the better.
> minimal effort hobby project
Sorry, just spent 6 hours figuring setting up my python environment. Ready to start my hobby project now!
I don’t know about that. I already knew a little Rust last month when I wanted to write a REST API server that would benefit from being deployable as a single executable. I probably spent a grand total of 2-3 hours researching which framework to use (actix-web for me), reading the code, and implementing the endpoints I needed. The end result ended up looking an awful lot like a Python Flask app. The actual code writing part of the project wasn’t any more complicated than using any other language might’ve been.
Learning Rust and learning web service programming at the same time would have a steep curve. If you already know the basics of Rust and have written web services before, writing a new one in Rust needn’t be stressful.
s/lazy/efficient/g :)
Yesod has most of the things on this wishlist (though it's Haskell, not Rust), and Yesod is generally awesome. I've been working with it for the past several years, and I look forward to the next several years with it.
“Slow” scripting languages worked in the 90s for the web and they work even better for now, plus you have more to choose from. The key is to shell out to other tools for heavy lifting, like a database. Multi process architectures are where Linux really shines.
Rust can fit in that picture, but it doesn’t need to be routing http.
I'm struggling to see a usecase for rust. If I want to do something as high level as a web app, GC is fine. If I want to do something at the systems level, Zig is much more at home there.
And development in rust is glacial. It's no one language featurep (not complaining about the borrow checker in particular), but the accumulative overhead of all of them acting in weird ways.
I will say the tooling is absolutely amazing, it's nice to span "app level" and "systems level" concerns in a single language. But it is a lot of language.
> I like to make silly things, and I also like to put in minimal effort for those silly things. I also like to make things in Rust…
I think this part is perhaps the silliest part of a very silly article. If you really like to put in a minimal effort then why on earth would you use Rust? If you want efficiency, memory management and a compiled modern language just use Go. Then you won’t even need anything but the standard library for what you want to do. Or… use Django as you suggest?
Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?
I am a fan of Rust for systems programming, but so many people are using Rust for things that are nothing even remotely close to systems programming. So many projects you see being written (or rewritten) in Rust are projects where I just think 'wait, why can't this just have a GC'? And then you look at the code base, and it's all Arc<Mutex<RefCell>>s, and you can't help at marvel at this, since that's just GC, so what's the benefit of Rust here, exactly? (Don't @ me, ARC is GC.)
I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. People will brag about Rust's memory safety, and then you find out that they don't really know how lifetimes work, they just .clone() or Arc<Mutex<RefCell>> everything. Which is totally valid, but Rust is hardly necessary for that.
Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right.
> What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc.
I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation. Most of the time I bring this up, someone will suggest something like Swift or OCaml, but I think the part people miss is how even despite all of the complexity that comes with being a systems programming language, Rust really goes out of its way to try to be developer friendly despite that.
Yes, it's a meme that Rust programmers are zealous evangelists and want to rewrite the world in it (which is a bit of an exaggeration in terms of lumping all Rust enthusiasts into that group, but there's certainly an element of truth in it), but no one seems to talk about how _weird_ of an idea it is for a language notorious for having a terrible learning curve to be so popular with people perceived to be lacking real-world experience with the domain. How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? You might chalk some of it up to marketing, but I think people undervalue how much effort is put into the little details in Rust to try to make it more approachable, like error messages, standard library documentation, first-class support for all major platforms, and high-quality introductory materials (e.g. both the original and rewritten The Rust Programming Language book, Rust by Example, Rustlings). I don't think the same experience is there if you want to use Swift on Linux (where the support isn't nearly as strong, and a lot of the fancy new things coming out won't be available) or OCaml (from googling right now, a debate on reddit about "which stdlib should I use as a beginner" is on the first page of results when I search "ocaml std" or "ocaml stdlib").
One issue is that with GC, you lose prompt finalization of resources. A lot of code is written with this assumption in mind (e.g., file buffers are flushed if the last reference to the file is dropped—which is arguable incorrect due to the lack of error checking). And the borrow checker is the only thing that keeps everything from being mutable in place in Rust today. Having GC would open the possibility for alternatives to the borrow checker without compromising memory safety, but even Pony-style reference capabilities probably won't lead to a language where abstractions compose much more easily than in Rust today.
Maybe a language with a similar syntax, traits, monomorphization, and macros would still be interesting to many people? Would people prefer traits and macros over ad-hoc polymorphism (in the style of C++, which could subsume the macro use cases, too)?
An issue only in some GC languages that don't provide the constructors for deterministic resource handling.
Unfortunately people keep placing all GC languages on the same basket.
And before anyone mentions that it is easy to forget, well those languages have their own "Clippy" to take care of it.
> but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation
I dream about a Rust subset that's exactly that. What would be even better is if you could just use Rust packages directly with it. Since these libraries already do compile, correctness has been verified.
There definitely is some void!
I gladly take the whole rust "package" because overall it's just so good, at least for opensource / hobby stuff. I wish there was an equivalent but with GC, to use for work.
> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?
I think Rust is especially popular with a demographic that was not previously exposed to lower level programming. Meaning younger programmers (because modern languages are higher level) and web centric programmers (because we're in a boom of web development).
This demographic had a hard time entering systems programming, because while fascinating, its exposure is lower (less jobs, less projects), and entry cost (learning C, or C++<11) is harder.
Rust made systems programming more accessible, and systems programming, just as anything related to how things work under the hood, is fascinating.
Now Rust is hard, as you noted, but not hard in the same sense than C is hard.
C is hard because low level stuff bites you immediately. You can't quite easily just use a random library in C if you don't understand your build system, linkage, etc. If you mess up in C, the compiler will not tell you either, you will have to debug your way out of it.
Rust is different, in the sense that its difficulty is limited to the compiler saying "nope". If you can get the compiler to say "yep", then you're 99.9% of the time safe. Now getting that compiler to say "yep" may take time, indeed, but all in all you most often can just get away with sprinkling unwraps, clones and Arcs all over the place until it works.
In that sense, I think Rusts popularity essentially lies in the fact that it is a way to do low level stuff with a barrier of entry limited to being stubborn in learning it.
Having learnt C in high school, and doing Z80 Assembly prior as a 12 year old kid, only with a bunch of books from the local library, it is kind of interesting to read about fear and hard regarding C.
Yes it does corrupt memory, there are some crashes, I usually bash C, nonetheless it seems we have too much "safety playground" regarding learning processes nowadays.
> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?
Popular languages don't really have evangelism or fans pushing it aggressively. Those are traits of smaller languages that don't interop well with other ecosystems so they need a lot of evangelism to build out the library ecosystem.
> there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector
What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin? Because those have great web frameworks that address all the features requested in the article and a whole lot more, there's good first class support for all major platforms, lots of documentation etc. These languages are also famously developer friendly with good error messages.
Rust makes an '.exe', Java makes a '.jar'.
I think people want to write programs that run on an OS rather than an interpreter.
Java compilers have been producing '.exe' for about 20 years now, it is a matter to actually care to learn about their existence.
For the majority of executing code, there is no fundamental difference when it comes to a JIT compiler.
Besides, GraalVM can produce a native executable for pretty much any JVM language/program.
The problem is friction. To run a rust app you can just run it. To run a java app you need to install java first. This is no problem for backends running on servers, but client apps (like Minecraft) have to include their own JVMs to reach a wider audience, and this solution still introduces a bunch of complexity.
Not a thing since Java 9 and jlink introduction, or since those commercial AOT compilers exist, for 20 years now.
And if free beer is your thing, GraalVM native image or OpenJ9 also produce a regular executable.
Scala 3? It has the vast Java ecosystem available and state of the art GCs (plural), with either a focus on throughput or low-latency. Also, it can exclude the null value from the type system, marking it explicitly with a union type.
I think all NVM langs claim interoperability with Java ecosystem. The situation on the ground is never as nice as sold in my XP.
Scala is a great example where I've seen the "best" option being rewrapped libs with scala calls and types rather than a native solution and the dev XP just isn't as good overall.
You can hardly get higher quality code than what is generally available in Java, especially with their stability. Wrapping it to use the language conventions seems like a pretty solid choice to me.
The dev xp, I sorta agree on, but it has improved a lot.
Fast also means more CPU Ressource efficient.
I am all in for not wasting more and more resources.
Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless.
It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one?
I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.
I used to think that it was more likely that Rust would "expand upward" to provide the higher level syntax that people want in a language like I describe above, but it does seem like the language development has vastly slowed down in terms of big new features. I don't necessarily think this is a bad thing; plenty of people didn't like how much churn there was in the first several years after Rust 1.0 came out. I personally didn't mind since I never ran into any significant breakage in what I worked on, but I definitely noticed a change in how open companies seemed to be to use Rust in any capacity coinciding with Rust's releases growing smaller on average; I think "frequency of major language features" is often used as a proxy for "language maturity".
At this point, I think a new language is more likely to provide this niche than Rust, and I also don't think that has to be a bad thing. Having Rust scoped more to lower-level programming where you're more worried about things like minimizing heap usage and avoiding copying strings or whatever rather than trying to be all things to all users might end up with a better experience in the long run.
Lol, and there are the downvotes
> that are nothing even remotely close to systems programming
This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably.
Sure, rust is primarily a language aimed at systems programming. But it also is so much more (and also a cult).
* Its type system is excellent. Especially the lack of a "null". Even if, like me, you're fine with a GC, the type system alone is worth dealing with this insistent borrow-checker.
* Its multithreading is stellar. The borrow checker helps a lot in making it such.
* Its mutable/immutable model is highly practical. It's what makes the threading stellar and the type system more useful than in any other language I worked with.
* Its "oop" model is uncomfortable at first (coming from Ruby and Java) but forcing the "composition over inheritance" by not having inheritance is probably the best thing that can happen to "OOP". Every solution where I used inheritance, I shouldn't have.
* Its culture of "making the good way the easy way", being opinionated, and a community that adheres to this, is worth dealing with a thousand borrow-checker WTFs. cargo fmt, clippy, etc.
* Its build system that generates binaries that can just be "plopped" onto a server, "chmod +x" -ed, and ran is unprecedented.
I come from Ruby, Java, Javascript (typescript). I do a lot of Python, maintain some go services, have decades of PHP under the belt and occasionally dabble in some C and even C++. I can find my way around in a C# codebase and Objective-C. All have their strengths and weaknesses. Their place and use-cases.
But rust, for me, is the only "ecosystem" that ticks all checkboxes in nearly all situations. It has downsides, and I consider the borrow-checker to be one of them in a lot of my use-cases, but it's something I'm willing to deal with gladly, because rust's other benefits.
a few months ago there was an article linked here on HN (iirc about rust game dev) that argued that while rust is great, it's virtue of being mostly correct every time can also be a weakness.
the argument was that in early dev and prototyping phases you don't want to write good, clean, correct code but move fast and break things while not caring about edge cases - and this, the author argued - is relatively hard in rust.
making the good way the _relatively_ easy way
I agree with you on the borrow checker... Part if me wants a simplified(distilled?) Rust ... All of the good stuff, but remove the bad... Not sure how that looks but it is something I know I want
I like Rust, but wasn’t “plopping” a binary onto a server and running it one of the original virtues of Go?
Arguably a louder “plop” due to size, but then you don’t have to chmod.
Certainly.
A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone!
My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.
I much prefer rust to go for many reasons, but IME go gets this part much better. Darwin / Linux cross compilation, armv7, FreeBSD, oh sorry you don't have a linker for that toolchain, wait where are those OpenSSL headers... lots of cross-compilation targets I've done in minutes with go that scp and run right away that end up being days / weeks of adventures to cross compile in rust, in spite of me knowing rust much better than go at this point.
> But it also is so much more (and also a cult).
Way to lose readers with memeish statements like that. That said it's in good company of cultists like Smalltalk and Lisp community ;)
> * Its "oop" model is uncomfortable at first (coming from Ruby and Java)
It's OOP in the sense it has polymorphism, and "methods" . It's not OOP in almost every other conceivable way.
It doesn't fit with static OOP of Java. It doesn't fit with dynamic OOP of Smalltalk and Ruby.
> It has downsides, and I consider the borrow-checker to be one of them
I wouldn't want Rust without borrow checker, and never figured this complaint.
Yes, it's uncomfortable and will prevent you from making some legal code.
Guess what? So will a seatbelt. You move too fast to reach something and it snaps you in place.
Rust to me looks a bit like Java. "One owner per resource" is Rusts "One class per file".
I am not convinced that the mental overhead justifies the memory safety guarantees yet. At least for a general purpose language.
I didn't yet write a lot of Rust, perhaps more experience trivializes Rusts ownership model.
I'm just really leery of using languages that don't have a clear separation between immutable and mutable state. Having it in Rust catches so many bugs.
I also want to write code in languages where you don't have to engage in bad software engineering practices to get optimal performance. That usually means aggressive inlining, something that Rust excels at.
edit: the other thing I wanted to mention is that rust's features cause dependencies to be pretty high quality.
If I pass in a slice of something, I'm no longer worried that something ten layers down will change it.
Error handling is explicit and panics are rare, so I'm not worried that dependencies will start throwing exceptions after an update. (This is the reason functions should indicate errors in type signatures—a better ecosystem.)
ADTs mean dependencies represent fewer illegal states internally.
It's just really nice to write code where the bugs are a couple levels up from bullshit like this.
I think this is a legit sort of reasoning, but in an interesting way it's something where OCaml could fill the gap. It has its ergonomics issues, but I think the issues are basically the same/worse in Rust (except I guess Rust's macro system is better).
I say this as a Rust enjoyer, but I take the pain because I _really_ want what I'm working on to be fast.
I like OCaml a lot as a language, but the tooling is very, very poor by modern standards. Poor enough that I think it’s a total blocker on wider adoption.
OCaml is definitely something I'd consider using if I didn't already live and breathe Rust :)
I use Rust often for things that aren't possible in other languages, so I also use it for things that are possible in other languages. (Though I used Python for a production and an art project recently -- with uv it's quite nice.)
I think RC and clone are the way people begin to use Rust. While lots of criticism are against this usage for not idiomatic, it should be acceptable. Coming from Python, nodejs or Ruby, even RC and clone or stack based variables is still a magnitude faster than those languages. When it's about absolute control for performance you can drop down a notch to the borrow checker behavior.
That's an interesting perspective I'd not considered before. Maybe there are different "registers" of Rust, in the same sense that linguists talk about registers in human languages, where you use your language differently for different purposes.
And thus, maybe if you're writing something that doesn't need to be screamingly fast absolutely all the time there's a register of Rust where putting lots of things in Rc<Box<T>> is completely acceptable, in much the same way that you might use a lot of impolite words around your friends but you don't in front of your employer.
You may be interested in https://without.boats/blog/the-registers-of-rust/ :)
I think Rc<Box<T>> could be simplified to Rc<T>.
I'm gonna plug my Rust "invention" here:
Show HN: How to program in Rust as if it was old school C++ with pointers
https://news.ycombinator.com/item?id=34067924
I came to Rust from Ruby-on-Rails and I’m absolutely done with method_missing and finding nils and NoMethodError in production.
This is not remotely a trade off I’m interested in making.
Having written some Rust and a lot of Ruby, I find Kotlin to be a really nice "typed Ruby". Just like Ruby, Kotlin is an OO language in the core that is really friendly to FP. It's terse (not as terse as Ruby, as there are types to specify); but MUCH terser that Java.
Kotlin is serious about null-safety.
> Don't @ me, ARC is GC.
Don’t know if you intended this joke, but some time before Rust 1.0, @ was the sigil for garbage collection types (@T, like &T these days). Which I think was just reference counting, without even a cycle collector, because was shown to be undesirable before it could be improved.
F#is not C like and it's tooling and packaging is not as good as rust. Last time I checked it had multiple packaging solutions like paket and nuget. The tooling on vscode can be buggy
Easy, stay with .NET standard tools, MSBuild.
There is also Visual Studio and Rider.
> stay with .NET standard tools
That’s a dealbreaker in many situations.
If you haven't used .NET since the early 2000's, I'd recommend checking out current `dotnet` CLI and tool chain.
Then probably .NET isn't an ecosystem for you, that is fine, there are other options.
Such as? They're cross-platform and MIT licensed.
How is F# on non-Microsoft platforms, is it fully cross platform? I don't use C#, .NET, or F# so I have no idea about the ecosystem.
Yes F# has come along for the ride with modern .NET and it's as cross-platform as C# is. However, a lot of the really shiny .NET stuff is tooled up mostly for C# users, so it can be a challenge if you wanted to do something like a .NET MAUI (cross-platform GUI library) application in F# because the tooling and the content out there to teach you about it assumes C#.
F# can usually handle C# things - they put a lot of work into ensuring interop with new C# features - but the languages are from different paradigms so it is sometimes a bit awkward despite F#'s comprehensive OO support.
Personally I struggle a bit with F# because it doesn't have typeclasses, and a language that looks that much like Haskell but doesn't have typeclasses just feels weird to me.
Although it might get them... C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed), so F# could presumably piggyback on that if they wanted.
> C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed)
Why not name it Traits?
Or just OCaml
OCaml is an excellent language, but doesn't it have a GIL?
Multicore OCaml finally landed a few years ago: https://news.ycombinator.com/item?id=34013767
> - Phoenix on Elixir! Yes, it's not quite so blazing fast
As someone running a fairly cpu heavy SAAS application for users who literally dog pile our whatsapp support forums if it goes down for even a second, Phoenix is pretty damn fast in production. I won't claim its as fast as rust but it will run circles around ruby or python and for IO bound tasks, competes perfectly fine with go. Its never been a bottleneck (database is another story)
People want everything in one language.
I do some systems programming, use rust for that and I am exactly the person you describe :-)
After reading endless insufferable comments on HN a la “this should have been written in Rust” I realized that there is a very strong possibility that the people making those comments do not know another language. We saw this with JavaScript a decade ago. Before that it was Ruby.
Is Rust only for "systems programming"?
I would say it shines when you have systems constraints, for example embedded & robotics work well with Rust. You cannot have a GC (either you don't have a heap or you cannot tolerate a GC pause resp.) but you still have the benefits of a good functional programming language to write your algorithms in.
The benefits are less obvious if you have less of those constraints: go is way way simpler to write large codebases for cloud applications in and still provide an excellent concurrency support. Python is way better for experimenting.
System programmers thinks so.
I guess that if all you do is hammer nails then a multitool is just a hammer.
Which is a classical example of everything is a nail.
I agree the type system is the best feature of Rust but neither Ruby or Elixir have the level of type safety and type expressiveness of Rust.
I'd recommend Haskell as an alternative, but Rust "fixes" plenty of long term Haskell annoyances (especially around laziness by default, concurrency, unsafe std).
Being able to use Arc<Mutex<T>>, Rc<RefCell<T>> and other smart pointers gives you granularity and control over what happens to your memory. I think it's a nice feature to have to mentally reason about your memory usage (incidentally a weak point in Haskell); even if it were on-par with a GC implementation-wise, why use a GC over this?
I like to have control over my code (and I'm probably one of the few who think monad transformers in haskell were a good feature - despite their clunkiness) and I'd pick explicit code over "magic garbage collection in the background" any day. This is not to say I like verbosity for verbosity's sake (eg. think React Redux in JS vs the implementation of the same idea in Elm) but in some cases I think it's justified and it brings extra value.
If Rust had no borrowing at all, just Rc<> everywhere I'd lose maybe 5% interest in it, maybe less. Value orientation and Traits system, close to bare metal speed and stellar stdlib are what's most interesting for me.
> Go try Ruby on Rails for a while!
You gave a long list of benefits of Rust - which should have answered your own question - and then suggested people use an ecosystem with almost none of those benefits.
I’m sure it made sense in your head.
> and a compiled modern language
Let's just say different people have different opinions on this one. Personally, I find Go to be a big regression in language design given modern PLT research, and wouldn't use it unless forced (e.g. terraform providers). Other people have other opinions: a friend I respect a lot has great success in the Go community.
I'm telling you that because if, as a Go enjoyer, you're baffled by the writings of a Rust enjoyer, it's very likely the result of different perspectives rather than silliness. And if your conclusion is "just use go", you're probably the one being silly.
This is definetly something the article should have drilled down on. Why Rust? I'm sure everyone's tired of hearing why rust is an excellent alternative to c/c++ for new projects, but as an alternative against Python it gets muddier. Rust has a clear advantage in performance and memory footprint and a much better multithreading story, but those are things that aren't high priorities for 95% of web development.
That basically leaves you with Rust's type system. Rust's type system is pretty great, and if we pretend we can't hear the Haskell developers it's one of the best type systems out there. That might seem to get in the way of quick prototyping, but on the other hand it would mesh really well with a framework like Django. One of the great things of Django was that you define your data schema, and Django takes care of both the database and a passable admin area. I'm sure you could greatly expand on that principle, with data types driving a lot of behavior and conveniences that the framework just handles for you.
Maybe a bit like .NET, but without the enterprisy coat of paint and without putting dependency injection everywhere.
The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. Its sensibilities are in a sweet spot that makes it very easy to pull off huge refactors. It was also a lot of people's first introduction to algebraic data types being used in nearly all error handling (its usage of `Result<T, E> where E implements Error` and lack of nulls or exceptions). It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps.
Most of those people aren't aware that the type system is a feature from most ML derived languages since Standard ML is a thing.
All of them with better ergonomics for Web development.
Do they really have better economics? (EDIT: ergonomics!)
Last time I looked into OCaml, I struggled to find a way to interact with the database in a type-safe way, I never figured out which standard library I was meant to install, I was being encouraged to use 2-3 different project management tools (Dune + Esy + OPAM), and I gave up on writing tests. But at least there's a garbage collector!
I realise these are all problems that I'll wrap my head around over time, and eventually they'll seem completely trivial to me, but the introductory documentation on getting started as a professional (and not as a first-year student doing a French-language compsci degree, which is what most of the documentation assumes), is pretty dire.
Meanwhile, much as I'm sure I overuse `.clone()` and `[A]Rc<_>`, the ownership model of Rust is deeply useful. It's something I often find myself missing in Javascript - not necessarily because I want to produce the most performant code, but because it's useful to understand the lifetimes of the objects I'm keeping around. Am I accidentally storing a reference to something in a closure that I forgot about? When this object gets deleted, have I checked that it's the last possible reference to this object? Etc.
Like, I don't think everyone needs to learn Rust. It's a great language, but there's lots of other great languages out there, depending on your personal and business contexts. But I think this idea that Rust can and should only be a low-level language feels absurd to me. It is a fairly ergonomic language with a fantastic ecosystem, a powerful type system, and an ownership model that will be useful even if you do try and opt partly out of it with GC-like wrapper types.
I guess you mean ergonomics.
Yes they do, unless you get your editor to magically type `.clone()` and `[A]Rc<_>` all over the place.
Not to mention they don't need unsafe, or 3rd party crates to handle graphs.
Additionally, all of them have interpreters and REPLs alongside their compilers, streamlining the code-develop-debug loop.
Thanks for pointing the typo out! I've fixed the comment.
In fairness, I think a lot of this comes down to familiarity. I'm fairly familiar with `.clone()` and Arcs at this point, so they don't really change much in terms of ergonomics. Usually their usage is fairly obvious, and quite often my editor literally does magically type the `.clone()` calls through LSP fix commands. It's the same as, say, OCaml's insistence that recursion is better for complex loops than, say, `while` — it's not necessarily wrong, but if you're unfamiliar with the idea, it's going to feel weird.
More important to me is the ergonomics of the broader ecosystem, and that's something that Rust has done well, that other languages just don't seem to be interested in at all. Things like integrating testing into the standard workflow; working hard on getting the stdlib in good condition; having an excellent ecosystem of well-documented, usable libraries; or designing error messages and lints with a focus on getting people to understand how the language works and not just what they've done wrong this time. I've really missed that stuff whenever I've tried MLs. You mention, for example, REPLs, but a unit test is basically a saved REPL session that you can repeat every time you make a change.
I'm not trying to convince anyone that Rust is the best language in the world or something. I really like it, but I find it helpful to think in terms of object ownership even in non-Rust languages, and I can understand why for other people that sort of approach is unhelpful. But I would love to see other languages embrace its ergonomics more, or new languages created with that as their focus.
A unit test has nothing to do with a REPL, a proper REPL provides something similar to jupiter notebooks in feel, alongside debugging and hot code reload experience.
Maybe we have different understandings of REPLs. For me, a REPL is a tool that I can use to try out some portion of my code, see how it responds to various inputs, see how it handles certain cases, and explore the internals of it via debugging tools.
But... that's what I do in a unit test anyway. A unit test is essentially a REPL session that I've frozen in time, can replay whenever I want, can debug, can trigger a fresh run whenever changes occur (which isn't quite hot reloading, but often a darn sight more useful), and can keep track of and share with my team. Which means I'm not just able to explore things on my own, but I can see the explorations that other people have made with their code.
For me the REPL is the experience similar to Lisp Machines, Smalltalk kind of experience, which is loosely captured in Jupiter Notebooks.
As for unit tests being more usefull, depends on how much one is willing to wait for them to run in Rust, given its compile times.
Typing in modern days is effectively moving the task of debugging to compile/ide annotations process instead of testing for correctness.
Albeit it makes the process easier compared to a really shittly written code without strict typing, but against good codebases, it takes the same amount of time.
> it takes the same amount of time
in my experience it doesn't
1. refactoring are in my experience still much faster (and reliable doable) with rust compared to e.g. Js/Python even in presence of a lot of tests. This is a bit less of an point with Java/TS/C# etc. through I had some very bad (and also some good) experiences with refactoring in TS. And to be clear I don't just mean pure refactoring but any larger changes affecting many places in code which might be needed to idk. impl. some feature.
2. especially with Js,Py and similar there are way to many edge cases you can have to test for all of them. Sure most times this mainly matters when writing libraries but on larger projects does apply too. Stupid stuff like you expecting a `list[int]` and someone (externally i.e. outside of your tests) passes a `dict[int, int]` and that happens to work as you current impl. is only linearly iterating it as if it's a `Iterable[int]` but then you change the impl to require a `Sequence[int]` as you access it by index in some corner case and now you customer has really strange subtle bugs. Can't be caught by your tests as the problem is the customer but still breaks the customer which is always bad and can't happen with rust. Sure also won't happen if everyone uses type annotations and mypy correctly and strictly. Through you can't rely on your customer using mypy, but you can rely on your customer running compiler checks (as it's the only way to build the code). Also while mypy is much much much better then pylance it is still prone to issues as both `cast` and `ignore[..]` are things you sometimes need but which easily can hide bugs if the code changes (cast doesn't pin the "from" type and ignore is scoped by place not by what is wrong)
I strongly disagree on the principle that tests and types have a 100% overlap in the problems they're solving.
Why not?
If you think about correctness of a program, (i.e for any combination of given input , it changes a state in a determinstic way, including no state change for invalid input).
Strict typing is one way to accomplish this. The cpu does not give a shit about types. It cares about memory registers and locations. The unique code built into the compliers/transpilers is the thing that validates the correctness of the program in this case.
You can move that code into the testing suite without relying on the complier, and just do testing. Generally, given competent programming skills, this takes about the same amount of time as designing a well structured program - your tests are pretty much your design document for the thing itself.
This is a very anti-pragmatic way of looking at things in my opinion. The program is not a snapshot that exists in a vacuum. Most programs are going to grow over time and have things added and removed in various places by many people. They're going to have many interfaces and operations.
I think you're arguing that tests and types can both be used to check a particular case for correctness. Sure, this is true. However "moving type checking code into the test suite" means nothing—that would just be type checking.
When you make a code change, there's a difference in the kinds of feedback you get from your tests and your types. Tests usually cover business logic or stories—things that you want or don't want. Types ideally cover everything. They check every operation applied to a given piece of data. Of course types are rarely precise enough that they can catch every logic bug (e.g. strings with semantics not encoded in types, like email addresses).
This is just scratching the surface. You might just have to try out both to get a better sense of how they feel to work with.
You can not test for the absence of behavior. You can design type systems to ensure the absence of specific behaviors.
Types [1] can only reason about categories of values, not about values. Tests and types do have an overlap, but the best option is both. Especially when combined with fuzzing, types can exclude large number of cases, making it even more efficient at covering a huge range of code paths.
[1] yeah, there are type systems like lean, coq that can do both, but the proving process is just currently not realistic for everyday applications
> instead of testing for correctness.
Except you can’t test for correctness. Tests can’t prove the absence of bugs.
People who say copilot is useless.... I can only imagine they're in a dynamically typed language. Copilot + Rust makes boilerplate go fast. Strong typing is force multiplier for code gen.
I suspect that’s true. I never blindingly copy LLM generated code (that would be recklessly stupid), but I often only quick skim rust code generated this way, just to make sure the general task it is solving is what I asked for. If there is an unhandled edge case or or memory handling bug, rust will catch it.
It's also easier to implement a generate_code -> check_for_errors -> give_error_to_llm -> fix_code loop, because the errors that rust throws at you are most of the time really well thought out, and as succint as usefully possible. Comparing it with python, where you have to write custom parsing to trim it down and even then it's hit and miss on where the actual error lies, it's not even funny.
Rust’s compiler errors is definitely one of the selling points of the language.
>Result<T, E> where E implements Error` and lack of nulls or exceptions
This all goes out the window when people throw “unwrap” all over the place because “this should always succeed”.
Rust does not skirt around the fundamentals. You can still handle errors however you want, you can still blast side effects all over the place, and you still have to uphold an arbitrary set of invariants specific to the task at hand. But the ecosystem as a whole is filled with things being done the right way because the language and its linters have always been quite helpful.
In any program there are errors you can handle and errors you can't, errors whose vary existence suggests something has gone horribly wrong. What else should you do in that situation but panic?
> The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system.
TypeScript has an equally powerful type system.
Python's type system is almost as good.
Both have are significantly more productive when it comes to writing software, and have bigger ecosystems and lower learning curves.
> It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps.
TypeScript and Elm are both good at this while being useful for web development today.
As someone who loves both TS and Rust: you couldn't be more wrong. TS is not even half as good at making invalid states unrepresentable.
A simple example of the (many) things you can't do in TS:
Try doing that without a runtime crash in TS. Super useful pattern for state machines (which are the building block of computing).I miss more features of Rust in TS that features of TS in Rust. All the time.
Interesting, great example. This kind of compile time safety can't be achieved without borrow checker, I guess? I'm now thinking hard if there's some type magic similar to the exhaustive checks for Typescript discriminated unions ("kind satisfies never" checks in switch statements).
I've been trying to come up with a similar pattern in TS many times but I think you cannot do this due to the lack of moves (bindings do alias, pass by reference).
But TS has so many dark magical patterns that I'm still hoping to be proven wrong.
> TypeScript has an equally powerful type system.
How does TypeScript's type system prevent shared mutable state?
How does Rust's type system prevent shared mutable state for out-of-process data common in distributed computing?
It doesn't.
When did threading get added to JavaScript?
And does Rust have type unions and intersections, interfaces, and mapped and conditional types?
> When did threading get added to JavaScript?
Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over)
> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?
You can typically accomplish the same thing with enums/proc macros/traits of course—with the additional benefit that the type system is designed to be sound. Soundness is an explicit non-goal of TypeScript[1], so once you start layering on those kinds of overly-clever types, you soon reach a point where you're just lulling yourself into a false sense of security.
[1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
> Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over)
...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency.
> usually
So, not always. That is - TypeScript's type system contains features that Rust's does not have.
JS has concurrency (but not parallelism) despite being single-threaded, though.
If you ever put an await anywhere in your code, an arbitrary amount of random stuff might run between the time you await and the time the awaiting finishes.
Same applies to older mechanisms like callbacks and promises.
Race conditions are more rare there because as long as you aren't doing any IO, there is indeed no concurrency, so you can't e.g. get two threads trying to increment a single variable at the same time. They can still happen, though, especially if you accidentally do a partial change to an object, put it in an illegal state, and do IO before you finish that change.
> which is an extremely rare source of bugs
Confidently asserted, but very debatable.
> The vast majority of errors caused by shared mutable state are related to concurrency.
Concurrency, like async-await, you mean?
> TypeScript's type system contains features that Rust's does not have
Sure, and likewise Rust's type system contains features TypeScript's does not have—for example, just try expressing anything close to traits with TS's type-erased generics. Since the feature sets aren't the same, I suppose it's a matter of opinion which type system is preferable. But I know which one is more helpful for me for sure (especially considering the aforementioned soundness issues).
> which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency.
Simply so untrue I’m not going to elaborate further
> When did threading get added to JavaScript?
idk. many years ago through stuff like service workers, having shared memory through TypedArrays and similar.
But for the discussion more relevant is that shared mutability constraints do not only matter with threading, they matter with any form of concurrency (like JS async/await/promises and before that callbacks). And even without that you still have other single threaded and single tasked concurrency with the classic being changing a collection while iterating over it. So even without classical forms multi threaded concurrency still very helpful.
> And does Rust have type unions and intersections, interfaces, and mapped and conditional types?
Rusts type system is mainly nominal typed while TS is mainly structural types so it's a bit hard to compare. Like if you nitpick then you could maybe argue that based on TS type system having "features rust types system doesn't have" it's more powerful (but you also could argue the other way around it depends on how you count them). But that would be misleading as it ignores that not only are they two fundamentally different approaches to typing it also ignores that some features are implemented through other means outside of the type system.
Practically having used both I can say that while TS has some things in the typing which are a bit cumbersome to do in rust when it comes to helping me having correct code in context of changes, especially larger changes, and especially libraries Rust still yields better results in my experience. Naturally assuming you don't abuse the TS in either case.
(and to technically answer the question, type unions == yes but different, intersection == no but also make little sense in rust, interfaces == yes but different, mapped types ~= depends on the aspect in some yes and better then TS in other no but implicitly through derives so worse then TS, conditional type ~= again handled through different features depending on usage either associated types or feature gates)
That is done by the compiler, not the type system
For what I hack on I often run into issues with the FFI performance between go/c# <-> c/c++. I’d rather not write C or C++ and Rust is one of the few languages that allows me to mess around with obscure libs at native performance and yet slap a web interface in front of it. cxx/bindgen is stellar in how fast they allow you to wrap libraries. These cases is where I would want like the simplest most opinionated web framework (like gin in Go).
For everything else, there’s Go IMO.
Have you had real success with cxx? I've been trying to FFI a C++ lib (that I have limited control over) and it's been a real PITA. At this point I'm thinking of just making a pure-c interface for what I want on the C++ side and using C bindgen or just straight "extern C" because C++ FFI seems so painful.
FFI can be a source of performance issues in Go but not in C# (at least not to the same extent), unless you go out of your way to fight the happy path approach.
Sometimes you do have to rethink what you marshal vs what you just manage manually, but that’s what pointers are for (that can be turned into ref Ts for single values and into Span<T>s for slices/arrays/etc). The idea is that performance ceiling of FFI in .NET is as cheap as direct calls.
> but as an alternative against Python it gets muddier
For me, a clear advantage of rust (and also Go) over Python (or Ruby, or PHP) is not having to deal with runtimes. With Python, the server needs all sorts of setup. Exactly the right version and configuration of the runtime. Pip. Or Pipenv. Or Pyenv. Or Conda. Or... and so on. Then it needs the libraries installed. Some of which must be built natively; so just packaging them in some CI is often not even possible. These native builds need lib-something-dev packages. Then with an update of the underlying server, suddenly nothing works anymore.
Having a single binary that I can plop onto almost every linux box and which "just runs" regardless of the exact version of Ubuntu, cargo, rust-toolchain on the server/hosting machine is invaluable. I'm so done with maintaining the fragile card-house that my Ruby-on-rails apps require, or that my python/flask services need, that my nodejs insists upon: with rust this is no longer needed.
And yes, docker/containerization is a solution to it. And yes, I know about the options to package up a python app with runtime included. But all that adds extra complexity. It merely makes it easier sometimes. Not simpler. And it inevitably makes troubleshooting, upgrading, etc even harder in some future.
Between Rust and Python there are a huge distance full of options with managed compiled languages, with AOT, JIT, or even both AOT and JIT as standard toolchain feature.
> and if we pretend we can't hear the Haskell developers it's one of the best type systems out there
Eh, Rust's type system isn't one of the best out there. It's lacking higher kinded types, etc. It's abilities in type level programming are frustratingly limited as well.
So it's advanced aside from from Haskell, OCaml, Idris, Scala, etc. Compare to OCaml's effect system for an advanced type system feature.
I 100% agree with you (I really miss HKTs), but I don't think the GP was using "best" to mean "most fully-featured".
And with that in mind, I do agree with the GP. Scala's type system, for example, is full of warts (well, Scala 2; I still haven't tried Scala 3). Rust's is cleaner and has fewer gotchas. I very rarely have to look up how to express something in Rust's type system, but I remember when I last did Scala, I often ran into weird type-system related errors that I just didn't understand and had to dig into to figure out. Some of that, sure, is likely due to Scala's type system having more features, but some of that is because it's just more complex. And I would usually rate something of lower complexity as better than something with higher complexity.
One of the major things about Scala 2 vs Scala 3 is the removal of many of the type system warts, in particular the type hierarchy now forms a lattice (if I'm getting my terminology right) rather than being rather adhoc in various places.
Lots of other small annoyances like the whole tuple situation have also been fixed.
EDIT: Plus: intersection types, sane macros/inlining, etc.
Unfortunately (for me), some of our projects still have to cross-compile to 2.x, but that's irrelevant for greenfield. I'd give it a whirl -- it's a great improvement over Scala 2.x.
OCaml's effects are fairly new, and the Rust maintainers are also looking into effect systems. Who knows, we might also get HKTs and dependent types too in the future.
The author is clearly building things for the joy of it. If she gets the most joy from Rust, that's what she should use!
> See, if I want to make something for the web, I could use Django but I don't want that. I mean, Django is for building serious businesses, not for building silly non-commercial things!
Personally, I spent the first decade of my career switching between languages, believing that I should use the best tool for any given job. I spent the last ~five years doing mostly Rust, and I've learned that there's a level of mastery of a language you can never quite reach if you're always context-switching between them, especially a language as “deep” as Rust. This means I write things in Rust that Rust is not the best language for.
> If she gets the most joy from Rust, that's what she should use!
In the past I’d try to justify why I’d done something a certain way when another way would’ve been faster / better / cheaper, but I now realise that (at least for personal pursuits) an acceptable answer to “why?” is simply “because I wanted to”.
I feel like this is where I've personally landed with Rust. For many applications, it's at least good enough. It gets the job done. It looks and feels professional. Fit and finish are rarely a material concern. It rarely causes active problems (except where there isn't native coverage yet) and reduces or eliminated many more. And... well, I like it.
If I were putting together a web development team, would I recommend Rust? ...probably not. But that's because I'm putting together a team, not a playground. I'm paying people. I want to use common, well-supported, time-tested methods, unless steering away from that is truly needed to make the project successful. For web dev, that assuredly ain't Rust ("yet," some may add).
But for me? Just for me? I think it's a language I'll always enjoy. Within that line of thinking, I do feel there's room for better web dev tooling in Rust, though what's already there is probably enough to at least get started.
[flagged]
Yes?
What kind of logic is this... The Rust language is quite rigorous, so web frameworks on it should also be equally laborious to work with? You have to roll your own authentication, you have to do your own routing, you have to do ad-hoc string manipulation instead of templates?...
The person likes writing in Rust, and would like to have a batteries-included web framework so they can tie together a web app quickly on the language they like to use... And I know they did not include https://rocket.rs/ in their 'existing ecosystem' section.
If you find the language rigorous, a web framework can't magically do away with that. It's genuinely illogical to believe so. There are plenty of web frameworks on Rust that are quite nice to use, but they are still Rust, with all its shortcomings in the same way Django is still Python with all its shortcomings.
What you're asking for is a DSL built on top of Rust for the purpose of creating web apps.
Show me where I asked for a framework that magically turns Rust into Ruby. The person has created a list of (high-level!) features that they need. None of them are 'no borrow checker'.
I reckon "Rust on Rails" would be a great idea.
It'd be cool to have an out of the box "90% of what a website needs" toolkit that means writing your 10% custom code/secret-sauce in a modern code security obsessed language. Even if it is opinionated and "batteries included" in ways that make some things annoying.
I have built many projects that start with a WordPress install, to piggyback it's CMS, user management, and admin backend. I then inevitably end up making a choice between writing the project in php, or jumping through hoops to use the WP features (like auth and user accounts) in some other language that's more appropriate to the task at hand.
Loco.rs is what you're looking for.
There is Rust On Nails too.
Counter example: stringly typed code can be written anywhere.
Rigorous isn’t the same thing as tedious?
I mean, OP is working on such a "magical" web framework now. Time will tell how it turns out, and how usable and magical it ends up being. But at least the author isn't just whining; she's put her hands to the keyboard and is going to try to get it done.
> What you're asking for is a DSL built on top of Rust for the purpose of creating web apps.
I don't think that's necessary, personally, but if someone really wanted that, I'm sure they could come up with something that can be wrapped in a Rust macro invocation, that gets expanded to something smaller and faster (compiled-code-wise) than anything you can get in a Rails app.
For what it’s worth, for me, the time-to-first-attempt-to-run-it is faster in Python or Node than Rust (sometimes), but the time-to-first-working program is generally not, and by the time I have the Rust one working, it handles most of the corner cases with clear error messages. There are rarely unexpected cases not handled.
In other words, I find it faster to produce working stuff in Rust and much faster to produce quality stuff.
Obviously I’m just one data point.
I don't as a rule web dev, so when I do I fall into the same category as the author: lowest effort to get something mostly right.
An explanation for "why bother try to have a low effort web server in Rust?" that I haven't seen mentioned: Once you're past the introductory phase of being familiar with Rust, if you don't need to pedantically handle every error case, it can be _very_ simple.
A low effort "doesn't have to be very flexible" web server would be terrific & easy to use in Rust.
Having said that, I'm not aware of the actual offerings available. Maybe there is one, other posts have suggestions.
> I like to make silly things, and I also like to put in minimal effort for those silly things
Saying that and then use Rust is like saying, "I want hassle-free driving, that's why I drive a car with a 7-speed manual shift".
If you want a full-auto, then use it. "Minimal effort" is the reason why people wrote garbage collectors in the first place.
Rust has benefits besides just memory safety and being efficient, it has great language design and a great toolchain. I chose (learning) rust over golang for quite simple projects with no performance requirements, out of sheer frustration with the toolchain/design of go, golang came off to me as "let's try to be special and make bizarre design decisions" which made it confusing to learn, not only that but I very quickly ran into pain points, whereas rust felt like everything just took the most logical straightforward path, and everything "just worked". It, to me, genuinely feels simpler, because things were what I expected. Kind of like apple simplifying their mouse to have no buttons and thinking it's very simple and easy, but then its just more complicated because it's so unusual, whereas everyone knows exactly how a normal mouse works. Just my view. I use typescript and needed a language to make a couple simple programs that could compile to a single executable, I'd love another option but don't want to use one that's not matured enough.
Strange - my experience was the opposite for Rust. The extreme plethora of String types, the way life time annotations made refactorings very difficult with very high cognitive overhead, no batteries included standard library, even error handling needing external support, string slicing panicking in Rust, async is a mess to debug - Go in contrast is a far more comfortable and consistent developer experience.
Zig is an excellent middle ground though it doesn't hit the maturity spot - I keep on having to update build.zig with most releases.
That said, what exactly was the issue you had with Go?
Basically the type system, most rust projects usually don’t come near “The advanced Reason there’s rust” and if they do need that there’re hardcore libraries for that, an ecosystem like that usually suffers from exhaustion cause no dev will want to maintain just a library and this is also the good apart of rust cause it lessens the barrier into the language as the ecosystem gets bigger
I use Rust primarily due to the type system. I could use OCaml of course but its a tooling nightmare compared to cargo. The fact that Rust is fast by default is just a plus.
Yes the intersection of compiled performant and web is mostly filled by Go.
It would be great to introduce some competition there, then!
(Not only because I think competition is good, but because I really do not enjoy writing Go.)
This thread is amusing.
Go look at job boards. The competition for Go, Rust, Django or whatever is Java+Spring. That's pretty much the industry standard unless you're in a Microsoft-only shop.
It’s disingenuous to leave out C# and F# out of this, given how much closer they are to Rust in language features and how much more “close to the metal” capabilities they offer while also having opinionated web frameworks, better CLI tooling and package management and being generally very productive languages.
Nobody enjoys writing Go but there’s a reason do code in Go and we can’t ignore it
From a technical point, you are absolutely correct. From a developer heavy business, it's a little more complicated.
If Rust had a good full-fledged web framework, it would enable more developers to justify why the business should use Rust. The culprit is that it would require a heavy education budget, but it would in turn enable the business to allow using Rust for other parts of the business which could benefit from Rust, e.g. middleware, small components, CLIs and systems programming in general.
Having a little bit of Python here, a little bit of Go there and a bit of Java elsewhere can become chaotic. There is a huge benefit for a small company to only have 1 programming language everyone agrees on using.
If your goal is to use just one language then why wouldn’t you pick JavaScript (likely Typescript), C# with Blazor, Go with templates or basically anything on the JVM? Rust is a bad general purpose language in my opinion, and its performance isn’t actually good enough compared to C# to really justify the added headaches. I say this as someone who really, really, doesn’t like C# by the way.
If your goal is easy web development, Django, Ruby on Rails and Laravel are frankly going be extremely hard to beat. I prefer Go with templates, but that’s still much worse than those options.
It could beat using C/C++ for using an embedded web server. I remember I tried that once and a lot of the work was using aho-corasick for working with paths, handling cookies and dealing with a bunch of nasty error handling all of which in theory would be easier in rust.
My problem wasn't so much dealing with memory management, but trying to put an upper bound on memory usage and failing nicely when that upper bound is met. I generally don't like working with garbage-collected languages, or having to use some niche application-specific language when I can just use a general-purpose language instead.
https://github.com/BurntSushi/aho-corasick
I've had a lot of fun playing with it, it was very nice & simple to use. It's also foundational in the Rust ecosystem, so it's well maintained.
> I also like to make things in Rust
Seems like a good enough reason to use it to me, but perhaps I’m just another cult member.
> we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++
I think rust is just safer period, regardless of your level of expertise or background. Or are you saying that every memory safety bug was written in by someone inexperienced?
Not to mention the concept of “sharing code.” See I may write garbage tier rust code that basically glues together a bunch of libraries, many of those libraries are written by programmers way better than me, and I can gain performance and safety from using their work. The performance difference between languages like Rust and JS is huge, even if I, tainted by my background in Java, write dogshit code.
> I think rust is just safer period, regardless of your level of expertise or background. Or are you saying that every memory safety bug was written in by someone inexperienced?
I think you're reading too much into that and creating conflict where there isn't any. GP just meant that they had a bunch of interpreted language OOP developers (probably Java or C# or something like that), and they wanted them to start writing code in an AOT-compiled language (yes, I know about Graal native image; not the point). And that teaching them Rust is probably going to result in safer code than if they were to teach them C or C++.
That shouldn't be a controversial statement.
> GP just meant that they had a bunch of interpreted language OOP developers (probably Java or C# or something like that), and they wanted them to start writing code in an AOT-compiled language (yes, I know about Graal native image; not the point).
JIT vs. AOT is not the same as being an interpreted language. For most applications, running on top of the virtual machine is a good thing, I don't see JVM developers turning to different languages just to escape the JVM, outside of some niche projects.
Also, without claiming that experienced c/c++ developers never write memory safety bugs, I don't think it's at all controversial to say inexperienced c/c++ developers write a lot of them (and hopefully experienced ones write way fewer).
(Also not the point, C# can be AOT-compiled as well these days)
> Seems like a good enough reason to use it to me
I was trying to out that wanting to take the easiest path was rather contradictory to working with Rust.
> I think rust is just safer period, regardless of your level of expertise or background.
Yes, I’m not sure how you think I was implying something different. We (specifically) adopted it because it was easier for our (specifically) developers who weren’t familiar with low level languages to work with compared to c/c++.
> many of those libraries are written by programmers way better than me
You shouldn’t sell yourself so short in my opinion.
> If you really like to put in a minimal effort then why on earth would you use Rust
Because it's a fun language and you really do get to avoid the borrow checker nowadays if you just use `Arc` and `Clone` all over the place. I'm the same as OP.
Also, I love the package ecosystem. I know it (rightfully) gets some of the flack that the JS ecosystem gets, but most of the time, I truly don't care. I enjoy C programming as well, but C not having a common packaging system / cargo equivalent has really hurt it a bit in my opinion.
I feel like my Rust code takes 3x as long to write as my Python code, but the gpt results for rust are about 10x better, because the tooling is a backstop against hallucinations.
I really like the Rust tooling and I like exhaustive pattern matching. Python post-dev debugging time is probably 10x vs Rust. That's why I choose Rust.
For writing web services that do a lot of data processing?
Because performance is a thing?
Because you like the Rust ecosystem?
Because you enjoy developing in Rust?
> Yes, yes we use Rust in production because we thought it would be easier (well safer) to teach to interpreted language OOP developers than c/c++ but why on earth would you ever use it for the web unless you are a member of the cult?
Rust is great, high level language that's super convenient for implementing arbitrary algorithms on arbitrary huge, complex data structures safely and quickly. Value semantics is absolutely unique and useful. The system of traits and standard library using traits like Ord or Hash means that it's enough for your type to implement one of those and suddenly it can be a key in a HashMap or BTreeMap and can be a part of even larger and more complex data structure. Adding a web to that easily could be super useful.
Go is only modern in release date.
As a Linux user I’ve had to deal with these kind of people who wouldn’t use something new unless it was made the same of what they’re currently using, all my life, they just are not able to get it
I wish the author success in their endeavor, but Rust is pretty far down the stack of languages I'd use to deliver a webserver.
I look at Rust for serving web-traffic and I see: dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang), weak client library stories (if I'm writing a service layer for a db, etc.), high barrier to entry, thin overlap with the core Rust value proposition (correctness around memory access, performance).
That's not even addressing the "what happens when my entry-level dev has to write something that interops with a web framework written in Rust." My heart can't take those code reviews, I might as well just write that shit myself without a framework for all the pain that's going to cause.
Note: I don't write a ton of Rust, for reasons that are maybe kind of obvious. I reach for it whenever C seems correct, which is rare but not never (for me).
> dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang),
Rust supports golang style message-passing concurrency if you want it[1]. I'd argue Rust mpsc channels are actually more powerful than Golang's and add richness to message-passing concurrency modeling.
[1]: https://doc.rust-lang.org/book/ch16-02-message-passing.html
Yeah, I don't get the hate here. Rust's channels are just as powerful as Go's, and there are even implementations of them in the futures crate that implement the Future trait, so you can await on them and effectively get the same behavior as "blocking" on a channel in a goroutine, without having a bunch of blocking native threads.
I'm not going to lie, my first response was:
Wait, what, you think we need another web framework?
.....buuuut, if you spend more than 5 second actually reading the article...
> This doesn't exist right now, and I'm not sure if anyone else is working on it. All paths seem to lead me toward "whoops I guess I'm building a web framework." I hope someone else builds one, too, so we can have multiple options.
...
> My toolkit is called nicole's web toolkit, or newt. It's available in a public repository, but it's really not usable (the latest changes aren't even pushed yet). It's not even usable for me yet—this isn't a launch post, more shipping my design doc
ie. -> https://git.sr.ht/~ntietz/newt/tree
Is where you can find the code, for what they're trying to make, to fill this gap.
Sure. Not a web framework. An all in one opinionated good out of the box defaults like rails.
Yes, there's no django/rails for rust.
Or go. Or clojure.
In fact, a lot of people have tried to make all-in-one frameworks, but usually the way the wind blows is that doing something specific is easy, but doing something flexible and generic is hard, a lot of work, and unless you're being paid to do it, it's a loveless job that eventually you get sick of and abandon.
I feel like if you're really going to go and write a rails clone, you need to spend a little bit of time digging into some of the other failed attempts and reasons they failed (eg. 1, 2, 3) first.
The landscape is littered with aborted rails clones.
It's perhaps... fun, but ultimately futile and naive, to think you can be 'the one that makes it' when so many others have failed, if you don't take the time to understand why so very very very VERY many attempts to do this in many languages has failed.
(NB. Not to pick on clojure; I could have picked a bunch of go examples instead, but I guess the clojure failures have been particularly visible to me since I use clojure, and it's a place where, like rust, currently there are a lot of 'bits and pieces you can assemble yourself' and it feels like, surely just slapping them all together in one package can't be that hard...)
[1] - "Clojure needs a Rails" https://news.ycombinator.com/item?id=32288291 [2] - "A Rails like framework for Clojure." https://news.ycombinator.com/item?id=822210 [3] - "Luminus – A Clojure Web Framework" https://news.ycombinator.com/item?id=22852375
> I feel like if you're really going to go and write a rails clone, you need to spend a little bit of time digging into some of the other failed attempts and reasons they failed (eg. 1, 2, 3) first.
The idea of creating a "one man framework" like Rails in a systems programming language like Rust is a very tricky one. I don't think you can mimic the best productivity features of Rails without metaprogramming. Yes, you can do something like it, but the abstractions would leak all over the place making it uncomfortable for a Rust developer and not good enough for a Rails developer.
So strange reading all the comments here saying that Rust is not a language for "lazy developers".
I'm an incredibly lazy developer and Rust only makes me lazier. I can pretty much turn off the part of my brain that deals with "programming language" stuff and put all that energy towards the part of my brain that deals with "building stuff" whenever I write code in Rust, because I have a high level of confidence that the language itself isn't trying to make me shoot myself in the foot at every turn.
Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes. It doesn't get any lazier than that.
On the web framework topic: Rocket is the greatest "lazy developer" web framework I've ever used.
> I'm an incredibly lazy developer and Rust only makes me lazier
You can't be that lazy, or you would use a language that doesn't force you to do memory management.
> Rust is the only language where I can open something like Notepad without an LSP or highlighting
This is a very weird and arbitrary qualifier that seems designed to filter out other languages with type systems.
> force you to do memory management
This is not my experience at all. I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice).
Your second comment is a very weird sentence that is very difficult for me to grok.
> I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice).
Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load.
My second paragraph is pointing out that "where I can open something like Notepad without an LSP or highlighting" is a strange qualifier. Why does it matter if you don't have semantic analysis in your editor? You certainly didn't explain it.
> Worrying about lifetimes
Again, not my experience at all. I simply don't think about any of that stuff when I write Rust, all my mental energy can safely go towards working on whatever I'm building.
If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.
> Again, not my experience at all. I simply don't think about any of that stuff when I write Rust
Your subjective perception is not reality. You have to think about it, or your programs will be incorrect. The mental load may be low to an experience Rust programmer, but it is there, and it's very intrusive to Rust beginners like myself.
> If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.
That's not relevant. Lack of external indicators of cognitive load does not mean that it's not happening.
Glad I noped out of this particular bad-faith subthread last night.
I am pleasantly surprised to see however that this unfortunate subthread produced interesting and well-intentioned comments from others.
In most Rust code I write, I never have to use an explicit lifetime marker other than ‘static (which is more of a global const thing). It’s really only something you have to worry about under certain conditions.
> I'm an incredibly lazy developer
> Watch the literally hundreds of hours of me live coding in Rust on YouTube
Your definition of "lazy" seems quite different from the standard definition.
In my view, the average "incredibly lazy developer" of 2024 tries to have an LLM write most code for them (probably in JS/TS/Python), doesn't notice the subtle bugs introduced by said LLM, and ships straight to prod. If using an LLM fails, they go back to StackOverflow to look for an answer that they can copy-paste. When that fails they give up and ask a less lazy developer for help. At no point in this process did they read the documentation for the language/framework/etc they are using to accomplish their goals.
> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load.
That's why I just... don't. I use `clone` liberally. That's it.
> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load.
As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. If you know that using global variable is often a bad idea, then you are, in some sense, worrying about lifetimes.
I first learned this in the mid/late 90s as my Perl4 cgi scripts started to grow beyond about a screens worth of lines, and it really solidified into an almost unconscious background task as I wrote code once I started writing a lot of Perl5 apache mod_perl stuff a few years later.
These days, I find myself experiencing slight cognitive dissonance writing tiny Arduino sketches with a bunch of global vars declared right up the top.
> As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though.
Yes, to a much smaller extent. Rust's object lifetimes, for all the performance gains you get, add on a layer of additional cognitive and development overhead that is simply not present in memory-managed languages.
> Rust's object lifetimes, for all the performance gains you get
Lifetimes are not about performance gains. They're about correct behavior under concurrency, which you have even on JS with async-await.
Heck, let me correct that: even under programs without concurrency it's very easy introduce subtle bugs due to shared mutable state (something as simple as having a global mutable variable, you don't even need concurrency to mess that up, concurrency just introduces more issues like race conditions).
> cognitive and development overhead that is simply not present in memory-managed languages
No, the cognitive overhead is there, you're just ignoring it (and thus more likely to introduce subtle bugs).
If anything, Rust lowers the cognitive overhead by taking care of that for me statically at borrow check time.
Lifetimes are just types (literally). If you think lifetimes are cognitive overhead, so are regular types. Same argument could be used there since types are "cognitive and development overhead that is simply not present in dynamically typed languages". But I wouldn't write anything beyond a few thousand lines of code without them.
When I write Rust I spend more time thinking about types than about lifetimes.
> As soon as you start writing large enough programs
...or small enough programs!
I fought a lot with the borrow checker when I started learning Rust, and then I learned to embrace it. The borrow checker only occasionally bugs me!
As I write more embedded Rust and Rust for WebAssembly, removing implicit dynamic memory allocation forces me to think a lot about lifetimes again.
Laziness with a long view: I probably won't have to rewrite it, and if I do, it will be easy. I can write code like that in Python or something, but I have to be on my best behavior to do so and that's not lazy.
Using notepad for code is just masochistism though
> You can't be that lazy, or you would use a language that doesn't force you to do memory management.
Eh, depending on what you're building you don't do much if any memory management in Rust. You just declare what you want and it's automatically released at the end of scope.
Yes I know the borrow checker. With experience it stops getting in the way while catching the occasional bug.
And no, building linked lists or recursive data structures are edge cases that you don't need to develop for most applications.
Some people are comfortable offloading mental effort to a compiler. Others suffer from anxiety at the suggestion.
I'm the other way around I guess - a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python and JS at work. Part of it might be the terrible tooling story in each of those language ecosystems as well.
Last week I deployed a Ruby change where a missed comma between two strings in an array did not get picked up by any of the automated tooling or by 3 other team members who code reviewed my change, and ended up cutting 50+ sev2s at 10pm.
AWS folks can probably guess which internal tool I had to touch that requires Ruby.
(I was on call, fun times)
> I feel a lot of anxiety when I'm forced to touch fragile bits written in Ruby, Python, and JS.
I resonate with you even with TypeScript, since it's just annotating types but not the true value under the variable. You would have to go to a greater extent to make sure that everything from outside (library code, parsing HTTP responses, database queries, etc.) conforms to your annotated types. Even in the same project code created by other people, I often doubt the validity of the types, asking myself questions like: Should I validate this? What if this has already been validated, thus making mine a performance waste? Does this object contain extra sensitive information that could be leaked when used in a logger?
After having experience with Rust, working with TS feels like navigating a minefield where every refactor could detonate hidden bugs or behavior collectively accumulated by all the historic code and dependencies, small or large.
I haven't had this experience with TypeScript. In the projects I've worked with, we turn on strict mode and heavily discourage using `any`. I generally feel pretty confident that the type annotations match the runtime values.
> Rust is the only language where I can open something like Notepad without an LSP or highlighting, write code for an hour without testing or compiling, and then run clippy a few times to see and make the suggested fixes.
> anxiety when I'm forced to touch fragile bits written in Ruby
Wild, because the first sentiment is exactly how I feel about Ruby.
Together we would be unstoppable :)
I agree with this 100%. Rust is the most effective language for the “laziest” of developers.
> It doesn't get any lazier than that.
Uhh have you tried Cursor compose?
Yet another one?
A lot of commenters are really getting hung up on the author's use of 'lazy'.
When she says lazy, she just means that she'd like a web framework that takes care of the most common and obvious schleps that are needed to create a web framework, like routing and so on. Once you get those schleps out of the way, there's still tons of work that needs to be done. Nothing lazy about that.
It all makes sense if you consider laziness here to mean the same as in Larry Wall's three great virtues of a programmer.
[flagged]
I wrote my first web app in Pascal as a CGI because that was what I knew. That app turned out to become the most popular Turkish social platform for the following 25 years.
I coded that app in 3 hours. It was very crude as you can imagine. But, it did its job. If I had to start with a “better” platform that I didn’t know, I could have spent days or weeks to learn and may not have released anything in the end because I got bored.
Don’t discount a language for a certain type of application because you think it’d be harder to work with than something else. Familiarity goes a long way.
For new web applications, why recommend alternatives to Next.js?
How do you convince someone to use an alternative? The knowledge needed to understand why will help you get close enough in Next.js anyway.
1. Lots of dead ends. Fetch cache limit for example. Cant replicate prod page caching behaviour in dev. Etc. Many issues with 100 thumbs get abandoned.
2. NodeJS. Not everyone likes it.
3. It is slow. Yes it is! Try to get good web metrics with Next I dare you!
4. Premature release of App Router. Will they do something like that again.
why are you fealung with cache at all in a wrb context? that's what CDNs are for.
React, like Haskell creates new problems you need sophisticated solutions for.
CDN is for content. Useless for say a Google search type problem. So I call an API endpoint for data in my component. But what if I get rendered 600 times? Well luckily I have memoized the call! As long as it was under 2Mb that is.
I appreciate that you’re getting to the crux of the matter instead of downvoting.
In our experience elevating the web metrics in Next.js takes the same expertise as doing it in any other framework. Our experience with Vertx and Microsoft’s dotnet web frameworks have been good, but Next.js got us to a fast, featureful, performant website sooner and with more flexibility around requirements. I won’t pass judgement on rust frameworks I haven’t used, but it’s just to say that in an honest accounting, a naked backend framework is less than half the product when you’re talking about web applications actually worth making with original ideas. Unless you work at Google.
Ok I will bite. How did you manage to get scripts to defer?
Code that we need later is `async import`-ed.
But for SEO, shouldn't Google be given a 100% pre-rendered, essentially static page? Next.Js plus our CloudFront seems to just support this.
I know TypeScript is available but not everyone can be convinced to adopt JS. I was part of that group until recently as I have been using strongly-typed language all my life.
The npm dependency ecosystem is extremely tangled. I work with node frequently, but there's plenty of opportunities for bad actors to introduce abuse and I'm wondering when the other shoe will drop.
Next.js is not nearly flexible enough. I'd never use it. It feels like rails, but somehow even more tightly coupled than that.
I am wondering why there is resistance to adopt GraphQL and a React-like front-end. Essentially, you no longer have routing/templating/web-server/etc... and you get lots of things handled for you (like authorization). You pretty much remove the web framework concept and just work directly on your application functionalities. With stitching, you have a gateway that add up various graphql gateways. So you could mix and match rust with other microservices or whatever.
I don't see myself doing it any other way these days.