Possible unpopular opinion: Rust is a systems language, doing "web work" in Rust is a waste of effort as there are much better languages and ecosystems for that.
You can do dependency injection in Rust to share connection pools just like you would in Java, and it's super simple to write threaded background tasks.
Google gave a talk recently that said they measured Rust developers as no less efficient or productive than Go developers [1].
It's a fantastic language and you shouldn't ever limit yourself to systems programming with Rust. It can do so much more than that.
Otherwise it's just stating that they assign the languages to categories of problems they are equally efficient in.
> "We have at this point rewritten a large number of systems [..] have some very concrete things that we can say"
> "When we've rewritten systems from Go into Rust, we've found that it takes about the same sized team about the same amount time to build it. [...] no loss of productivity when moving from Go to Rust."
> "We do see some benefits [...] we see reduced memory usage in the services that we've moved from Go. [...] We see a decreased defect rate over time in those services that have been rewritten in Rust"
> "Within two months about a third of the folks were feeling as productive, within four months about 50%."
> "People do indeed feel as productive in Rust as they do in their original language. C++, Java, Python, Go."
> "One of the biggest latencies is code review time [...] How hard is it to review code in Rust? [...] A little over half said that Rust is easier to review. The most incredible question [...] The confidence that people have in the correctness of the Rust code that they're looking at. [...] 85% of people believe that their Rust code is more likely to be correct."
A rewrite should be much faster than the original. Much of the original development will have had changes in requirements, refactors because of better understanding the problem domain, best structure for the code etc. A lot of that can be just 'copied' into the new system. The developers know exactly what to do.
To complete this experiment they should have also re-written it in C# or java and then compare with rust.
Having written services in the Google style for years at a major fintech surrounded by Xoogler peers, systems design starts with a design document. You capture requirements upfront and solicit buy-in from the stakeholders. It's nothing at all like what you describe. You design the API and systems upfront without code (apart from capacity testing) and actual implementation happens quickly.
If iteration time was some "gotcha", Google would have made that footnote. That's not really how service development works in companies of this scale.
Translation time from design document to service is the same for Golang and Rust.
Likewise on CLR with F#.
Having a rust alternative to something like libmicrohttpd would be nice and I would use it.
Not having to learn something like PHP? Do we not count learning C++? I would guess most people would agree learning PHP + Nginx is going to be a lot less complicated, which will be preferable for people just trying to build something. I'm not sure dropping down to such a low level is something most web developers will have to deal with.
I think that you find it easy speaks more to an already existing familiarity with C++, not that it would be a path of less resistance.
No, because they presumably already know it. They wouldn't be using it otherwise.
Neither is the intersection between embedded programming and web programming.
But either way, if something like Django, .Net, or go is an option, Rust is probably a bad idea.
Rust is a high AND low level lego due to type composition and ability to directly address memory with no hacky garbage collection required.
Garbage collection is a bad idea when your state machine is basically a stateless request response cycle that can fit in n stack frames and has a defined lifetime ending in the response.
Interpreted languages calculate runtime code paths on an ad-hoc basis and are subject to bugs that a binary executable will never encounter.
One can objectively state that Interpreted languages and their virtual machines are LESS DETERMINISTIC than binary executables whose runtime code already exists at compilation time.
Of course, shared libs and other things that violate the spirit of the above can wreak havoc with even binaries, however the executable is a finite artifact.
I kinda agree with this, but the speed of a language like Rust changes so much of the mental calculation. Like in Python/JS/Ruby you try to offload as much work to the database as possible, because its so much faster. In Rust, you might not need to do that, because its such a fast language.