2 ms·
If you spend all day writing web servers and clients it might seem fundamental. Most of my code doesn't touch the network so I don't mind if I need the ecosyste
by hctaw 5y ago
If you spend all day writing web servers and clients it might seem fundamental. Most of my code doesn't touch the network so I don't mind if I need the ecosystem to do it - I do that in C and C++ too.
I think people are fairly apprehensive towards a bigger std because firstly, dependency management is almost trivial (C++ needs the kitchen sink in std because dependencies don't exist to the language, for example) so it's not that big of a deal, and secondly because a bigger std means a bigger commitment to APIs and maintenance by a relatively small group of maintainers for all eternity.
At the level of the stack where it makes sense to use rust, it doesn't make sense to put HTTP in std. At least not like Go.
- hda2 5y agoYou may have been correct 20 years ago, but I don't believe this argument holds water nowadays. HTTP APIs are everywhere from being required to control small embedded systems to interacting with large complex daemons. These usecases are exactly the space where Rust/stdlib is meant to be used. Rust has included TCP and UDP in the standard library* because it was rightly recognized that these protocols, like stdio and filesystem io, have become fundamental to how most modern software interacts with its environment (system, IPC). HTTP today has also become fundamental in a similar manner. I argue that it is time that we treated it as such. * as apposed to leaving them as an external dependency, like mio.