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

231–240 of 260 posts

Re: UUID package coming to Go standard library

#231

Post by LtWorf »

HendrikHensen wrote: post #140
LtWorf wrote: post #91

Earlier quoted context omitted.

Open the python documentation if you're curious of why people are downvoting you.

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.

Re: UUID package coming to Go standard library

#232

Post by thayne »

throwaway894345 wrote: post #32
JimDabell wrote: post #23

Earlier quoted context omitted.

Perhaps I’m misunderstanding, but the linked issue seems to address this directly: > Would like to point out how Go is rather the exception than the norm with regards to including UUID support in its standard library. > C#: https://learn.microsoft.com/en-us/dotnet/api/system.guid.new... > Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm... > JavaScript: https://developer.mozilla.org/en-US/docs/Web/A…

No one is debating whether Go is missing a uuid package from its standard library; the debate is about whether this is indicative of a general trend with the Go standard library (as the gp claimed above). If you’re arguing as the grandparent did that Go regularly omits important packages from its standard library, then it’s not unreasonable to ask you for your idea of an exemplary stdlib.

I think the closest thing to an exemplary stdlin is rust's std. I think it strikes a good balance between being too small or too big. Unfortunately, what rust doesn't really have (yet) is a "blessed" set of libraries to supplement the stdlib.

The problems with a big "batteries included" standard library like go or python strives for, are that you will inevitably leave things out that at least some people consider "basic", like uuid, and parts of stdlib will probably have lower quality than third party libraries, like pythons urllib or gos log package, and it is constrained by needing to maintain backwards compatibility and being tied to the language's release cycle.

Re: UUID package coming to Go standard library

#233

Post by da_chicken »

intelVISA wrote: post #192
gzread wrote: post #168

Earlier quoted context omitted.

How's your UUIDv4 generated? > Are you sure the way you're serializing it is how the remote system will deserialize it? It's 16 bytes. There's no serialization.

Vibe endian

Schrodinger's complement

Re: UUID package coming to Go standard library

#234

Post by tomhow »

PunchyHamster wrote: post #75
gucci-on-fleek wrote: post #61

Earlier quoted context omitted.

> If you wrote a new Python program today that needed to make HTTP requests, would you rely on the stdlib, or would you pull in a dep? For a short script, the standard "urllib.request" module [0] works pretty well, and is usually my first choice since it's always installed. For a larger program, I'll usually use a third-party module with more features/async support though, but I'll only do this if I'm using other thi…

[flagged]

Please don't post sneers and swipes like this on HN. The guidelines make it clear we're trying for much better than this.

https://news.ycombinator.com/newsguidelines.html

Re: UUID package coming to Go standard library

#235

Post by tomhow »

orangeisthe wrote: post #64
therealdrag0 wrote: post #3

Golang lack of support for basic stuff like this is quite annoying.

[flagged]

> cut the bullshit

You can't comment like this on Hacker News, no matter what you're replying to. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Re: UUID package coming to Go standard library

#236

Post by zadikian »

8organicbits wrote: post #211
zadikian wrote: post #199

Earlier quoted context omitted.

Common one is if you want two structs deemed "equivalent" based on a few fields to get the same ID, and you're only concerned about accidental collision. There are valid use cases for that, but I've also seen it misused often. v7 rough ordering also helps as a PK in certain sharded DBs, while others want random, or nonsharded ones usually just serial int.

Have you seen UUIDv3/v5 used there though? I've seen lots of md5 historically and sha variants recently, but not the UUID approach.

Yeah, I've seen both 3 and 5 used, not just hashes in some custom format. That way it works with Postgres uuid type etc.

Re: UUID package coming to Go standard library

#237

Post by throwaway894345 »

thayne wrote: post #232
throwaway894345 wrote: post #32

Earlier quoted context omitted.

No one is debating whether Go is missing a uuid package from its standard library; the debate is about whether this is indicative of a general trend with the Go standard library (as the gp claimed above). If you’re arguing as the grandparent did that Go regularly omits important packages from its standard library, then it’s not unreasonable to ask you for your idea of an exemplary stdlib.

I think the closest thing to an exemplary stdlin is rust's std. I think it strikes a good balance between being too small or too big. Unfortunately, what rust doesn't really have (yet) is a "blessed" set of libraries to supplement the stdlib. The problems with a big "batteries included" standard library like go or python strives for, are that you will inevitably leave things out that at least some people consider "ba…

I didn’t have a strong opinion on standard library sizes until I tried Rust, but Rust was not a very pleasant experience because there were not standard packages or even consistent community advice for things as pervasive as error handling or async.

But I understand people have different opinions and that there will never be a standard library that appeases everyone. I don’t think “having a batteries included library” aims to appease everyone either. But mostly I just don’t understand the people who criticize Go for not having enough things in their standard library because Go’s standard library is one of the more useful (which may not be everyone’s ideal).

Re: UUID package coming to Go standard library

#238

Post by iJohnDoe »

sethammons wrote: post #106
vips7L wrote: post #22

Earlier quoted context omitted.

People are weird. A few days ago someone on /r/Java was arguing that a basic JSON parser shouldn’t be in the standard library.

Anecdote: about 8 years ago, I was interviewing hundreds of candidates for a non-java shop but you could interview in java if desired. One java dev ever was able to figure out parsing json with ease. Every single other java interview the person struggled with json. It was weird.

> interviewing hundreds of candidates

For one position? To fill a department or company?

Re: UUID package coming to Go standard library

#239

Post by Mawr »

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?

> but then again there are faster libraries that can give you 3x performance(in case of numeric keys)

Yeah, exactly. If you can constrain your problem domain ("numeric keys only"), you can always squeeze out more performance than a generic algorithm can give you. Completely irrelevant as far as stdlib goes though.

Re: UUID package coming to Go standard library

#240

Post by bigstrat2003 »

jen20 wrote: post #29
artimaeis wrote: post #24

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

But they're there. I would much rather have a stdlib option which isn't as good as the most popular third party solution, than not have an stdlib option at all. You can't always count on being able to install stuff from pypi, but you can always count on the stdlib being present.
Post reply on HN