I started learning Rust recently and usually start learning new languages by building different kinds of Hacker News clients with the language. This time I focused on a offline-first desktop HN client, that fetches items periodically and allows the user to browse it in a desktop app built with Tauri.
While developing this, I started writing a API with Actix Web at the same time, so the same service could be used directly in the browser, not just with the desktop app. So I found Actix Web to be the most supported.
However, I jumped into the RC versions (in order to use tokio >v1 which I was already using for other things, and you can't mix versions), while most human-written documentation (website, Stack Overflow, forums and such) were written for the pre-4 version. So I'm glad to see it finally released, and can't wait for all the documentation to/web resources to be properly updated as well so I can learn more about Actix Web.
"Actix was found by third parties abusing unsafe and when they were auditing most libraries found for Rust on the internet. When the unsafe code was audited it was found that on misuse, it can lead to serious vulnerabilities. So they opened a bunch of issues and added a lot of patches and PR’s in GitHub."
This is an easy mistake to make, but actix-web isn't actix, it's a web framework that uses actix. And while actix once had a controversial reputation regarding unsafety, the project has reversed its stance in the years since that quote was relevant and now appears to treat soundness violations with seriousness.
Hey bud, you are being really aggressive and disagreeable in here. At this point, I think everyone is aware that you, personally, would not recommend Rust or Actix. Loud and clear my dude.
Unless the HN API itself gets compromised, I'm not sure what can go wrong by running your own local HN client really (it only communicates with the official HN API). But happy to be showed otherwise.
For those who have been considering Rust for your next web dev project, it is a great time to give it a try. Actix Web is a mature offering with ecosystem, community and learning materials, including a few major book publications in the pipeline.
I love working with rust for personal/toy projects, and I've been really itching to find a good use case on the web!
The last I investigated, there were many gaps where one had to "roll their own x" - as compared to something like Rails, which comes with a lot of functionality (and has a huge ecosystem of libraries to support it for stuff that's missing).
If you're familiar with Rails as well... can you speak to what I'll be missing when I work with Actix? Some things I know I take for granted are the ActiveRecord ORM, the session framework, the availability of gems to handle various authentication systems, caching, and a ready "out of the box" browser testing framework.
I know I shouldn't expect anything close to what Rails has to offer, and for hobby projects I don't have an issue with that, but I'm curious about just how far things have come.
There won't be a Ruby-on-Rails or Django like experience with Rust for a long time.
My response has gotten fairly long, so I think I'm going to turn it into a blog post. Here's a start:
I can't tell you how far you may get with the ORM libraries currently available as I moved to parameterized SQL libraries some time ago. Others seem to get on just fine with diesel, the most popular ORM/query builder. It's very fast, too -- nearly as fast as the plain old paramaterized SQL libraries -- but parameterized SQL libraries are much more popular (at least 3 times more popular) if we were to just look at download stats. You can go a long way with those and roll a custom query builder helper should the need for it arise. There are a few popular async connection pools, deadpool being my favorite.
Actix Web had a fine session management solution, but it has recently gotten a lot of attention lately and a PR awaits for merging with v4 that makes it even better. Actix Web has a strong session management solution, with support for Redis already built.
In terms of authentication, there's a popular jsonwebtoken crate that handles all of the JWT related functionality. There are plenty of strong cryptographic hashing libraries for argon2, bcrypt or whatever you're looking for. There are oauth2 clients. There are hashicorp vault clients. Or, you could roll these clients yourself, if you were so inclined to. There are also systems such as those maintained by the ORY community, written in golang, that have intuitive APIs and can serve auth related purposes. Many options to choose from with regards to authentication and authorization.
There are at least two viable async http clients to choose from. You'll use either extensively.
In terms of caching, there's a pretty good redis client. There isn't a "cache aside" (aka cache-else-db) library in open source, yet. People roll their own and don't seem inclined to share them just yet. :)
Graphql story consists of 2 viable libraries, async_graphql and juniper. Neither is exceptionally better than the other, but async_graphql seems to be leading.
Testing in Rust is pretty good but relative to Python or Ruby it has a lot of room for improvement. I've learned a lot over the years through trial and error and would like to blog about it. The one situation that is difficult to handle in Rust involves end-to-end integration tests involving calls to 3rd party api's. If you wrote your own client, then you can design the client so that you can control URL's, but if you're using open source clients, you may not be able to control those URL settings. This makes it more difficult to route requests to mock servers. Using dependency injection and mock types is what people are doing at the moment to address this issue. There is a nicer alternative, and that involves running a mock server that handles request interception. This is a rather impressive category for open source development and anyone reading this should take a look at what people have done in go, node, etc.
I always wondered if the safety and correctness that Rust offers is needed in a CRUD application? Do you think it pays off to work in the extremely strict system where you can't just cast to any and move on with your product features?
This is something I thought about a lot before switching to Rust at Svix[0]. What I came to realize though, that there are no "casts to any and move on", but rather there are silencing real bugs and praying you won't hit them.
Almost every time I've ever tried to silence the type checker (in any other language) it resulted in a bug.
Does it make you slower? Definitely at times, but it's mostly OK, and the code is pretty damn clean. You can check out our repo to see how it looks[1].
Edit: we don't use Actix, we use Axum, but the same holds for Actix too.
You can in JS/TS and Python. Technically you could even do it in a language with a fairly strong type system like C# or Java by casting to object or dynamic, though the code using the cast object after that will probably be very unidiomatic.
Exactly what the sibling comment said, you can do it in many languages. Also, the comment I replied to suggested just that ("cast to any"), which is the context. :)
If you're writing software that will be long-lived with multiple developers, the safety, correctness and strict type system is absolutely necessary for maintainability and refactoring purposes alone. Even for a CRUD app (maybe especially for a CRUD app as you're marshaling objects of different types around, usually), and even when runtime speed is a secondary concern.
But a higher level language with a GC and good types would be more productive , I would suggest to also check the ecosystem not only the language, the access to documentation, and developers (if you need to build a team). From my experience big projects suffer not because of the language but because of bad architecture caused by inexperienced developers.
I don't disagree with the ecosystem argument, nor the argument that poorly thought out architecture is a big cause, as well. I don't think having a GC de facto makes you more productive and that's worth arguing about itself.
My point was that having the ability to perform "fearless refactoring" to improve architecture and adapt to changing needs of the software needs ruthless type system support to catch the non-obvious areas that you just broke and make sure that API contracts are still correct and to make sure you're not deserializing random stuff into `interface{}` or worse, `Any`, `Value` or `void *`.
We had strong types and languages that allowed that before Rust, I do not understand why would people push Rust everywhere and not focus on the stuff it is actually good at like low level stuff where performance and safety is needed.
Is not the safety (borrow checker) but the combination of: Bare structs, enums, pattern matching and some traits (like Into) that make a breeze modeling business rules.
Any web (or any RPC) facing app that needs high performance and security should consider using Rust frameworks (or go). They are far more efficient than the interpreted languages and 1 server can usually replace several in such cases. It's well worth converting 1 or 2 "small" microservices that require "significant" server side "work" in comparison to interpreted stuff like rails and python.
Once you acquire the capabilities to do the work efficiently with Rust, it's hard not to use it even for smaller CRUD applications. You'll have a stronger, faster system that uses resources efficiently. It's a good tool for team development efforts, too, as you refactor each other's code and quickly find out what requires fixing (way before releasing to production).
> Once you acquire the capabilities to do the work efficiently with Rust
The problem is getting to that point.
I only tried Rust once, two years ago. The type system was fighting me all the way: the types different libraries were using were incompatible with each other, there was no obvious way to properly convert between them, finding proper signatures and behaviors was pain as many things were in traits or macros etc.
A lot of this comes down to tooling and ecosystem maturity, so things may have improved.
I had a few really strong reasons to push through, but it is understandable why others decide not to. It hasn't been cheap. I ate sunk costs plenty by adopting too early. I get angry at how much better the ecosystem and resources are now than when I started!
This aside, you'll still battle with the compiler. As to what you're battling depends on what you're building.
I still write Python for quick scripts, but if it's gonna be a page or more of logic I give up and write it in Rust. Compile times for quick scripts, in practice, don't really bother me, and cargo is fantastic for "just work please".
Thanks a lot for this! actix-web is an amazing framework so far. I've started with the book zero2prod in rust, and using some type driven designed, rust's errors handling, actix-web's extractors and web::data feels like super good ergonomics.
I do feel like the docs could be expanded a bit more, I got stuck when trying to write a middleware for example.
I've been using the pre-releases for my web service and it has been rock-solid. I'm happy that it finally has been marked stable. That will definitely help a bit with dll-hell that you often see for unstable releases.
Anyone got experience using actix web vs rocket? My rough impression is that actix is focused more on performance, rocket on stability and developer ergonomics?
To me, rocket seems much more "batteries included" than actix, which requires you to look around or build your own things if you want to build a bigger app. I'm thinking about authentication, templates, etc.
I'm not really a web dev, though, so I may be wrong, or missing something.
Why would I choose Actix over ASP.NET MVC with which I'm already familiar and works fast and reliably and doesn't require me to learn another language?
There's no need for a deterministic memory managed language in web applications. GC languages such as Java and C# work just fine there.
What of people that don't use C#? What of teams with libraries already built in Rust? Also I've been on teams building web apps in Java that were more complicated than just CRUD. We had one where the GC behaviour of Java was decidedly suboptimal as the applications would for for minute long GCs due to large in memory caches
There are very few developers that aren't fluent in C# or Java or another C derived language. The learning curve for Rust is pretty steep, since the deterministic memory management requires new concepts to be mastered whereas with C#/Java you can just create objects left and right without having to worry about when to clean them up.
C# and Java have vastly more libraries available to them than Rust.
Having sub-optimal behavior is usually a sign of poor design IMHO. But it's difficult for me to pass judgement without seeing the application code. Also, I doubt that Rust would be of any help in this case.
Is it the time to consider Actix (or any other rust web framework) for production?
I'm planning for a rather ambitious project, but not sure if I should choose rust (the new shiny thing) or stick to good ol Go (while I do have some issues with it)
Plenty of companies (including Microsoft IIRC) are using Actix in production. At this point it's not that shiny and new.
Actix is the most mature of the Rust web frameworks. Axum is new but very promising. Rocket is popular but development is stalled at the moment since the main developer has been going through some rough times.
Rust is plenty ready for production. Choosing between Go and Rust for web backends is really choosing between a more complex language that allows you to have powerful abstractions and has a focus on correctness vs. A simpler language that is looser and prefers “verbose but simple” code.
From a language features perspective, Rust. Personally I find building up the rigor to do correct error handling in Go's approach or C libraries with seperate error functions is its own kind of complexity, however.
Google and most other software kings chooses C++ for backend. If you think you know better than them feel free to use the hype lang of the day. Rust will be gone in a few years.
I don't think that conflicts with my comment. Just because Rust is ready for production doesn't mean that C++ isn't also ready for production. For what it's worth, Google are increasingly choosing Rust for new projects. As are Microsoft, AWS and several other large software companies. Obviously it doesn't usually make sense to rewrite old projects that are already in C++.
We looked into Rust at our company (top 100) and it's clear it's not ready for production systems. It just puts developers into a huge tar pit fighting with the compiler for anything more than a simple hello world app. If it actually lived up to it's hype it would have been used to rewrite browsers, servers, OSes etc. But C/C++ are still the kings of system programming.
It is and will continued to be used in areas where security is important.
This is from November 2020, I’d expect them to use it even more by now:
> But we also use Rust to deliver services such as Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon CloudFront, Amazon Route 53, and more. Recently we launched Bottlerocket, a Linux-based container operating system written in Rust. Our Amazon EC2 team uses Rust as the language of choice for new AWS Nitro System components, including sensitive applications such as Nitro Enclaves.
> The whole reason for Rust's existence was for Servo so using it as an example of its use is disingenuous at best.
Mozilla wanted to push the boundaries of what's possible with a browser rendering engine and they felt like they couldn't do it safely with the existing languages, so they created their own. Doesn't that, alone, speak volumes for how useful Rust is?
> C/C++ runs 99% of the the worlds software including OS's/browsers/GUI's/Compilers/Virtual machines/Games/Aircraft/Spacecraft etc etc etc.
Now you're being disingenuous. Rust is still so young compared to those languages! Not to mention that the industries best served by Rust move glacially slowly compared to, say, the web. I bet we'll see significantly more adoption of Rust in 10-15 years.
While Rust is being used on the system level for Android, there are no plans for the time being, to ever support it for app development on the Android NDK or AGK.
Honestly it's pretty clear from your weirdly large number of negative comments on here that you've never taken a serious look at using the language for a real project. You just have some weird axe to grind with it.
That's cool, I guess, but also not particularly interesting.
Anecdotal but my company is using it for a new project and we just hit production about a month ago. So far it's been great with 10+ million requests handled per day. Looking forward to upgrading to 4.0
I made another post in this thread, but I'm using it very happily for a few microservices that power https://fakeyou.com (one is the main web monolith, the other is a websocket to pubsub bridge for an upcoming feature).
- I've found it extremely fast to work with and iterate.
- I've been able to meld a lot of complex use cases to it. In-memory caches, worker thread pools, etc.
- It works great with testing, CORS, MySQL, Redis, forms, json, uploads, S3 clients, etc.
- Serde + the expressive type system is incredible (this is more about being able to use Rust, but Actix plays so well with it).
I'm using sqlx for nearly typified SQL checked at compile time. If we get a jOOQ-like DSL, I'll be overjoyed.
for request schema, do you know how rust/ actix supports protobuf? I find protobuf great for rapid prototyping, and using monorepo for both frontend + backend makes it even better for api consistency. my search shows there are 2 major libraries but the de factor parsing library doesn't support it (Serde)
also, I'm interested in how you structure your code. is everything a crate? or you work in a giant namespace with different structs (sorry if this doesn't make sense I don't know much rust)
No idea why you're downvoted/flagged, these are perfectly valid questions.
> for request schema, do you know how rust/ actix supports protobuf?
That's a great question! The serde annotations make it look like it should work. If not, there might be a plugin for it. Actix has a rather vibrant ecosystem of utility crates.
I've used Prost for protos once before (it felt like the more mature option), and the build integration was seamless. I was frustrated with how the IDE handled it at the time (Clion+Rust), which is one of the reasons I'm not using protos in Rust today. The IDE couldn't work out the types and everything touching the syntax tree near protos was opaque to the IDE. It was over two years ago the last time I checked the status of protos in Rust, so there's a good chance the situation has improved.
I didn't use Prost with Actix in particular, which is why I can't really provide insight there. It should be quick to set up a test.
I'm using two monorepos: one for frontend (yarn/typescript/react for three websites) and one for backend (all Rust; two servers and seven jobs). If I'd lumped it all together, I would have investigated protos more seriously. I should probably investigate using them again in the near future.
> also, I'm interested in how you structure your code. is everything a crate?
I'm using Rust workspaces to organize the backend monorep. I have about ten binaries, and five library crates that are shared between the various binaries. I also have a few vendored packages that aren't available on crates.io (newrelic-telemetry-sdk, etc.) I was told Bazel does a good job with build caching, so I'll investigate using that soon so I'm not always rebuilding the world.
> or you work in a giant namespace with different structs (sorry if this doesn't make sense I don't know much rust)
With the way modules work, there's next to no need for that in Rust. It's one of the most hygienic import systems I've used.
Overall, I'm extremely happy with the setup and it's been really productive for me.
> Is it say possible to run a production quality server that can handle hundreds of thousands of concurrent users on digital ocean lets say?
Absolutely. I used to work as an SRE on Mozilla's WebPush infrastructure. Every running Firefox in the world establishes a connection to it; that means it peaks at tens of millions of concurrent connections every day. We could easily handle hundreds of thousands of connections on a couple CPU cores and gigs of RAM.
Although most connections were usually idle, we also regularly pushed messages to every connected client (e.g. when a collection in our remote settings service was updated).
What libraries like this could you really extract "performance/$" from? Sounds like a mostly financial metric.
It's so situational that you cannot say outright exactly how much something cost in different scenarios. Doing so requires strict metrics about other things at the same time, and could only be done as an analysis of what happened, not what will happen in the future. Subtle bugs and things like just using a different data structure would impact the performance, down to the tiniest detail.
If you're so adamant to see metrics, you could use TechEmpower's framework tests, latest one placing 5th Actix in the "Composite score" (https://www.techempower.com/benchmarks/#section=data-r20&hw=...), as a result of being pretty high up in the specific benchmarks. But even with that information, it doesn't mean it'll be the 5th fastest framework when you use it.
I guess the point is: do you own benchmarks for the specific areas where you need it to be fast, calculate what your costs would be for hosting it, and you'll have your "performance/$".
The truth is there isn’t an awful lot of difference between the artist frameworks. Actix-web was one of the first though, so the reason to choose it over others would be that it’s a bit more built out feature wise.
Actix-Web actually differentiates itself from most other Rust servers in that it runs multiple per-thread runtimes as opposed to a single work-stealing runtime. This probably doesn't matter to most, but if you really care about latency, it might be a factor to consider.
I've used both very extensively and while I like the direction c++ is headed, I know a lot of people don't, I couldn't disagree with you more. Writing reasonably fast rust that doesn't crash is far easier than writing any kind of c++ that doesn't crash. Copies are a real problem in rust though, they are definitely difficult to avoid without jumping through hoops sometimes but I haven't hit any yet that are a real world show stopper with good upfront design and architecture. C++ just has too much baggage and footguns to make it truly productive on larger teams osit
> Seriously look at modern C++ it is very easy to develop high performance software in a modern language.
I'm a full time c++ developer that does Rust as a hobby, and I'm asking myself if we are talking about the same language. C++ is a clusterfuck of obscure features, 1 million different build systems and hacks upon hacks for even simple things like include guards, forward declaration of classes to not completely kill your build times and _many_ more daily struggles that are simply none existent in Rust.
I started learning Rust recently and usually start learning new languages by building different kinds of Hacker News clients with the language. This time I focused on a offline-first desktop HN client, that fetches items periodically and allows the user to browse it in a desktop app built with Tauri.
While developing this, I started writing a API with Actix Web at the same time, so the same service could be used directly in the browser, not just with the desktop app. So I found Actix Web to be the most supported.
However, I jumped into the RC versions (in order to use tokio >v1 which I was already using for other things, and you can't mix versions), while most human-written documentation (website, Stack Overflow, forums and such) were written for the pre-4 version. So I'm glad to see it finally released, and can't wait for all the documentation to/web resources to be properly updated as well so I can learn more about Actix Web.
Great work on creating a nice library folks! :)