What if there were an alternative, simpler rng implementation with less breakage than the rand crate?
-
-
-
Right, yeah, I think that's what I meant by there being some design space in the ecosystem for something exactly like that. :-)
- 2 more replies
New conversation -
-
-
Commenting here since it's tangential, and I don't want to derail your issue, but I think we really need to decide as a community what we consider to be the norm for compiler version support. I think we can be more aggressive than other langs, but different crates have diff needs
-
I agree. To be clear though, if it were only about MSRV, I could overlook that, at least for rand. I still like the LTS idea that boats/aturon proposed. It provides a rallying point. Adding MSRV to Cargo.toml in order to improve failure modes is also a good start.
- 4 more replies
New conversation -
-
-
Using ‘getrandom’ directly would probably help you and may be enough.
-
It would need the `Rng` trait (or similar) layer on top of it, ideally. I guess that's probably the (longer) pole in the tent.
End of conversation
New conversation -
-
-
As `rand` is a project controlled crate, we can also lobby for stabilisation. You're not the only one frustrated.
-
+1 from me, seems like this is much more annoying than any MSRV issues that you might also have. The rand folks should agree on a minimal API already and start taking backwards compatibility seriously as befitting a project with its amount of downstream users.
- 1 more reply
New conversation -
-
-
I'd support this as a Quickcheck user. Rand has been more of a pain in my backside for http://Criterion.rs than it's worth, and I hardly even use it except transitively through Quickcheck.
-
As a criterion user, I'd love to see it stop depending on rand
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.