3 ms·

> but Rust has never struck me as suitable for rapid prototyping Having Rust a lot, and coming from JavaScript, I'd say it depend at what stage of prototyping

> but Rust has never struck me as suitable for rapid prototyping Having Rust a lot, and coming from JavaScript, I'd say it depend at what stage of prototyping you want to stop: If you want to make a one-shot implementation of a quick demo without ever iterating on, then, yes, Rust is going to slow you down. If your prototyping effort involves lots of iterations because you're learning in the process (learning about the use-case, the market and so on), then Rust quickly pays of compared to JavaScript or say Python because refactoring is straightforward and you're almost never going to break things in the process. Most of the benefit comes from static typing alone, but Rust type system allows you to express things in a more robust way than C# or Java for instance, leading to an even more streamlined iteration cycle (but it's not a game changer either). But the place where I've found Rust to shine, with no match whatsoever, is going from the stable prototype to the production ready stuff: in addition to the ability to get the best achievable performance on your hardware, I find the error handling to be the killer feature in that scenario: when prototyping, you use unwrap everywhere without paying attention (and it basically behaves as in a language exceptions where you don't catch them) but then you just ctrl-F `unwrap` and you can deal exhaustively with all possible error scenario with very limited effort. Ensuring after the fact that every possible exception gets handled properly is a much harder task.

stmblast 3y ago
Totally agree with this. I can spin up a generic Axum backend service within probably about half an hour to an hour that contains most of the things I need (auth, CRUD, similar things) once I know what I need, configuration and business logic depending. I think the key phrasing is primarily "when you're familiar with Rust" - if you're not familiar, then it will definitely be a slog. Certain things that would require you to manually implement a complex trait (for example, Send + Sync + 'static plus whatever else) would probably slow you down though, but presumably by that time you probably already know what you're doing.
- BWStearns 3y ago
  Do you have a goto library for auth in Axum? Maybe I just don’t implement it often enough but auth in Axum usually takes me an hour at least even if I’ve implemented it somewhat recently.
CraigJPerry 3y ago
>> The place where I've found Rust to shine, with no match whatsoever, is going from the stable prototype to the production ready stuff Love it or loathe it, spring boot is going to win that race every time. A kind of sweet thing about modern spring is it can be pretty easy to rip it out when you've arrived at your feature complete state. So if you wanted to, you could get rid of reflection without losing JIT for example (i think Graal is getting JIT eventually, which would be the other way to force yourself rid of reflection today, so maybe this becomes moot in future). But either way, if you approach your spring boot development with this exit strategy in mind, you can reap the rewards of removing a big project dependency to own over time leading to cheaper TCO long term once the project has reached feature complete state. It'll even likely be slightly faster if you're ripping out all those classes from the classloader, removing all that reflection and proxies etc. - but you can do all this while scoring the benefits of rapid iteration & extensive code reuse / building on the shoulders of giants, at the start of the project by exploiting spring and especially by exploiting boot. Could you do something like that with say Axum? Maybe. Probably not. I mean that's quite a niche idea spurred on by your next comment i've quoted below but even if you're not interested in eeking out the last say in performance and cloud memory footprint costs then spring boot will still more than likely be absolutely fine without doing any of this. And you'll be done sooner too of course. As for production, does that mean stuff like robust and safe, automated scrubbing measures for handling developer access to sensitive prod memory dumps for diagnostics? Or maybe just mature observability tools - it's like bringing the "tokio console" knife to a "JMC & JFR" gun fight. I guess my TL;DR here is just: Java. But it could equally be C# or maybe even something else. It's definitely not "with no match whatsoever". >> in addition to the ability to get the best achievable performance on your hardware I've ended up spewing so much above i don't feel like going much further and it was actually this part that made me reply. What you're saying seems unlikely - you're claiming not just fast but the best possible performance on given hardware. So we're talking really annoying things to own like repurposing #[repr(C)] not for FFI but to allow explicit ordering of struct fields to maximise memory throughput. We can do that kind of stuff in Java too (heck most languages allow something like this), java has some unsafe off-heap facilities which can be (ab)used for extreme cases - although there's potentially much nicer and safer APIs in the latest Java which i haven't looked at yet - https://openjdk.org/jeps/442 https://openjdk.org/jeps/442 Best achievable performance usually means for one part of your process at the cost of another code path - when you get down to the most extreme levels, it becomes trade offs. If you want to go that far in java, you can. It's not like you're getting extreme performance for nothing by going another way. E.g. rustc won't magically recognise every time i could use vector instructions, you have to write your code careful of branching and dependencies, be friendly to the compiler for it to do its magic. But of course, we have vectorisation (and even some auto-vectorisation) in java too.

stmblast 3y ago

Totally agree with this. I can spin up a generic Axum backend service within probably about half an hour to an hour that contains most of the things I need (auth, CRUD, similar things) once I know what I need, configuration and business logic depending. I think the key phrasing is primarily "when you're familiar with Rust" - if you're not familiar, then it will definitely be a slog. Certain things that would require you to manually implement a complex trait (for example, Send + Sync + 'static plus whatever else) would probably slow you down though, but presumably by that time you probably already know what you're doing.

BWStearns 3y ago
Do you have a goto library for auth in Axum? Maybe I just don’t implement it often enough but auth in Axum usually takes me an hour at least even if I’ve implemented it somewhat recently.

CraigJPerry 3y ago

>> The place where I've found Rust to shine, with no match whatsoever, is going from the stable prototype to the production ready stuff Love it or loathe it, spring boot is going to win that race every time. A kind of sweet thing about modern spring is it can be pretty easy to rip it out when you've arrived at your feature complete state. So if you wanted to, you could get rid of reflection without losing JIT for example (i think Graal is getting JIT eventually, which would be the other way to force yourself rid of reflection today, so maybe this becomes moot in future). But either way, if you approach your spring boot development with this exit strategy in mind, you can reap the rewards of removing a big project dependency to own over time leading to cheaper TCO long term once the project has reached feature complete state. It'll even likely be slightly faster if you're ripping out all those classes from the classloader, removing all that reflection and proxies etc. - but you can do all this while scoring the benefits of rapid iteration & extensive code reuse / building on the shoulders of giants, at the start of the project by exploiting spring and especially by exploiting boot. Could you do something like that with say Axum? Maybe. Probably not. I mean that's quite a niche idea spurred on by your next comment i've quoted below but even if you're not interested in eeking out the last say in performance and cloud memory footprint costs then spring boot will still more than likely be absolutely fine without doing any of this. And you'll be done sooner too of course. As for production, does that mean stuff like robust and safe, automated scrubbing measures for handling developer access to sensitive prod memory dumps for diagnostics? Or maybe just mature observability tools - it's like bringing the "tokio console" knife to a "JMC & JFR" gun fight. I guess my TL;DR here is just: Java. But it could equally be C# or maybe even something else. It's definitely not "with no match whatsoever". >> in addition to the ability to get the best achievable performance on your hardware I've ended up spewing so much above i don't feel like going much further and it was actually this part that made me reply. What you're saying seems unlikely - you're claiming not just fast but the best possible performance on given hardware. So we're talking really annoying things to own like repurposing #[repr(C)] not for FFI but to allow explicit ordering of struct fields to maximise memory throughput. We can do that kind of stuff in Java too (heck most languages allow something like this), java has some unsafe off-heap facilities which can be (ab)used for extreme cases - although there's potentially much nicer and safer APIs in the latest Java which i haven't looked at yet - https://openjdk.org/jeps/442 https://openjdk.org/jeps/442 Best achievable performance usually means for one part of your process at the cost of another code path - when you get down to the most extreme levels, it becomes trade offs. If you want to go that far in java, you can. It's not like you're getting extreme performance for nothing by going another way. E.g. rustc won't magically recognise every time i could use vector instructions, you have to write your code careful of branching and dependencies, be friendly to the compiler for it to do its magic. But of course, we have vectorisation (and even some auto-vectorisation) in java too.