Would it be a bad idea to have a single seed for the entire lifecycle of a backend process when it comes to generating UUIDs (triggered by different app users)?
Running nextRandom into IO seems reasonable - you probably have it in your stack somewhere anyway, so I don't think there's any reason to lie about purity :slight_smile:
Which builtin effect(s) are recommended for use when generating UUIDs?
@Sridhar Ratnakumar do you have concrete initial seed? If not, you'll probably need source of randomness =
IO
Would it be a bad idea to have a single seed for the entire lifecycle of a backend process when it comes to generating UUIDs (triggered by different app users)?
Probably not.
So I could just use
Input
to pass around this seed frommain
Wait, that won't work.
But if it restarts for some reason, it will start assigning the same UUIDs, won't it?
I need to update it as well.
The initial seed will be generated in IO and random.
Guess I need to track the seed in
Polysemy.State
I just wonder whether it makes sense to pass seed around in pure
State
or whether you could just create mutable var once you're already usingIO
The later is probably better. SoPolysemy.Random
is out of core?Wait wait, I misread
It's in
polysemy-zoo
- if you don't mind dependencies, you can use itLast time I tried it I had trouble with making deps happy in nix. It is called a zoo after all.
I suppose I could just create a
UUID
effect./me looks at https://github.com/polysemy-research/polysemy-zoo/pull/60
Well, there is always unsafePerformIO lol
Running
nextRandom
intoIO
seems reasonable - you probably have it in your stack somewhere anyway, so I don't think there's any reason to lie about purity :slight_smile:Oh yea, I can do IO. But you have to create a whole new GADT with one constructor
nextUUID
just for this right?You need new effect if you don't want to use
Embed IO
directlyif it's going to be an effect with only one constructor that gives a value you might as well use
Input
, or am I missing something?