The Rust developers deprecated some important code we depend upon in std::net, mainly IpAddr. Can anyone offer a good reason why and what else is under consideration for deprecation? If we can't depend on a stable std::net ABI, we may as well go back to C.
Could you please point me towards the deprecated methods?
I went through all methods on std::net - Rust and none of them are deprecated.
IpAddr is unstable and never been stabilized (so only available of nightly compilers), you shouldn't rely on its stability for that reason. IpAddr in std::net - Rust
The reasoning behind that move is described here: https://github.com/rust-lang/rust/issues/27801
Deprecation of nightly, unstable features is a rather graceful move, IMHO, I'd even be comfortable with full immediate removal (but I know that I'm sailing a different boat here).
Now, yes, it was in nightly, so there is no guarantee that it would be stabilized or deprecated. Looking over the comments, it seems like many other developers depended on IpAddr and voiced support to keep it. I guess that's a lesson to us about depending on Rust.
This is exactly why unstable features aren't enabled in non-nightly builds: to prevent de-facto stabilisation.
I've had useful features ripped out from under my feet, too (and mightily was I pissed)... but that's the explicit risk of using unstable.
Given that there seem to be quite a few crates using copies of this type, I suppose the next logical step is to agree on a single definition, shove it in a crate, and depend on that.
That said, it's a little worrying that potentially useful "interface" types don't have a clear migration path into std, if "std doesn't use it" is a valid reason to kill it.
This is actually even nicer for you: you can use it on stable in 1.6, but it will not be supported in a future version of Rust (2.x.x). Enough time for you to devise a solution or create a crate. Also note that reintroduction at a future date was mentioned as an explicit option.
Some people in the issue also mentioned that the enum doesn't include enough variants and doesn't make it very useful. I didn't feel it was a clear "keep".
I really can't see where this as a make-or-break thing for Rust.
1 Like
I really meant this means I need to be a lot more thoughtful about what we use from the standard libraries. Sure, it's not a make-or-break issue. Our shop is relatively new to Rust, we were quite productive in porting an old code base, and we are pleased with the performance and tools. Since we are a network security shop, we're used to networking libraries that provide utility with lots of helper functions and types. Maybe I need to get more involved in the Rust community, but I now don't know if std::net is that library.
tl;dr I'm not bitter or angry, just more surprised that something like an IP address abstraction isn't a standard library feature. It's all good, though. Our code is already patched and merged.
There's a pretty strong trend in the complete opposite direction for std, at least as I've seen it. It's not trying to be "batteries included" like Python; it's meant to only contain the very highest-value stuff, and things that can't really be done properly anywhere else. Not only that, but things that go in have to be supported forever, so they have to pass a high "complete, accurate and good design" bar.
I mean, sure, you can argue over where exactly the line is drawn, but that's the overall strategy, from what I've seen.
Aside: Rust is in something of a "damned if you do, damned if you don't" position. On the one side, you have people complaining about the lack of functionality, and on the other you have people complaining that the stdlib is too large.
3 Likes
I see that as a very valid reason. If std doesn't use or consume the type, it's also hard to discover.
In general: just use what is in stable or on beta. Guarantees for that are very strong.
Rust is a young language, spots in APIs are usual, but we need to make sure that the fillers merit being supported forever. Get used to filling the blanks on you own, you implementation will probably fit your use-case just fine. I'm doing that very often when porting code to stable.
If you are using unstable features, make sure you star all the tracking issues on Github and watch out for the "final discussion" marker. That means you can make your case and will definitely be listened to.
Ah, that's good to hear.
One thing to remember about Rust is that it is a systems language, and as such needs to run in very restricted environments, and to not add bloat to programs. One major attraction of Rust is that it does not add much bloat over using C, while being far safer. A large libstd would negate that.