Once you get to higher level protocols like HTTP, you also have questions like "should HTTP header be strings or encoded as types. There very much isn't just one way to implement it.
That's pretty fundamental and completely changes your API.
And, before you reply, you might want to know that while the majority of things do it with callbacks, both the lowest embedded AND highest custom networking systems implement networking with polling (for different reasons).
If anything, i would say that over the last year or so, too much effort has been put into making Rust a competitor for web development, what with async, and lots of attention paid to web frameworks. Meanwhile, C++ people i know mostly look at it and say "meh, no const generics, no placement new".
Second, we’ve been working a ton on const generics. It takes a long, long time. But it’s been a constant effort. We’ll get there.
(Placement new has had less attention.)
If (if!) Rust's mission was to replace C++, that would be a mistake.
That's pretty obvious, right? You decide to replace C++. You make a language which isn't a great C++ replacement. You attract users who aren't C++ programmers. They aren't interested in the things C++ programmers are interested in. You build features which don't appeal to C++ programmers. Lather, rinse, repeat.
I think at this point, in practice, Rust's goal isn't to replace C++. It's to become a better Rust.
This assumption only holds if people didn't want to do systems programming before. Many people who wanted to do it crashed into C++ and then said "yeah okay, not for me", which calls this into question.
From the very first introduction of Rust to the world: “a complied, concurrent, safe systems language.”
Then it was “memory safety without garbage collection”.
Now it’s “A language empowering everyone to build reliable and efficient software.”
Sure there is domain and design overlap, but the goal was never explicitly attracting C or C++ programmers. At least not exclusively.
That is still Mozilla's main angle on Rust, but Rust has grown much beyond Mozilla, so this is just history now as you describe.
Rust will be most popular with those who are 18 years old now and wanting to try native programming. When you compare the two, tabula rasa, it's just a no-brainer.
When is that? Knuth is 82.
https://www.independent.co.uk/life-style/learn-language-scie...
It's nothing personal against anybody.
GUI tooling like Qt or XAML, even OWL, MFC, wxWidgets, VCL, if I go pick 90's examples.
async/await runtime as part of std. C++20 async/await isn't relying to competing external libraries.
Mixed language IDE based development experience, including debugging across languages on the same session, e.g. Java/C++, .NET/C++, Objective-C, Swift/C++.
Standard library is a liability. It's only a matter of time before any non-trivial stuff will turn out to be worse than a 3rd party solution, and won't be able to catch up due to std's constraints (C++ regex being extreme example).
Rust has already learned that lesson with channels. So instead of having to say "don't use std's, use the other faster nicer thing", Rust skips over the tech debt part, and recommends the other faster nicer thing immediately.
And a clean separation of await from its runtime is actually pretty cool. I'm writing a GTK+ app right now, and I can await button clicks on its event loop.
Also, I haven't been following the Go ecosystem lately, so I could be wrong, but they seem to have done a good job at creating standard libraries for common stuff like http serving, and those libraries seem to have aged just fine.
I'll bite. Why?
Rust is a system-level programming language.
Not that this means that every demand needs to be acquiesced to, there’s balance to be found.
I used to code a lot in C++, but I've come to the conclusion that manual memory management is a cost that has to be considered seriously. e.g. one burden is that when you're declaring a field on a struct in Rust, you have to consider whether it needs to be a reference, value, automatic reference counted, boxed, if its a reference, what the lifetime is, etc. The only thing I miss about manual memory management is the RAII pattern.
Rust moves down a level of abstraction that IMO is not useful for most applications.
Thing is, with ongoing efforts on managed languages to integrated similar capabilities into their type systems, we can get most of it, even if we don't get access to the full package.
So I guess you're right, nothing I can think of quite fills the niche that Rust does, if compiling to a native binary is a hard requirement. Also I'm not aware of any widely-adopted language with borrow checking, if that's a feature that's valuable for your use case.
Rust belongs with the above but it has...checks notes...actix-web which was run by one guy who ragequit and apparently no one else is capable of taking the reins.
Also you forgot netty which is best Java networking library nowadays.
Java is a good example why batteries-included standard library is a bad idea. The fact that Java keeps reinventing things (Old I/O -> New I/O, Newer I/O; java.util.Date -> java.time.*; File -> Path are just a few examples) also proves that point.
Standard library must contain fundamental interfaces which are required by most libraries to interoperate with user code and with other libraries. String type is used everywhere, so standard library must contain String type, otherwise people will invent QString, CString, Glib::ustring and billion other string which do not interoperate with each other, so instead of writing useful code you'll convert one string to another. Array, Set, Map are used everywhere as well, so standard library should provide those interfaces. Filesystem paths, streams are useful. And similar things. But not big libraries like HTTP library. They should be implemented as independent projects, so the best one wins.
You're arguing against a strawman. These things are not in the standard library, but the ecosystem builds around them, and there are published JSRs that define the interfaces for foundational libraries (including both servlets and DI - of which Spring is just one of many compatible implementations).
No-one's arguing that Rust should have a web framework in the language standard library (I hope). But there should be one or more established options that the rest of the ecosystem knows about and interoperates with.
You can't compare a general use networking server such as hyper with actix-web. Hyper is used for a much broader range of scenarios than just web development.
I truly hope that programmers continue to broaden the ecosystem, but progress has been slow.