Golang lack of support for basic stuff like this is quite annoying.
[flagged]
Open the python documentation if you're curious of why people are downvoting you.
UUID package coming to Go standard library
91–100 of 260 posts
Re: UUID package coming to Go standard library
#92Earlier quoted context omitted.
I just write my own code and then ask AI to find any issues and correct them if I feel it is good advice. What AI is amazing at is writing most of my test cases. Saves me a lot of time.
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.
To be fair, many human tests I've read do similar.
Especially when folks are trying to push % based test metrics and have types ( and thus they tests assert types where the types can't really be wrong ).
I use AI to write tests. Many of them the e2e fell into the pointless niche, but I was able to scope my API tests well enough to get very high hit rate.
The value of said API tests aren't unlimited. If I had to hand roll them, I'm not sure I would have written as many, but they test a multitude of 400, 401, 402, 403, and 404s, and the tests themselves have absolutely caught issues such as validator not mounting correctly, or the wrong error status code due to check ordering.
Re: UUID package coming to Go standard library
#93Earlier quoted context omitted.
It’s nice to have a break from AI FUD. It reminds me of a time when I could browse HN without getting anxiety immediately, because nowadays you can’t open a comment section without finding a comment about how you ngmi.
Man... I spent the last 6 months writing code using voice chat with multiple concurrent Claude code agents using an orchestration system because I felt like that was the new required skill set. In the past few weeks I've started opening neovim again and just writing code. It's still 50/50 with a Claude code instance, but fuck I don't feel a big productivity difference.
> voice chat ... required skill set
But we're still required to go to the office, and talking to a computer on the open space is highly unwelcome
Re: UUID package coming to Go standard library
#94Earlier quoted context omitted.
UUID is just array of 16 bytes or two 64-bit ints. Generating UUIDv4 is like few lines of code. Is that a big deal? I don't think so.
16 random bytes is not a valid UUIDv4. I don’t think it needs to be in the standard library, but implementing the spec yourself is also not the right choice for 99% of cases.
Let's call it a valid UUIDv0 - all bits randomized including the version bits :)
Re: UUID package coming to Go standard library
#95Earlier quoted context omitted.
My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!
Like Python though, while the batteries are included, many of them are dead.
Yes because the formats and protocols they are for have changed so much right? -_-'
Re: UUID package coming to Go standard library
#96Earlier quoted context omitted.
Broadly speaking, maintaining a big std lib is a huge amount of work, so it makes sense that a language team is conservative about adding new surface to a stb lib which they will then have to maintain for a long time.
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 total rewrite.
edit: as usual on ycombinator, dowvotes for saying something factually true that can be easily verified :D
Re: UUID package coming to Go standard library
#97Golang lack of support for basic stuff like this is quite annoying.
It makes you look on GitHub for implementations, which later can be hijacked and used for malicious reasons
Re: UUID package coming to Go standard library
#98Earlier quoted context omitted.
It’s nice to have a break from AI FUD. It reminds me of a time when I could browse HN without getting anxiety immediately, because nowadays you can’t open a comment section without finding a comment about how you ngmi.
Man... I spent the last 6 months writing code using voice chat with multiple concurrent Claude code agents using an orchestration system because I felt like that was the new required skill set. In the past few weeks I've started opening neovim again and just writing code. It's still 50/50 with a Claude code instance, but fuck I don't feel a big productivity difference.
Really? The past two weeks I've been writing code with AI and feel a massive productivity difference, I ended up with 22k loc, which is probably around as many I'd have manually written for the featureset at hand, except it would have taken me months.
Re: UUID package coming to Go standard library
#99A slow day in Go-news land? :) It is heathwarming to see such mundane small tech bit making front page of HN when elsewhere is is debated whether programming as profession is dead or more broadly if AI will be enslaving humanity in the next decade. :)
It’s nice to have a break from AI FUD. It reminds me of a time when I could browse HN without getting anxiety immediately, because nowadays you can’t open a comment section without finding a comment about how you ngmi.
Well fortunately you’re here to take what was a discussion completely unrelated to AI and drag it back around to AI again.
If you’re tired of talking about AI, why did you post this?
Re: UUID package coming to Go standard library
#100Am I the only one who hates UUIDs and doesn't see the point of them? Having any structure whatsoever in them is pointless and stupid. UUIDs should be 128 buts of crypto.Rand() and nothing else. Argh.
I treat UUIDv4s as 128 random bits and it triggers ppl.
To be fair that’s literally just a waste of resources. If you want 128 random bits just get 128 random bits from the underlying source, unless your host langage is amazingly deficient it’s just as easy.