4 ms·
I’m sure I’m not the only one wondering, but why would someone want to write web code in Rust. To be fair, as a web developer by day, I still haven’t gotten ar
by 40four 6y ago
I’m sure I’m not the only one wondering, but why would someone want to write web code in Rust.
To be fair, as a web developer by day, I still haven’t gotten around to trying to write any Rust in my free time. I am curious though. But after browsing the docs of actix-web and rocket, it seems a bit of a reach to say you could use these solutions in place of monolithic frameworks Django or Rails.
Maybe if they had said they could take the place of an Express/ Slim / Flask app I wouldn’t have rolled my eyes as hard. Wouldn’t these battle tested ‘micro’ frameworks be a better comparison?
Anyway, since I really know next to nothing about Rust, what would be the benefits for me to pick say, Actix-web over Slim to start a new project?
I get the feeling the best reason would be I’m already an experienced Rust developer and want to leverage that domain knowledge. Or maybe a team that already writes a lot of Rust wants to keep consistency over their repos.
- couchand 6y agoThe best part about Rust is the type system. For one example, in a web app I'm building for a client, we have two types to represent invoice ids: one for the invoice id that came back in a response from the API, and one for an invoice id that a user is asking for. They are distinct because we know that an InvoiceId refers to an actual invoice in the system, and a UnverifiedInvoiceId might not. Both of them are distinct from a CustomerId or any other id. This might sound like it could get cumbersome fast, but it's actually really simple in practice, due to clever uses of traits. UnverifiedInvoiceId implements rocket::FromParam, so I can deserialize it from a URL parameter. InvoiceId is only created in the serde::Deserialize implementation of an invoice-returning API response. So a (significantly simplified) endpoint in the app might look like: #[get("/invoices/<unverified_invoice_id>")] pub fn get_invoice_by_id( unverified_invoice_id: UnverifiedInvoiceId, api_conn: ApiConnection, ) -> HtmlResponse { // API "search" methods take unverified user input as parameters let invoice = api_conn.fetch_invoice_by_id(unverified_invoice_id); // API "lookup" methods take verified ids let line_items = api_conn.fetch_invoice_line_items(invoice.id); render_invoice(invoice, line_items); } I can't accidentally switch up things that don't belong together, even though under the hood they're all just unsigned ints.
- nivethan 6y agoBusiness logic is where Rust would shine and rust feels nicer to work in than java.
- mavelikara 6y agoWouldn't Kotlin and Typescript provide many of these benefits on a much more mature ecosystem?
- oftenwrong 6y agoOne time I made an authentication system for an application that had some types like PlainTextAccountPassword and HashedAccountPassword. The storage backend for accounts accepted a HashedAccountPassword only. This way it would be less likely that a maintainer would end up storing a plain text password. It is possible to do something like this in nearly any language with a type system.
- stjohnswarts 6y agoYeah, easy to make a class for that in Python and you basically have a new type. It can even check itself, although I'm not sure that's a great idea :) .
- g_delgado14 6y agoNone of this is unique to Rust - I can do this in typescript: Serde -> Zod (https://github.com/vriad/zod https://github.com/vriad/zod) Diesel -> Prisma Yet you expose yourself to concepts that are unique to Rust that do not enhance the developer experience (such as lifetimes). I don't need to worry about lifetimes in typescript and can just focus on shipping code. Lifetimes is just one example, but there are others that create more friction than they provide benefit IMO.
- steveklabnik 6y agoI agree that Express/Slim/Flask is a better comparison. But, to answer your core question, there are a few different reasons: * Performance. The simple, straightforward Rust code will often be much faster than the usual suspects here. Sometimes, I/O is your bottleneck, but sometimes it's not. Maybe you only move some backend services over. npm is an example of a company that did this; some high performance services were implemented in Rust because Node was struggling. * Consistency. Resource usage tends to be very flat. This helps with things like capacity planning, but also reliability (which is a later bullet point). * Cost. This is directly related to performance, but also on a different axis: memory usage. We've seen people switch code to Rust, and while the performance doesn't change things for end users, the extra overhead means smaller servers, or less servers, which translates directly into $$$. There are some big, not super public success stories here I wish I could tell you about, but a public example is Rubygems. They had a lambda doing some log processing, and the performance benefit of Rust made things fast enough to move it onto lambda's free tier. Infinity savings! (Though of course it was actually from $12,000/year -> $0) * Reliability. Back to the npm use-case, they had a lot of ops issues with Node. The Rust code ran for something like a year, year and a half, before ever having a single production issue. Static typing helps here, less variable resource usage helps here. * Static types. Some people have come to prefer developing in a language with static types. Rust doesn't have a monopoly here, but it is among very few languages that have many of its features, and many of them don't check those previous boxes. Of course, things aren't a panacea either. The ecosystem isn't as mature, even if this web page says it is. Async is great, but not perfect. Some people really do not like static types. Etc.
- 40four 6y agoI'll admit, the performance benchmarks on actix-web are very impressive! Thanks for the detailed response, I have an eyebrow raised :)
- MaxBarraclough 6y agoDoes Rust significantly outperform Java and C#?
- 6y ago
- Dowwie 6y agoI'll try to focus on a reason that Steve hasn't touched in his response -- investing in one's future. I'm a generalist who wants to use great tools for my work. I've built a variety of systems, not just web applications, with Rust. The more I use the language, the more I learn and develop greater capabilities to do more unfamiliar work. I am on the fence right now about diving into video streaming/processing but already have a foundational knowledge that will lend useful to a Rust-based solution. Embedded product development, too. And mobile. Rust is being used everywhere, now, with success. So, while you may get away with using slim for your web app, using Rust instead is a way of acquiring the skillset that is applicable across all software development. One may do web dev today, but security engineering tomorrow. Whatever the domain, Rust expertise carries over. Using Rust for web development is how you invest in a software engineering future. As a manager, one may argue that this is up to the programmer to do so in their own time, and not company time. Well, in response to that I recommend reading Steve's comment as to why you can't afford not to use Rust going forward. :)