Why requiring SecureRandom when Crystal::Random::System can be used directly in stdlib?

I don't understand what is the difference (I thought that SecureRandom was renamed to Random::System but then discovered that it's still here).
SecureRandom is a safe random source, while Crystal::Random::System is it's platform independent implementation?

I don't understand what is the difference (I thought that SecureRandom was renamed to Random::System but then discovered that it's still here).

That definitely is worth a blogpost or similar that describes what the stdlib should look like moving forward. /cc @mverzilli @matiasgarciaisaia @bcardiff

@konovod a bit more of background (until someone can produce a condensed and concise response here):

• [RFC] per-platform low-level abstractions #4406
• Crystal::System::Random namespace #4450

Cheers

@luislavena i think i already read them (maybe not thoroughly). But when reading i thought that it was replacing secure_random and i was confused to see it's still here (and just calls Crystal::Random::System). What to use in any particular case - Crystal::Random::System.random_bytes or SecureRandom.random_bytes?

So, if I understand correctly, the difference is that SecureRandom is an interface exposed to end users, while Crystal::Random::System is a low-level and internal part of stdlib, so former should be used in external shards, while latter should be used inside stdlib?

I've updated PR.

This weird phobia against including SecureRandom in the prelude is just crazy.

The system random situation in crystal is also just crazy. There should be one class in crystal which uses Crystal::System::Random: Random::System. And it should provide a random_bytes method.

And you know how I feel about SecureRandom, it should be unified with Random.

All the current mess just serves to confuse people, as this thread continues to prove.

All the current mess just serves to confuse people, as this thread continues to prove.

I have no personal position on that, so I will suggest a RFC for that be reviewed by core and other contributors.

Please do, so the RFC can be used as guidance and modifications be introduced to simply current approach.

Thank you @konovod! I was about to say you're steadily becoming "Crystal's Random Guy" but realized it didn't sound so positive :P.