Actix-web is in 2.0. The original author stepped away recently, but it has quite the community behind it.
If readers are curious why Rocket requires nightly, it has to do with the macros (that resemble Java annotations/python decorators). Specifically Rust wants all its macros to be hygienic - they shouldn't be able to (for example) create variables that clobber user-defined variables. Rust has multiple types of macros, but the type used by Rocket, procedural macros, don't have this hygienic property yet. For context, procedural macros operate on TokenStreams, whereas "normal macros" (declarative macros) operate on AST nodes. See the issue https://github.com/SergioBenitez/Rocket/issues/19
What's the situation with use of unsafe now?
Although toxicity that was shown by the community was obviously uncalled for, I was very put off by the original author's stance on the issue and am wary of using it in production.
> Performance remains the key reason for the unsafe blocks. As per the safety dance charter, changing std Rust so as to eliminate the need for unsafe seems like the best course of action, but this work is beyond my comprehension.
https://www.reddit.com/r/rust/comments/efk7n7/actixweb_v20_r...
If you have one or two modules you're using that cal calling out to C libs, and your managed language is segfaulting, it's probably somewhere to do with those libraries, or how you're utilizing them (maybe a bad API or abstraction). Rust just lets you take that reasoning further in the case of unsafe, since you can see the unsafe code in the same codebase, it's basically the same language plus a couple extra features, and can be kept much smaller (at least in the case where the functionality is implemented in Rust).
Unsafe isn't meant to imply "don't do this", it's meant to imply you're giving up the safety generally afforded. It's like driving a car without seatbelts and airbags down the freeway, not like driving a car at 100Mph on a windy cliff-side road.
1: Or to the same level, if using unsafe to abstract over a C lib also
you could:
- Convince the fire alarm about the difference between pizza smoke, and fire smoke (somehow?). - Call the fire department to come put out the fire so you can finish cooking your pizza. - Disable it until you have finished cooking the pizzas. - Have a pizzaless party.
Fire alarms have little to do with performance, and even though they have false positives we tolerate them due to the impact a false negative would have.
Rust has much more modern and ergonomic syntax, features and package management over C, so even inside unsafe blocks it's simply easier to write.
Also benchmarks show Swift and C# are still about 2x-5x slower than Rust and C++, and that only if you're very careful and you write non-idiomatic code (e.g by avoiding heap allocations). When you're not, and you use OOP abstractions heavily, 10x worse is a much more likely outcome.
Winning the benchmarks game is meaningless, other than "I fell good" kind of thing.
What matters is having the language features that allow to optimize the 1% of the code base, when it actually impact the acceptance criteria of project delivery.
I have been replacing C++ systems with Java and .NET based solutions since 2006, it hardly matters that C++ wins in the micro-benchmarks.
And if really needed, only that 1% gets packed into a C++ library with managed language bindings, turning C++ into our "unsafe" module.
In many applications there is also no single bottleneck and the split is not 1/99, nor even 20/80. After you optimize the most obvious bottlenecks you end up with a flat profile, where majority of time is taken by cache misses scattered across almost the whole codebase.
It might not matter for some apps where performance is less critical, but in this case you probably don't want to use Java or C# when there exist languages offering much better abstractions (and surprisingly - Rust and C++ can be higher-level than Java or C#, leading to better abstractions, shorter code and higher productivity). Don't conflate EASY with PRODUCTIVE. Easy languages are not always more productive (if it was true everybody would be coding in Scratch).
As for Rust, it remains to have something that matches Orleans, Akka, Kafka, ....
Then there is the whole IDE tooling experience, libraries like the one here that require nightly toolchains, and lack of support for stagging binary libraries, which cargo might eventually get one day, but isn't here today.
Java and C# might be inferior products from your point of view, but as mentioned, what I get are rewrites from C++ into Java and .NET languages, not the other way around.
And I never sensed lack of productivity, quite the contrary, specially when I usually don't have to think about which C++ flavor of the month I am allowed to use, or having political discussions about enforcing the use of static analyzers on the CI/CD pipeline (assuming there is even one to start with).
IDE support is already very good and better than for many popular languages (e.g. dynamic ones).
Performance profiling is also better than in Java. I'd take perf over visualvm any time.
Java had much worse tooling when it was at the age of Rust today.
IDE support can be considered very good if the baseline is the 90's Borland and Microsoft IDE experience, not what modern Java and .NET are capable of, which starts to finally approach the Smalltalk and Common Lisp development experience of yore.
Rust IDEs can't still offer completion that works all the time, let alone all the other IDE features.
Perf is no match for Visual VM, as it is a Linux only tool, and it's usability is found lacking. It is so good that Google was forced to create their own graphical based tooling after years of Android developers complaints being forced to use it.
Yeah, except not every business is willing to wait 25 years for Rust to achieve parity with today's Java ecosystem.
Note that C++ is 40 something years old and still there are domains that it is fighting against C, which require a generational change before being open to try out anything else.
Rust's has a big selling story for OS low level systems libraries, the niche C++ is heading to, with the caveat that C++ will as secure as Rust, that is where the language should focus.
To be honest, had Go supported generics from day one, Nim or D some corporate backing, and I would have never considered Rust for hobby projects beyond the language geek thing of trying out new languages every year.
Unfounded speculation. You've made this number up.
> Rust IDEs can't still offer completion that works all the time, let alone all the other IDE features
I didn't see any problems in IntelliJ. If there are cases where autocomplete doesn't work, these are rare edge cases and they don't affect predictivity. VSCode was a bit laggy, but that's probably VSCode problem not Rust's. This is what happens if you base a desktop tool on a browser running JS.
> Rust's has a big selling story for OS low level systems libraries
It is good at that, but this is not the primary reason to use Rust. Rust selling point are explicit lifetimes which make it virtually impossible to create pointer hell I found in every commercial Java codebase I worked on. It is the same level of productivity enhancement as introducing static types over dynamic. Explicit lifetimes make it a bit harder to write in Rust but code is being read 99% of time and written only 1% of time.
Compile on Stable (Rocket): https://github.com/SergioBenitez/Rocket/issues/19
Stabilize Proc Macro Hygiene (Rust): https://github.com/rust-lang/rust/issues/54727
Partially Stabilize Proc Macro Hygiene (Rust): https://github.com/rust-lang/rust/pull/68717
But 1.0 is special -- pretty much everyone agrees on its meaning: it's ready for others to use it, and I'm willing to stand by it.
Sub-1.0 is also special, and generally agreed upon -- no one should consider this production-ready, and I'm not ready to defend it.
Using node as much as I have, I've gotten used to updating dependencies fairly often and spending maybe a day a month on keeping things updated and smooth. I also tend to dig into nested dependencies and my bundle sizes (more on the front end).
Probably Go and node.js could be counted as good solutions, because their standard libraries cover the use-case very well. Or Java, thanks to a mature ecosystem around web services - even though the mainstream solutions (Servlet) focus on blocking IO.
Up from there would imho be Go or C#, mostly because they're faster than node, but still very accessible, and really good support around them for web services. Certain workloads are still not great. I think Java is probably okay, I just personally don't care for it, apparently it's gotten better than when I last used it regularly over a decade ago.
Rust is when you want balls out absolute performance in a language with newer, higher level features and constructs. The unsafe escape hatch is really there if/when you need it, but should not be the norm. The final executable size on rust is also impressive and will work very well in some constrained environments, or when you need better execution performance and more control than the others provide (outside of C/C++, D and a couple others).
I've only built a couple smaller web apps with rust so far, but the output size is impressive. Being able to build to a bare container or with busybox if some in-container scripting is needed has been a great experience so far.
Then there is the .NET stack as well.
For distributed computing I hardly see a reason to pick Rust over Java or .NET eco-system.
If we would be speaking about something like real time audio engine, then Rust would probably be the tool I would pick.
It'd be so nice if a major vendor picked up the language and built an ecosystem on it :)
Most of those languages also have ways to stack allocate and off GC heap allocation, it is a matter of learning how to use those features, when and if it actually matters.
99% of the time it won't matter.
Rust is great replacement for the kind of low level stuff like the C++ layer of Android, UWP composition engine, game engine graphics rendering and similar.
As a language it is mature, but the crates ecosystem is of lesser quality, especially for applications like HTTP servers. I've already overcome its learning curve, but the devs who swear by other languages that pay them well may not be so forgiving.