251–260 of 260 posts
Earlier quoted context omitted.
What other basic stuff are you thinking of?
I'd love to see proper WebSocket support, and JWTs.
I don’t disagree with you btw. JWT signing/verification and JWK support is especially something I would prefer had first class implementations. (I’m much less concerned with JWT parsing, which is trivial).
Earlier quoted context omitted.
Sure. Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG? Are you doing that every time you're generating one of these IDs in any system that might need to communicate with your API? Or maybe they just generated one random number, and now they're adding 1 every time. Now transfer it over a wire. Are you sure the way you're serializing it is how the remote system will deseri…
> Now generate your random ID. Did you use a CSPRNG, or were your devs lazy and just used a PRNG? There's nothing about UUIDs that need to make them cryptographically secure. Many programming language libraries don't (and some explicitly recommend against using them if you need cryptographically strong randomness).
Earlier quoted context omitted.
UUIDs don't use base64
You can absolutely encode a UUID in base64, as you can any string of 128 bits.
Earlier quoted context omitted.
Why it is "huge amount of work" ? Do the code reliably breaks in every new python version ?
Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons. For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the…
Earlier quoted context omitted.
I've seen tests doing: a = 1 assert a == 1 // many lines here where a is never used assert a == 1 Yes AI test cases are awesome until you read what it's doing.
I write assert(a==1) right before the line where a is assumed to be 1 (to skip a division by a) even if I know it's 1. Especially if I know it's 1!
Earlier quoted context omitted.
You can absolutely encode a UUID in base64, as you can any string of 128 bits.
128 random bits in some random format aren't a uuid. 0.2ml of water isn't a raindrop. If I say "you can provide me with a uuid" and you give me a base64-encoded string, it's getting rejected by validation. If I say "this text needs to be a Unicode string" and you give me a base64-encoded Unicode string's byte array, it's not going to go well.
Does Postgres not truly support UUID because it internally represents it as 128 bits instead of a huge number of encoded bytes in the standard representation? Of course not.
Every time I read these types of Go issues, I think I am reading a writeup of a highschool debate club. It's like there is debate just for the sake of debate. I understand the defensiveness about implementing new features, and I understand the rationale to keep the core as small as possible. But come on, it's not like UUID is a new thing. As the opener already pointed out, UUID is essential in pretty much all languag…
It's an open Github issues thread. What do you expect?