8 ms·

Awesome news! Rust is easily the best programming experience I've had--the language feels incredibly well thought out, common tooling like doc generation and de

Awesome news! Rust is easily the best programming experience I've had--the language feels incredibly well thought out, common tooling like doc generation and dependency management are included with the language, and the compiler takes full advantage of language features such that my editor's linter is able to detect most mistakes I make and the language itself guards me from doing anything obviously unsafe. I thought the rewrite-everything Rust people were annoying and that turned me off initially, but ever since getting involved with the community I've found that it's full of lots of very passionate people working on a stunning variety of interesting new projects. You really feel like you're on the ground floor of the next generation of systems programming languages, enough to where I've even considered replacing my habitual use of Python with Rust considering how easy it is to write. Seriously, it's worth your time to explore. If you have a spare evening and want to be enchanted, highly suggest giving the Rust book a gander: https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/

haskellandchill 6y ago
It’s booming. I’m considering making Rust or Haskell a requirement for my current remote job search. And given that I have no strong salary requirements it’s actually going to work, could not have done this 4 years ago.
manishsharan 6y ago
serious question : would you recommend Rust for CRUDdy type of web applications -- stuff where mostly you are firing off prepared statememts at a SQL db and then applying business logic to result set. This is what most J2EE apps do currently.
- akritrime 6y ago
  hmm, no. While compile-time type check[0] for SQL queries changes your whole experience of how you do SQL, at the end of the day creating an webapp in rust is not as easy or mature as any of the other languages more suited for the task. If you want to learn, then its fine. But if you are newish to rust and want to do your next CRUD app at work in rust, I don't think its going to a good experience. [0]: https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx
- tempest_ 6y ago
  I mean you could certainly do it in Rust. I am not sure I would recommend it though. The dev time for rust will naturally be slower because the developer will have to take more into consideration. Additionally while the community is growing rapidly you wont find the same depth of ecosystem that you have with Java. Client libraries will be half baked and still be a work in progress a lot of the time. If the business stuff is not performance or time sensitive it would probably be better to use something like Java/Go/Python, maybe elixir, that will have good turn around time with reasonable performance. A good litmus test for the moment is probably "Would I write this in C++ five years ago?" if yes Rust might be a good option today with a few caveats, like GUI or GPU programming still being in their relative infancy in Rust.
- bluejekyll 6y ago
  You're in a Rust thread, I think the general response is going to be, "Yes!" And I personally, say yes. But that comes with some caveats. You will be entering an ecosystem that doesn't have all the libraries that folks coming from the rich history of Java has, so you will most likely be signing up for some extra work. But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature.
  - jariel 6y ago
    "But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature. " Ok, so this is an 'opportunity' for some, but a 'big cost' for others. So remember there are very few Rust devs out there, it is a little bit hard, and though a good chunk of devs might jump at the chance to learn, others, not so much. It would be a really hard thing to rationally do a 'crud app in Rust' at this moment in time due to all the above reasons. There's a lot of added risk for really no benefits. If you have a core team that has the skills, ability and is willing to commit to it, then maybe. But we have to think beyond that, when you need another 100 devs ... and people maintaining it ... one can see how other things factor into the equation. If there is some specific reason and the conditions are right, and if that reasoning is not warped by our own natural tendencies to 'want to use Rust' then there might be an opportunity ... but generally not. As team members get more excited about 'the problem they are solving' and less 'the tools they use' - you might see an inclination towards other tools, for the most part, at least today, for CRUD-ish kinds of things.
    - bluejekyll 6y ago
      Everything you stated, is literally the reason I said there are caveats, I find it interesting you decided to expand on that, but quoted the second part, pretty much out of context. Nothing you said is wrong per se, but it’s also not entirely accurate. First, there are very good db connection libraries available to Rust users, with good connection pooling options. Second there are good ORMs if that’s something you enjoy using. Third there are excellent application server options in Rocket and Actix available. Your comment implies these don’t exist. It’s more the edge cases, and the things outside the DB that will be issues. And even there, you’d need to get into specific areas that would cause issues due to lack of available implementations. In terms of developers out there that want to work with a language, there’s no better response to that than it’s “the most loved language”, and that may translate to many people adopting and expanding its use.
- steveklabnik 6y ago
  We are doing some web backend stuff in Rust at Oxide, my colleagues gave a talk on it: https://www.youtube.com/watch?v=EmSjZbSzA3A https://www.youtube.com/watch?v=EmSjZbSzA3A The TL;DR is it may or may not make sense for you. Engineering! We are finding it valuable, but you may have different needs than we do. Ecosystem maturity is variable.
- tmountain 6y ago
  Can't speak to Rust, but this is a sweet spot for Golang for sure.
- heavyset_go 6y ago
  The ecosystems that support creating CRUD apps are more mature in other languages.
- mamcx 6y ago
  I have a app that have been ported from old python -> f# -> rust (e-commerce like) and the transition was great (https://www.reddit.com/r/rust/comments/hh9tz6/does_rust_have_a_production_ready_web_server/fw9mfb5/ https://www.reddit.com/r/rust/comments/hh9tz6/does_rust_have...). You need to pay attention in how align the whole software stack. Pairing Rust with tailwinds and htmx or Hotwire simplify so much stuff is like cheating. For regular CRUD flows having enums/traits/iterators make domain modeling very good and found is more productive to me than F#/Python at the domain layer. I do my own micro SQL-orm layer (I have the need to talk to +6 RDBMS and be dynamic at runtime), and most db libraries in the rust ecosystem are mature enough now. I find recently the whole auth is not as mature as you find with Django (aka: Not need to code part of it, you can certainly do it manually), but anyway is now better to offload to key cloak or similar.
  - Smaug123 6y ago
    Could you comment a bit more on how Rust let you model the domain better than F# did?
    - mamcx 6y ago
      The thing with F# is that (idiomatic) models/functions rely on type inference, and eventually is hard to see what is the flow without look at the IDE. Rust making type annotations explicit with minimal inference is much clearer. Also, the fact I can do mutation + imperative code locally yet give a functional feel make some hacks around this on F# unnecessary. But probably the biggest thing is that Rust make idiomatic things like conversions with From/Into/AsRef/etc instead of rely in your own conventions, making code more readable in the long run. Other source of simplification is serde. A lot of my stuff is transfer/(re)encoding of data and have a "de facto" idiom for this help a lot. One thing that F# make far easier and I miss much is the sequences (https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/sequences https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...). Making iterators is boilerplate and wish Rust have generators in stable. I found a decent library for this in https://lib.rs/crates/genawaiter https://lib.rs/crates/genawaiter but is not the same as have it in-build.
- ragnese 6y ago
  I currently do it and have no regrets, but I don't require a lot of fancy stuff that you might find the Java ecosystem. If you don't have any need for concurrent sharing of data and never really miss having destructors in a managed language, then I'd guess that Rust wouldn't be a great fit for a CRUDy backend. Scala and Kotlin are great choices there. They have good type systems (everyone loves Rust's enum types, which are just ADTs and exist in many other languages as well), they have garbage collection- so no borrow checker headaches, and they have the massive Java ecosystem if and when you need it. On the other hand, all programming languages are greater than the sum of their parts. Rust is more than just a checklist of "borrow checker, fancy enums, no exceptions, move semantics, etc, etc". You might just love the language even if it's not "objectively" better for your use case than something else. That's where I am. I spent years doing C++ and I instantly fell in love with Rust. It's not perfect, but it's usually my first choice when doing almost any project. I only ask myself "Is Rust such a bad fit for this task that I'm significantly hindering myself?" and/or "Is FooLang so PERFECT for this task that not using it is stupid?".
- JeremyNT 6y ago
  I'm mostly a rails developer and really want to get into Rust. I went through the tutorial and did some practice on Excersism. I'm not a rust expert but I enjoyed working with it and learning about it. With that disclaimer: as of now, what rust lacks is a comprehensive framework for web development. I'm sure your story in the J2EE world is similar to rails: you have libraries that you can use to abstract away a lot of repetitive things such as authentication. You probably also have a framework-aware test suite that integrates with something like Selenium. You may have abstractions around javascript build systems like Rails' webpacker that allow you to easily integrate SPAs directly into your app using the same overall tooling. There's so much code you don't have to write, and you probably don't think much about it, and you probably just take it for granted. This is not the story with Rust. There are some frameworks such as Rocket you can reach for, but when I evaluated the situation ~6 months ago I realized I couldn't justify using Rust for this yet. From a web development perspective, there was just too much busy work you'd need to do. I don't think this is an inherent limitation of the language, by the way. I think Rust is a lot of fun to work with and I wouldn't hesitate to use it once a more robust library ecosystem is developed for this use case. I'm always keeping an eye open for places where it would fit what I do, like a small performance-sensitive microservice for example. The type system is powerful, it's great (as a Ruby developer who last worked with C++ a long time ago) to work with a compiled language again. The type system, Rust linter, and compiler together catch many classes of trivial errors that you need to test against in Ruby. I hope it'll get there one day!
  - torgard 6y ago
    actix-web seems really interesting, just from some cursory reading. Also, from a performance standpoint, it seems to be _really_ good: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ This example in particular piqued my interest: https://github.com/actix/examples/blob/master/async_pg/src/main.rs https://github.com/actix/examples/blob/master/async_pg/src/m... I have no experience in Rust whatsoever, but I feel inspired to try it out.
- redis_mlc 6y ago
  No, because rust is extremely picky about types and casts, which makes for a large learning curve for no real advantage in text processing. Expect to be much less productive until you get your own toy programs working.
- cultofmetatron 6y ago
  don't get me wrong, I love rust and find it a great language for doing systems level stuff but it would be my last choice for a crudy type web application. Those are intrinsically IO bound. Sure, you might find a noticeable improvement if you're using something really slow like rails without any caching but there are plenty of garbage collected rapid development languages that will be fast enough that the visible performance difference will be dwarfed by the IO bottleneck. There are already several languages that server that niche better. I myself use phoenix/elixir which is batteries included. I have a nice toolbox of production ready libraries. I can prototype/build endpoints much faster than I would in rust and the sub 200ms req/res times (including the database call) is plenty fast enough. That said, there are a few things I'd consider rust for. 1.cpu intensive jobs - elixir and any language with c interop have rust interop and I'd be happy to delegate those jobs to a service written in rust. 2. optimized large data structures, discord did something akin to this for their chat system 3. serverless functions - having no runtime or garbage collector makes for a gloriously fast cold boot if you're into that sort of thing. In short, While you CAN user rust for web development, I dont' think its appropriate for most web development related use cases if you're trying to develop software for a client. IF its for fun, Then by all means, go nuts! :)
  - zozbot234 6y ago
    > Those are intrinsically IO bound. Rust has a great async story compared to other languages, which benefits IO-bound workloads even more so than CPU-busy ones.
    - andrewflnr 6y ago
      Not compared to Elixir. It's hard to beat lightweight processes for concurrency. I've used Rust, but I'm doing my webapp in Elixir.
    - coder543 6y ago
      I disagree. Saying that it is "great" is really overselling it at this point, unless the languages you're comparing to are mainly C or C++. I would also toss Ruby in that category for now, but they seem to be working on making async better with Ruby 3+. When compared to Python, JavaScript, or C#... Rust's language support for async isn't really that impressive to most developers, although the implementation has some technical characteristics that are nice for people who care about the low level details. The ecosystem is pretty lacking, even though it is much better than it was a few years ago. Compared to the aforementioned languages (including Rust), Go and BEAM-based languages are just on another level. I'm sure both Rust's language ergonomics and the ecosystem will improve over time, but Rust's goals also make it unlikely to ever be compatible with my definition of a great async system... which is the model Go and Erlang use where the developer can't tell that every single sequential process isn't running in a separate OS thread -- and, by extension, every function is automatically async with no distinction that I have to worry about. In Go, I can spin up as many goroutines as I need, and I don't have to worry about any single goroutine blocking an executor like I have to worry about in Rust. Yes, some async runtimes in Rust have worked on clever things like monitoring the executor threads and spawning a new executor to steal a blocked executor's work queue... maybe some day that will be a battle tested solution. Like most of the Rust async story, there are rough edges that could benefit from some more time. (I have worked professionally with both Rust and Go for several years, and I think they're both great languages with different trade offs... I'm not trying to bash Rust here.)
- snake_case 6y ago
  I just launched a jigsaw puzzle website last week that has a backend API written in Rust and uses the postgres crate [1]. Since this is a side project for me, there wasn't much risk if it ended up being a bad decision. Multiple times throughout the project I got frustrated with the DX of existing http frameworks I tried and ended up building my own [2] on top of hyper. However, after launching my site and seeing how it performs in production, I could not be happier with the result! I had a bit of Rust experience before the project but learned a lot more through building this. For you and others, I think it really depends on the situation. Building a Rust CRUD app will likely take longer than the other languages you're used to as the ecosystem is under heavy development, especially with async/await. So if you or your team are in a rush, I'll just echo that you should build with the tools you already know. If you have time and budget to experiment like I did, it might be worthwhile and I can promise it will be fun :) [1]: https://github.com/sfackler/rust-postgres https://github.com/sfackler/rust-postgres [2]: https://twitter.com/jakedeichert/status/1205230350160539650 https://twitter.com/jakedeichert/status/1205230350160539650
- hobofan 6y ago
  Reddit thread about this question from yesterday: https://www.reddit.com/r/rust/comments/leki5o/advantages_of_building_a_crud_web_application_in https://www.reddit.com/r/rust/comments/leki5o/advantages_of_...
- idubrov 6y ago
  I have some extensive (self-assesment :) ) experience building this kind of application, and my answer would be "no, but maybe" (I was one of the first engineers & architect on our zero to ~500k codebase). Some of the arbitrary, random things I've learned: 1. Given how nice and powerful language is, Rust works relatively well with less experienced engineers. Potentially. You can build very nice APIs which are straightforward to use. If you can stay in this territory, everything is great. However, there are some hard walls in Rust which are really difficult to jump over. And once you hit them, you really need somebody who understands Rust really really well and is capable of working around those issues. 2. It was quite hard to find the right balance between engineering time, compilation/linking time, safety, ease of use, performance, etc. Might be my personal biases, but I had to make some questionable decisions to keep compilation times / turnaround times at bay (like, unsound plugin system, custom serialization framework or test framework using nightly Rust features). 3. The type system is really, really nice. This alone compensates for a lot of things. 4. Ecosystem? Simply amazing. High quality libraries, documentation and everything. 5. Ecosystem again? Lots of things are still missing. 6. Performance? I'm 90% trolling here, but my experience was that Rust is not "blazing fast" by default. Not for "enterprise" software. You have to do some legwork sometimes. I've built some simple tool to do certain transformation between JSON and XML, and out of gate it was ~2x slower than Java equivalent (yes, with release build). Turned out, strings are not that cheap to clone if all you have is a bunch of strings. I did make it like 5x times faster than Java in the end, but it did require some weird tricks (like forcing hash map to look for a "derived" key than I give it). There were some other cases where performance was reduced by simple things (like, having "heavy" Result vs having error variant boxed). I think, this is "easily" counteracted by adopted practices and libraries (optimized error types, for instance), some standard patterns (like don't be afraid of Arc, they are better than to move huge data chunks around), maybe, good profilers as well. This is probably also my biases talking here, frankly, I don't think it mattered at all (performance was killed by database, as is very common with enterprise systems). Also, in the end, it was fast (outside of database woes). 7. Overall, I find Rust very exciting language to work with, which was a big driver (but that doesn't necessarily scale -- you'll have to have some answer prepared when less experienced engineers will ask you "but why can't I do like I did in Typescript in those trivial 500 lines of code"). Would I do it again? Probably, but with understanding that whoever pays for it, might be paying for my "fun" on top of the product they are getting. Which is not necessarily a bad thing -- "fun" is also a factor in attraction and retention of engineers. I'm also not going to lean into the "dark side". Like, if all you care is to get some half-broken whatever out as quick as possible, Rust might not be the right choice. It makes you think about "right or wrong" a lot, imo.
- Animats 6y ago
  That's what Go is for. I've said this before. Go has all those well-exercised packages for doing web applications. Rust is for harder problems. The ones you'd otherwise have to do in C++. I'm working on a client for a virtual world in Rust, and it is far easier in Rust than it would be in C++. Full 3D, GPU usage, networking, lots of state, a constantly changing big world through which you can move, compute bound, multiple threads. All my code is in safe Rust, and I've never had to use a debugger. Write your embedded software in Rust. Write your networking software in Rust. Write databases in Rust. Write browsers in Rust. Write complex games in Rust. For ordinary server side web jobs, it's overkill.
  - bsaul 6y ago
    Go is clearly not for crud web apps. For that you have all the rails clone that’ll autogenerate pretty much everything, and has a predetermined path for every situation. Or the enterprisy version, with a decent orm, if you want type-safety. Go is for system-level programming that mainly consists of plumbing api endpoints together. i would recommend it for building middlewares in a server environment
  - singularity2001 6y ago
    Looking for a virtual world in Rust, is yours on github?
- tracker1 6y ago
  I love Node for those types of situations... that said, it's sometimes useful to optimize certain portions of applications depending on the need.
- dhbradshaw 6y ago
  I'm working on a little crud project. It uses rust all the way down, with actix-web as the http framework and sled as an embedded key value store. The idea is to replace the complexity and expense of using many nodes with one node that's extremely fast. It's been a slow side project for the last month learning the ecosystem and figuring out how to properly deal with types etc. But now I have a page that uses an opaque cookie stored in the database to identify the logged in user and return proof of success in a rendered template. My goal was to keep server latency for that request below a millisecond, and it ended up being about 100 microseconds on my laptop, so 10 times faster than I was hoping for. I'm just not sure how I could have achieved that with, for example, Django. So I guess what I'm saying is that it's slow and challenging for me, at least in the beginning. But it's getting faster and easier over time. And in the end, I'm creating something with performance and reliability that would be hard to achieve in another way.
  - cies 6y ago
    > I'm just not sure how I could have achieved that with, for example, Django. Impossible. Also look at startup time, disk size for installation... But the real benefit is when you want to hack/refactor your code months or years later (or someone else working on the code): languages with strong type systems can help prevent sooo many error in those cases. Compare that to Python where many errors are only discovered runtime.
bcrosby95 6y ago
> Rust is easily the best programming experience I've had When you make this statement, what languages are you comparing it against?
- malwrar 6y ago
  Currently: C, C++, Python, Go, JS, C#, Java, Lua (if that counts), Kotlin, Julia, Scala. I've dabbled in a bunch of other ones but haven't made anything noteworthy with them. You may notice a lack of other modern compiled languages like Zig, so take that bias in mind :)
  - felipemnoa 6y ago
    I'm not trolling. I'm genuinely curious. I've always thought of languages just as tools and have never been fanatic about a particular one. I personally like C and Java but have no problem using other languages if they are the best for the job. I'm really curious to know what makes rust so special? Mind you that I know nothing about it.
    - lights0123 6y ago
      Algebraic data types[0], compile-time thread safety guarantees[1], async/await on embedded[2], type inference that can work backwards[3], blocks are expressions so you can return values from if statements[4], returning from while(true) loops[5], and iterators[6] that don't kill performance[7]. [0]: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html#enum-values https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html... [1]: https://doc.rust-lang.org/book/ch16-04-extensible-concurrency-sync-and-send.html https://doc.rust-lang.org/book/ch16-04-extensible-concurrenc... [2]: https://lights0123.com/blog/2020/07/25/async-await-for-avr-with-rust/ https://lights0123.com/blog/2020/07/25/async-await-for-avr-w... [3]: https://doc.rust-lang.org/book/ch03-02-data-types.html#data-types https://doc.rust-lang.org/book/ch03-02-data-types.html#data-... [4]: https://doc.rust-lang.org/book/ch06-02-match.html#the-match-control-flow-operator https://doc.rust-lang.org/book/ch06-02-match.html#the-match-... [5]: https://doc.rust-lang.org/book/ch03-05-control-flow.html#returning-values-from-loops https://doc.rust-lang.org/book/ch03-05-control-flow.html#ret... [6]: https://doc.rust-lang.org/book/ch13-02-iterators.html https://doc.rust-lang.org/book/ch13-02-iterators.html [7]: https://doc.rust-lang.org/book/ch13-04-performance.html https://doc.rust-lang.org/book/ch13-04-performance.html

haskellandchill 6y ago

It’s booming. I’m considering making Rust or Haskell a requirement for my current remote job search. And given that I have no strong salary requirements it’s actually going to work, could not have done this 4 years ago.

manishsharan 6y ago

serious question : would you recommend Rust for CRUDdy type of web applications -- stuff where mostly you are firing off prepared statememts at a SQL db and then applying business logic to result set. This is what most J2EE apps do currently.

akritrime 6y ago
hmm, no. While compile-time type check[0] for SQL queries changes your whole experience of how you do SQL, at the end of the day creating an webapp in rust is not as easy or mature as any of the other languages more suited for the task. If you want to learn, then its fine. But if you are newish to rust and want to do your next CRUD app at work in rust, I don't think its going to a good experience. [0]: https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx
tempest_ 6y ago
I mean you could certainly do it in Rust. I am not sure I would recommend it though. The dev time for rust will naturally be slower because the developer will have to take more into consideration. Additionally while the community is growing rapidly you wont find the same depth of ecosystem that you have with Java. Client libraries will be half baked and still be a work in progress a lot of the time. If the business stuff is not performance or time sensitive it would probably be better to use something like Java/Go/Python, maybe elixir, that will have good turn around time with reasonable performance. A good litmus test for the moment is probably "Would I write this in C++ five years ago?" if yes Rust might be a good option today with a few caveats, like GUI or GPU programming still being in their relative infancy in Rust.
bluejekyll 6y ago
You're in a Rust thread, I think the general response is going to be, "Yes!" And I personally, say yes. But that comes with some caveats. You will be entering an ecosystem that doesn't have all the libraries that folks coming from the rich history of Java has, so you will most likely be signing up for some extra work. But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature.
- jariel 6y ago
  "But, this is also a great opportunity, because it means that you could be responsible for building a missing library or feature. " Ok, so this is an 'opportunity' for some, but a 'big cost' for others. So remember there are very few Rust devs out there, it is a little bit hard, and though a good chunk of devs might jump at the chance to learn, others, not so much. It would be a really hard thing to rationally do a 'crud app in Rust' at this moment in time due to all the above reasons. There's a lot of added risk for really no benefits. If you have a core team that has the skills, ability and is willing to commit to it, then maybe. But we have to think beyond that, when you need another 100 devs ... and people maintaining it ... one can see how other things factor into the equation. If there is some specific reason and the conditions are right, and if that reasoning is not warped by our own natural tendencies to 'want to use Rust' then there might be an opportunity ... but generally not. As team members get more excited about 'the problem they are solving' and less 'the tools they use' - you might see an inclination towards other tools, for the most part, at least today, for CRUD-ish kinds of things.
  - bluejekyll 6y ago
    Everything you stated, is literally the reason I said there are caveats, I find it interesting you decided to expand on that, but quoted the second part, pretty much out of context. Nothing you said is wrong per se, but it’s also not entirely accurate. First, there are very good db connection libraries available to Rust users, with good connection pooling options. Second there are good ORMs if that’s something you enjoy using. Third there are excellent application server options in Rocket and Actix available. Your comment implies these don’t exist. It’s more the edge cases, and the things outside the DB that will be issues. And even there, you’d need to get into specific areas that would cause issues due to lack of available implementations. In terms of developers out there that want to work with a language, there’s no better response to that than it’s “the most loved language”, and that may translate to many people adopting and expanding its use.
steveklabnik 6y ago
We are doing some web backend stuff in Rust at Oxide, my colleagues gave a talk on it: https://www.youtube.com/watch?v=EmSjZbSzA3A https://www.youtube.com/watch?v=EmSjZbSzA3A The TL;DR is it may or may not make sense for you. Engineering! We are finding it valuable, but you may have different needs than we do. Ecosystem maturity is variable.
tmountain 6y ago
Can't speak to Rust, but this is a sweet spot for Golang for sure.
heavyset_go 6y ago
The ecosystems that support creating CRUD apps are more mature in other languages.
mamcx 6y ago
I have a app that have been ported from old python -> f# -> rust (e-commerce like) and the transition was great (https://www.reddit.com/r/rust/comments/hh9tz6/does_rust_have_a_production_ready_web_server/fw9mfb5/ https://www.reddit.com/r/rust/comments/hh9tz6/does_rust_have...). You need to pay attention in how align the whole software stack. Pairing Rust with tailwinds and htmx or Hotwire simplify so much stuff is like cheating. For regular CRUD flows having enums/traits/iterators make domain modeling very good and found is more productive to me than F#/Python at the domain layer. I do my own micro SQL-orm layer (I have the need to talk to +6 RDBMS and be dynamic at runtime), and most db libraries in the rust ecosystem are mature enough now. I find recently the whole auth is not as mature as you find with Django (aka: Not need to code part of it, you can certainly do it manually), but anyway is now better to offload to key cloak or similar.
- Smaug123 6y ago
  Could you comment a bit more on how Rust let you model the domain better than F# did?
  - mamcx 6y ago
    The thing with F# is that (idiomatic) models/functions rely on type inference, and eventually is hard to see what is the flow without look at the IDE. Rust making type annotations explicit with minimal inference is much clearer. Also, the fact I can do mutation + imperative code locally yet give a functional feel make some hacks around this on F# unnecessary. But probably the biggest thing is that Rust make idiomatic things like conversions with From/Into/AsRef/etc instead of rely in your own conventions, making code more readable in the long run. Other source of simplification is serde. A lot of my stuff is transfer/(re)encoding of data and have a "de facto" idiom for this help a lot. One thing that F# make far easier and I miss much is the sequences (https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/sequences https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...). Making iterators is boilerplate and wish Rust have generators in stable. I found a decent library for this in https://lib.rs/crates/genawaiter https://lib.rs/crates/genawaiter but is not the same as have it in-build.
ragnese 6y ago
I currently do it and have no regrets, but I don't require a lot of fancy stuff that you might find the Java ecosystem. If you don't have any need for concurrent sharing of data and never really miss having destructors in a managed language, then I'd guess that Rust wouldn't be a great fit for a CRUDy backend. Scala and Kotlin are great choices there. They have good type systems (everyone loves Rust's enum types, which are just ADTs and exist in many other languages as well), they have garbage collection- so no borrow checker headaches, and they have the massive Java ecosystem if and when you need it. On the other hand, all programming languages are greater than the sum of their parts. Rust is more than just a checklist of "borrow checker, fancy enums, no exceptions, move semantics, etc, etc". You might just love the language even if it's not "objectively" better for your use case than something else. That's where I am. I spent years doing C++ and I instantly fell in love with Rust. It's not perfect, but it's usually my first choice when doing almost any project. I only ask myself "Is Rust such a bad fit for this task that I'm significantly hindering myself?" and/or "Is FooLang so PERFECT for this task that not using it is stupid?".
JeremyNT 6y ago
I'm mostly a rails developer and really want to get into Rust. I went through the tutorial and did some practice on Excersism. I'm not a rust expert but I enjoyed working with it and learning about it. With that disclaimer: as of now, what rust lacks is a comprehensive framework for web development. I'm sure your story in the J2EE world is similar to rails: you have libraries that you can use to abstract away a lot of repetitive things such as authentication. You probably also have a framework-aware test suite that integrates with something like Selenium. You may have abstractions around javascript build systems like Rails' webpacker that allow you to easily integrate SPAs directly into your app using the same overall tooling. There's so much code you don't have to write, and you probably don't think much about it, and you probably just take it for granted. This is not the story with Rust. There are some frameworks such as Rocket you can reach for, but when I evaluated the situation ~6 months ago I realized I couldn't justify using Rust for this yet. From a web development perspective, there was just too much busy work you'd need to do. I don't think this is an inherent limitation of the language, by the way. I think Rust is a lot of fun to work with and I wouldn't hesitate to use it once a more robust library ecosystem is developed for this use case. I'm always keeping an eye open for places where it would fit what I do, like a small performance-sensitive microservice for example. The type system is powerful, it's great (as a Ruby developer who last worked with C++ a long time ago) to work with a compiled language again. The type system, Rust linter, and compiler together catch many classes of trivial errors that you need to test against in Ruby. I hope it'll get there one day!
- torgard 6y ago
  actix-web seems really interesting, just from some cursory reading. Also, from a performance standpoint, it seems to be _really_ good: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ This example in particular piqued my interest: https://github.com/actix/examples/blob/master/async_pg/src/main.rs https://github.com/actix/examples/blob/master/async_pg/src/m... I have no experience in Rust whatsoever, but I feel inspired to try it out.
redis_mlc 6y ago
No, because rust is extremely picky about types and casts, which makes for a large learning curve for no real advantage in text processing. Expect to be much less productive until you get your own toy programs working.
cultofmetatron 6y ago
don't get me wrong, I love rust and find it a great language for doing systems level stuff but it would be my last choice for a crudy type web application. Those are intrinsically IO bound. Sure, you might find a noticeable improvement if you're using something really slow like rails without any caching but there are plenty of garbage collected rapid development languages that will be fast enough that the visible performance difference will be dwarfed by the IO bottleneck. There are already several languages that server that niche better. I myself use phoenix/elixir which is batteries included. I have a nice toolbox of production ready libraries. I can prototype/build endpoints much faster than I would in rust and the sub 200ms req/res times (including the database call) is plenty fast enough. That said, there are a few things I'd consider rust for. 1.cpu intensive jobs - elixir and any language with c interop have rust interop and I'd be happy to delegate those jobs to a service written in rust. 2. optimized large data structures, discord did something akin to this for their chat system 3. serverless functions - having no runtime or garbage collector makes for a gloriously fast cold boot if you're into that sort of thing. In short, While you CAN user rust for web development, I dont' think its appropriate for most web development related use cases if you're trying to develop software for a client. IF its for fun, Then by all means, go nuts! :)
- zozbot234 6y ago
  > Those are intrinsically IO bound. Rust has a great async story compared to other languages, which benefits IO-bound workloads even more so than CPU-busy ones.
  - andrewflnr 6y ago
    Not compared to Elixir. It's hard to beat lightweight processes for concurrency. I've used Rust, but I'm doing my webapp in Elixir.
  - coder543 6y ago
    I disagree. Saying that it is "great" is really overselling it at this point, unless the languages you're comparing to are mainly C or C++. I would also toss Ruby in that category for now, but they seem to be working on making async better with Ruby 3+. When compared to Python, JavaScript, or C#... Rust's language support for async isn't really that impressive to most developers, although the implementation has some technical characteristics that are nice for people who care about the low level details. The ecosystem is pretty lacking, even though it is much better than it was a few years ago. Compared to the aforementioned languages (including Rust), Go and BEAM-based languages are just on another level. I'm sure both Rust's language ergonomics and the ecosystem will improve over time, but Rust's goals also make it unlikely to ever be compatible with my definition of a great async system... which is the model Go and Erlang use where the developer can't tell that every single sequential process isn't running in a separate OS thread -- and, by extension, every function is automatically async with no distinction that I have to worry about. In Go, I can spin up as many goroutines as I need, and I don't have to worry about any single goroutine blocking an executor like I have to worry about in Rust. Yes, some async runtimes in Rust have worked on clever things like monitoring the executor threads and spawning a new executor to steal a blocked executor's work queue... maybe some day that will be a battle tested solution. Like most of the Rust async story, there are rough edges that could benefit from some more time. (I have worked professionally with both Rust and Go for several years, and I think they're both great languages with different trade offs... I'm not trying to bash Rust here.)
snake_case 6y ago
I just launched a jigsaw puzzle website last week that has a backend API written in Rust and uses the postgres crate [1]. Since this is a side project for me, there wasn't much risk if it ended up being a bad decision. Multiple times throughout the project I got frustrated with the DX of existing http frameworks I tried and ended up building my own [2] on top of hyper. However, after launching my site and seeing how it performs in production, I could not be happier with the result! I had a bit of Rust experience before the project but learned a lot more through building this. For you and others, I think it really depends on the situation. Building a Rust CRUD app will likely take longer than the other languages you're used to as the ecosystem is under heavy development, especially with async/await. So if you or your team are in a rush, I'll just echo that you should build with the tools you already know. If you have time and budget to experiment like I did, it might be worthwhile and I can promise it will be fun :) [1]: https://github.com/sfackler/rust-postgres https://github.com/sfackler/rust-postgres [2]: https://twitter.com/jakedeichert/status/1205230350160539650 https://twitter.com/jakedeichert/status/1205230350160539650
hobofan 6y ago
Reddit thread about this question from yesterday: https://www.reddit.com/r/rust/comments/leki5o/advantages_of_building_a_crud_web_application_in https://www.reddit.com/r/rust/comments/leki5o/advantages_of_...
idubrov 6y ago
I have some extensive (self-assesment :) ) experience building this kind of application, and my answer would be "no, but maybe" (I was one of the first engineers & architect on our zero to ~500k codebase). Some of the arbitrary, random things I've learned: 1. Given how nice and powerful language is, Rust works relatively well with less experienced engineers. Potentially. You can build very nice APIs which are straightforward to use. If you can stay in this territory, everything is great. However, there are some hard walls in Rust which are really difficult to jump over. And once you hit them, you really need somebody who understands Rust really really well and is capable of working around those issues. 2. It was quite hard to find the right balance between engineering time, compilation/linking time, safety, ease of use, performance, etc. Might be my personal biases, but I had to make some questionable decisions to keep compilation times / turnaround times at bay (like, unsound plugin system, custom serialization framework or test framework using nightly Rust features). 3. The type system is really, really nice. This alone compensates for a lot of things. 4. Ecosystem? Simply amazing. High quality libraries, documentation and everything. 5. Ecosystem again? Lots of things are still missing. 6. Performance? I'm 90% trolling here, but my experience was that Rust is not "blazing fast" by default. Not for "enterprise" software. You have to do some legwork sometimes. I've built some simple tool to do certain transformation between JSON and XML, and out of gate it was ~2x slower than Java equivalent (yes, with release build). Turned out, strings are not that cheap to clone if all you have is a bunch of strings. I did make it like 5x times faster than Java in the end, but it did require some weird tricks (like forcing hash map to look for a "derived" key than I give it). There were some other cases where performance was reduced by simple things (like, having "heavy" Result vs having error variant boxed). I think, this is "easily" counteracted by adopted practices and libraries (optimized error types, for instance), some standard patterns (like don't be afraid of Arc, they are better than to move huge data chunks around), maybe, good profilers as well. This is probably also my biases talking here, frankly, I don't think it mattered at all (performance was killed by database, as is very common with enterprise systems). Also, in the end, it was fast (outside of database woes). 7. Overall, I find Rust very exciting language to work with, which was a big driver (but that doesn't necessarily scale -- you'll have to have some answer prepared when less experienced engineers will ask you "but why can't I do like I did in Typescript in those trivial 500 lines of code"). Would I do it again? Probably, but with understanding that whoever pays for it, might be paying for my "fun" on top of the product they are getting. Which is not necessarily a bad thing -- "fun" is also a factor in attraction and retention of engineers. I'm also not going to lean into the "dark side". Like, if all you care is to get some half-broken whatever out as quick as possible, Rust might not be the right choice. It makes you think about "right or wrong" a lot, imo.
Animats 6y ago
That's what Go is for. I've said this before. Go has all those well-exercised packages for doing web applications. Rust is for harder problems. The ones you'd otherwise have to do in C++. I'm working on a client for a virtual world in Rust, and it is far easier in Rust than it would be in C++. Full 3D, GPU usage, networking, lots of state, a constantly changing big world through which you can move, compute bound, multiple threads. All my code is in safe Rust, and I've never had to use a debugger. Write your embedded software in Rust. Write your networking software in Rust. Write databases in Rust. Write browsers in Rust. Write complex games in Rust. For ordinary server side web jobs, it's overkill.
- bsaul 6y ago
  Go is clearly not for crud web apps. For that you have all the rails clone that’ll autogenerate pretty much everything, and has a predetermined path for every situation. Or the enterprisy version, with a decent orm, if you want type-safety. Go is for system-level programming that mainly consists of plumbing api endpoints together. i would recommend it for building middlewares in a server environment
- singularity2001 6y ago
  Looking for a virtual world in Rust, is yours on github?
tracker1 6y ago
I love Node for those types of situations... that said, it's sometimes useful to optimize certain portions of applications depending on the need.
dhbradshaw 6y ago
I'm working on a little crud project. It uses rust all the way down, with actix-web as the http framework and sled as an embedded key value store. The idea is to replace the complexity and expense of using many nodes with one node that's extremely fast. It's been a slow side project for the last month learning the ecosystem and figuring out how to properly deal with types etc. But now I have a page that uses an opaque cookie stored in the database to identify the logged in user and return proof of success in a rendered template. My goal was to keep server latency for that request below a millisecond, and it ended up being about 100 microseconds on my laptop, so 10 times faster than I was hoping for. I'm just not sure how I could have achieved that with, for example, Django. So I guess what I'm saying is that it's slow and challenging for me, at least in the beginning. But it's getting faster and easier over time. And in the end, I'm creating something with performance and reliability that would be hard to achieve in another way.
- cies 6y ago
  > I'm just not sure how I could have achieved that with, for example, Django. Impossible. Also look at startup time, disk size for installation... But the real benefit is when you want to hack/refactor your code months or years later (or someone else working on the code): languages with strong type systems can help prevent sooo many error in those cases. Compare that to Python where many errors are only discovered runtime.

bcrosby95 6y ago

> Rust is easily the best programming experience I've had When you make this statement, what languages are you comparing it against?

malwrar 6y ago
Currently: C, C++, Python, Go, JS, C#, Java, Lua (if that counts), Kotlin, Julia, Scala. I've dabbled in a bunch of other ones but haven't made anything noteworthy with them. You may notice a lack of other modern compiled languages like Zig, so take that bias in mind :)
- felipemnoa 6y ago
  I'm not trolling. I'm genuinely curious. I've always thought of languages just as tools and have never been fanatic about a particular one. I personally like C and Java but have no problem using other languages if they are the best for the job. I'm really curious to know what makes rust so special? Mind you that I know nothing about it.
  - lights0123 6y ago
    Algebraic data types[0], compile-time thread safety guarantees[1], async/await on embedded[2], type inference that can work backwards[3], blocks are expressions so you can return values from if statements[4], returning from while(true) loops[5], and iterators[6] that don't kill performance[7]. [0]: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html#enum-values https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html... [1]: https://doc.rust-lang.org/book/ch16-04-extensible-concurrency-sync-and-send.html https://doc.rust-lang.org/book/ch16-04-extensible-concurrenc... [2]: https://lights0123.com/blog/2020/07/25/async-await-for-avr-with-rust/ https://lights0123.com/blog/2020/07/25/async-await-for-avr-w... [3]: https://doc.rust-lang.org/book/ch03-02-data-types.html#data-types https://doc.rust-lang.org/book/ch03-02-data-types.html#data-... [4]: https://doc.rust-lang.org/book/ch06-02-match.html#the-match-control-flow-operator https://doc.rust-lang.org/book/ch06-02-match.html#the-match-... [5]: https://doc.rust-lang.org/book/ch03-05-control-flow.html#returning-values-from-loops https://doc.rust-lang.org/book/ch03-05-control-flow.html#ret... [6]: https://doc.rust-lang.org/book/ch13-02-iterators.html https://doc.rust-lang.org/book/ch13-02-iterators.html [7]: https://doc.rust-lang.org/book/ch13-04-performance.html https://doc.rust-lang.org/book/ch13-04-performance.html