Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UUID package coming to Go standard library

github.com

Post reply on HN
Print view View original

241–250 of 260 posts

Re: UUID package coming to Go standard library

#241

Post by [deleted] »

LtWorf wrote: post #231
HendrikHensen wrote: post #140

Earlier quoted context omitted.

I cannot identify with this at all. We have Python and Go applications in production, and for Go the vibe is mostly "standard library plus a few dependencies" (e.g. SQL driver, opentelemetry) whereas with Python it's mostly "we need a dozen libraries just to get something done". For example Go has production ready HTTP server and client implementations in the standard library. But with Python, you have to use FastAPI…

Seems to me you overcomplicate your python dependencies on purpose and then complain that they are complicated. I've never seen a go program that is more than hello world that has only 1 or 2 dependencies in my whole professional life.

[deleted]

Re: UUID package coming to Go standard library

#242

Post by jkrejcha »

da_chicken wrote: post #166
gzread wrote: post #151

Earlier quoted context omitted.

byte[16] is well supported by most languages and storage systems.

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).

Re: UUID package coming to Go standard library

#243

Post by knorker »

grey-area wrote: post #224
knorker wrote: post #214

Earlier quoted context omitted.

Well, for C++ the backwards compatability is even better. Unless you're using `gets()` or `auto_ptr`, old C++ code either just continue to compile perfectly, or was always broken. Sure, the Go standard library is in some sense bigger, so it's nice of them to not break that. But short of a Python2->3 or Perl5->6 migration, isn't that just table stakes for a language? The only good thing about Go is that its standard l…

But any time you need to step outside of that, it starts a bit-rotting timer that ticks very quickly. This is not my experience with my own or third party code. I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade, and perhaps one caused by changes to a third party library (sendgrid, who changed their API with breaking changes, not really a Go problem). A…

>> But any time you need to step outside of that

"That" here refers to the standard library, so:

> I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade

I agree. But I'm saying it's a very low bar, since that's true for every language. But repeating myself I do acknowledge that Go in some senses has a bigger standard library. It's still just table stakes to not break stdlib.

> A 'bit-rotting timer' isn't very specific or convincing, do you have examples in mind?

I don't want to dox myself by digging up examples. But it seems that maybe half the time dependabot or something encourages me to bump versions on a project that's otherwise "done", I have to spend time adjusting to non backwards compatible changes.

This is not my experience at all in other languages. And you would expect it to be MORE common in languages where third party code is needed for many things that Go stdlib has built in, not less.

I've made and maintained opensource code continuously since years started with "19", and aside from Java Applets, everything else just continues to work.

> sendgrid, who changed their API with breaking changes, not really a Go problem

To repeat: "It seems that language-culturally, Go authors are fine with breaking changes".

Re: UUID package coming to Go standard library

#244

Post by knorker »

herewulf wrote: post #216
knorker wrote: post #189

Earlier quoted context omitted.

Really? My experience is that of C, C++, Go, Python, and Rust, Go BY FAR breaks code most often. (except the Python 2->3 change) Sure, most of that is not the compiler or standard library, but dependencies. But I'm not talking random opensource library (I can't blame the core for that), but things like protobuf breaking EVERY TIME. Or x/net, x/crypto, or whatever. But also yes, from random dependencies. It seems that…

Isn't the x for experimental and therefore breaking API changes are expected?

Sure.

To repeat: "It seems that language-culturally, Go authors are fine with breaking changes". I just chose x as examples of near-stdlib, as opposed to appearing to complain about some library made by some random person with skill issues or who had a reasonable opinion that since almost nobody uses the library, it's OK to break compat. Protobuf is another. (not to mention the GCP libraries, that both break and move URLs, and/or get deprecated for a rewrite every Friday)

The standard library not breaking is table stakes for a language, so I find it hard to give credit to Go specifically for table stakes.

And it's not like Go standard library is not a bit messy. As any library would be in order to maintain compatibility. E.g. net.Dialer has Timeout (and Deadline), but it also has DialContext, introduced later.

If the Go standard library had managed to maintain table stakes compatibility without collecting cruft, that'd be more impressive. But as those are contradictory requirements in practice, we shouldn't expect that of any language.

Re: UUID package coming to Go standard library

#245

Post by gethly »

Mawr wrote: post #239
gethly wrote: post #146

Seems pointless. Go should focus on refactoring core libraries, especially net and http, for performance because nbio, gnet and others are kicking its ass. And that is sad, as third party libraries should never perform better than standard library. Also swiss tables were great addition to Go's native maps, but then again there are faster libraries that can give you 3x performance(in case of numeric keys).

> And that is sad, as third party libraries should never perform better than standard library. It's quite literally the opposite. The purpose of a stdlib is standardization, stability, and broad usefulness, not extreme performance. In fact, that can't be its purpose — you can only get max performance if you tune for your exact use case — but how could a stdlib that's by definition generic ever be able to do that? > b…

Standard library often has access to low level code that the user space does not. Hence why it must be the most performant code there is. Period. As for the maps, there is no reason why swiss maps must be used for every key type. Optimising the hashing for specific types makes a lot of sense and is a waste if not done.

Re: UUID package coming to Go standard library

#246

Post by efilife »

3eb7988a1663 wrote: post #185
jasomill wrote: post #117

Earlier quoted context omitted.

1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble. The fact that we're discussing this at all is a reasonable argument for using a library function.

While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?

What do you mean? Are you talking about validation of UUIDs?

Re: UUID package coming to Go standard library

#247

Post by grey-area »

knorker wrote: post #243
grey-area wrote: post #224

Earlier quoted context omitted.

But any time you need to step outside of that, it starts a bit-rotting timer that ticks very quickly. This is not my experience with my own or third party code. I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade, and perhaps one caused by changes to a third party library (sendgrid, who changed their API with breaking changes, not really a Go problem). A…

>> But any time you need to step outside of that "That" here refers to the standard library, so: > I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade I agree. But I'm saying it's a very low bar, since that's true for every language. But repeating myself I do acknowledge that Go in some senses has a bigger standard library. It's still just table stakes t…

I disagree about culture, I’d say that’s the culture of js.

For Go I’d say it’s the opposite and you have obviously been unlucky in your choices which you don’t want to talk about.

But it is not a universal experience. That is the only third party package with breaking changes I have experienced.

Re: UUID package coming to Go standard library

#248

Post by 3eb7988a1663 »

efilife wrote: post #246
3eb7988a1663 wrote: post #185

Earlier quoted context omitted.

While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?

What do you mean? Are you talking about validation of UUIDs?

If you generate random bytes, which are unlikely to conform to the UUIDv4 spec, my guess is that most libraries will silently accept the id. That is, generating random bytes, will probably work just work.

Re: UUID package coming to Go standard library

#249

Post by 3eb7988a1663 »

kbolino wrote: post #229
3eb7988a1663 wrote: post #183

Earlier quoted context omitted.

Honestly the problem was they did not go far enough. They hoped to have a minimal churn switch to avoid getting locked into bikeshedding for the rest of time. However, there was so little user user facing improvements that the required change hardly seemed worth porting. They also failed to initially offer any automatic porting tooling which could have increased adoption. I will be forever mad that they did not use t…

> They also failed to initially offer any automatic porting tooling which could have increased adoption. Maybe it wasn't very good, but 2to3 was there from the start: https://docs.python.org/3.0/library/2to3.html

Huh, so it was. Thanks for the correction.

Re: UUID package coming to Go standard library

#250

Post by efilife »

3eb7988a1663 wrote: post #248
efilife wrote: post #246

Earlier quoted context omitted.

What do you mean? Are you talking about validation of UUIDs?

If you generate random bytes, which are unlikely to conform to the UUIDv4 spec, my guess is that most libraries will silently accept the id. That is, generating random bytes, will probably work just work.

But what libraries are you talking about? What is their purpose?
Post reply on HN