Remix.run Logo
therealdrag0 5 hours ago

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

vbezhenar an hour ago | parent | next [-]

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.

danishanish an hour ago | parent | next [-]

I think it saves labor and eventual bug hunting to include these in a stdlib. We should not be expected to look up the UUIDv4 spec and make sure you’re following it correctly. This feels like exactly what reasonable encapsulation should be.

computomatic an hour ago | parent | prev [-]

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.

rollulus an hour ago | parent | next [-]

Well that depends on your luck, it could be a valid one about 1/16th of the time.

koakuma-chan 36 minutes ago | parent | prev [-]

What if I generate 16 random bytes and use that as id?

serf 5 hours ago | parent | prev | next [-]

the idea of what 'batteries included' means has changed a lot in the past twenty years, and like most Go quirks , probably Google just didn't need <missing-things>.

throwaway894345 3 hours ago | parent | next [-]

Google is the author of the de facto uuid library in Go, google/uuid. I’m very curious what people think is an exemplary “batteries included” stdlib?

tptacek 2 hours ago | parent | prev [-]

Huh? The universal idiomatic answer to "how to use UUIDs in Go programs" for the past decade has been to pull in a Google dep.

tptacek 4 hours ago | parent | prev | next [-]

What's the language you're thinking of that has more of these decisions fixed in the standard library? I know it's not Ruby, Python, Rust, or Javascript. Is it Java? I don't think this is something Elixir does better.

JimDabell 3 hours ago | parent | next [-]

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/API/Crypto/rand...

> Python: https://docs.python.org/3/library/uuid.html

> Ruby: https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/S...

tptacek 3 hours ago | parent | next [-]

You're answering the question of "which languages have UUIDs in their standard libraries" (Javascript is not one of them). That's not the question I'm asking. 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? In a Java program, if you were encrypting files or blobs, stdlib or dep?

Is C# the language that gives the Go stdlib a run for its money? I haven't used it much. JS, Python, and Ruby, I have, quite a bit, and I have the sprawling requirements.txts and Gemfiles to prove it.

I asked the question I did upthread because, while there are a lot of colorable arguments about what Go did wrong, a complete and practical standard library where the standard library's functionality is the idiomatic answer to the problems it addresses is one of the things Go happens to do distinctively well. Which makes dunking on it for this UUID thing kind of odd.

gucci-on-fleek an hour ago | parent [-]

> 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 third-party dependencies anyways.

> JS, Python, and Ruby, I have, quite a bit, and I have the sprawling requirements.txts and Gemfiles to prove it.

I checked the top 10 Go repositories on GitHub [1], and all but 1 of them have 30+ direct dependencies listed in their "go.mod" files (and many more indirect ones). Also, both C and JavaScript are well-known for their terrible standard libraries, yet out of all languages, JavaScript programs tend to use the most dependencies, while C programs tend to use the least. So I don't think that the number of dependencies that an average program in a given language uses says anything about the quality of that language's standard library.

[0]: https://docs.python.org/3/library/urllib.request.html

[1]: https://github.com/trending/go?since=monthly

PunchyHamster 12 minutes ago | parent | next [-]

> I checked the top 10 Go repositories on GitHub [1], and all but 1 of them have 30+ direct dependencies listed in their "go.mod" files (and many more indirect ones).

Big projects having big dependencies, whoopty fucking do

gucci-on-fleek a few seconds ago | parent [-]

I gave that example to refute the point that having worked on projects in other languages with tons of third-party dependencies implies that those languages have poor standard libraries. I certainly didn't intend to imply that that means that Go has a poor standard library or that small Go projects often use hundreds of third-party dependencies like JavaScript projects tend to do.

Go's package management is actually one of its strongest points, so I think that it's unsurprising/good that some projects have lots of dependencies. But I still stand by the point that you shouldn't judge a language based on how many dependencies most programs written in it use.

(Except for JavaScript, where I have no problem judging it by the npm craziness :) )

tptacek an hour ago | parent | prev [-]

Just claiming you'd use urllib is a concession. Yeah, I get it: for toy programs, you'd use the stdlib's HTTP.

That's not what happens in Golang.

gucci-on-fleek 27 minutes ago | parent [-]

Fair enough, but the quality/breadth of the standard libraries is fairly topic-specific in Go (and all languages, really). There's a reason that you picked networking and crypto for your examples, since the Go standard library is indeed really strong here—I don't even like Go, but if I had to write a program that did lots of cryptography and networking, then Go would probably be my first choice.

But lots of programs (and most of the programs that I write) don't use any cryptography, and only have trivial networking requirements, and outside those areas, I'd argue that the Python standard library [0] has broader coverage, supports more features, and is better documented than the Go standard library [1].

The Go standard library is still pretty great though, and is well ahead of most other languages; I just personally think that it's a little worse than Python's. But if you mostly write networking/crypto code, I can easily see how you'd have the opposite opinion.

[0]: https://docs.python.org/3/library/index.html

[1]: https://pkg.go.dev/std

tptacek 25 minutes ago | parent [-]

Like, at this point, I feel like we share premises. We disagree, but, fine, seems like a reasonable disagreement. A better one than how annoying it is that Golang lacks "basic stuff" like a standard UUID interface.

throwaway894345 3 hours ago | parent | prev [-]

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.

artimaeis 3 hours ago | parent | prev | next [-]

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!

jen20 3 hours ago | parent [-]

Like Python though, while the batteries are included, many of them are dead.

0x696C6961 3 hours ago | parent [-]

It begs the question, why don't these languages put out a v2 stdlib?

remus an hour ago | parent [-]

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.

PunchyHamster 12 minutes ago | parent [-]

Why it is "huge amount of work" ? Do the code reliably breaks in every new python version ?

harrall 4 hours ago | parent | prev [-]

Obviously PHP

catlifeonmars 4 hours ago | parent | prev | next [-]

What other basic stuff are you thinking of?

patrickmcnamara 9 minutes ago | parent [-]

I'd love to see proper WebSocket support, and JWTs.

orangeisthe an hour ago | parent | prev | next [-]

Go has one of the best stdlibs of any language. I'd go as far and say it's the #1 language where the stdlib is the most used for day to day programming. cut the bullshit

zdw 4 hours ago | parent | prev | next [-]

Now do Javascript.

sheept 3 hours ago | parent [-]

crypto.randomUUID()?

nwhnwh 4 hours ago | parent | prev [-]

https://github.com/rs/xid