undefined

points

[-]

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

by tptacek18 hours ago|

parent|

[-]

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.

by gucci-on-fleek17 hours 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

by tptacek17 hours ago|

parent|

[-]

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.

by gucci-on-fleek16 hours 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

by tptacek16 hours 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.

by gzread12 hours ago|

parent|

[-]

Or a GUI framework

by PunchyHamster16 hours ago|

parent|

prev|

[-]

[flagged]

by gucci-on-fleek16 hours 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 :) )

by fshr14 hours ago|

parent|

prev|

[-]

https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand...

by 151559 hours ago|

parent|

prev|

[-]

Ruby has SecureRandom.uuid and others

by throwaway89434518 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.

by thayne16 minutes ago|

parent|

[-]

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.

by artimaeis19 hours ago|

prev|

[-]

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!

by jen2019 hours ago|

parent|

[-]

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

by 0x696C696118 hours ago|

parent|

[-]

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

by fredoralive4 hours ago|

parent|

[-]

Python has some work to trim bits of it's built in libraries, see for example https://peps.python.org/pep-0594/ and https://docs.python.org/3/deprecations/index.html .

by remus17 hours ago|

parent|

prev|

[-]

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.

by PunchyHamster16 hours ago|

parent|

[-]

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

by Philip-J-Fry12 hours ago|

parent|

[-]

The work involved in maintaining a standard library is things like bug fixes. A larger standard library (or multi versions) means there's more likely to be bugs. You also have performance improvements, and when new versions of the language come out which has features to improve performance, you will most likely want to go back through and refactor some code to take advantage of it. You will also want to go through and refactor to make code easier to maintain. All of this just gets harder with a larger surface.

And the more stuff you pack into the standard library the more expertise you need on the maintenance team for all these new libraries. And you don't want a standard library that is bad, because then people won't use it. And then you're stuck with the maintenance burden of code that no one uses. It's a big commitment to add something to a standard library.

So it's not that things just suddenly break.

by can3p11 hours ago|

parent|

prev|

[-]

Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers

by LtWorf15 hours ago|

parent|

prev|

[-]

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

by Hendrikto13 hours ago|

parent|

[-]

I think the downvotes are because you did not answer the question you replied to, and instead gave a pretty unrelated rant.

by LtWorf11 hours ago|

parent|

[-]

I'm explaining that yes, code does break every new python version? Mostly because they touch the stdlib instead of just leaving it be.

by akerl_5 hours ago|

parent|

[-]

The thread is about the code in the std lib being a huge amount of work because the code in the std lib needs to be kept working with new language releases.

And then you answered about downstream code breakage totally outside the std lib.

by gzread12 hours ago|

parent|

prev|

[-]

What would that entail, just a package whitelist? A few renamed packages? In the python 3 transition they renamed urllib2 to just urllib, but now it's almost a dead battery too and you want to use requests.

by isbvhodnvemrwvn11 hours ago|

parent|

prev|

[-]

Python had enough fun with 2 to 3 transition I think.

by 3eb7988a16638 hours ago|

parent|

[-]

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 that as a breaking opportunity to namespace the standard library. Something like: `import std.io` so that other libraries can never conflict.

by kbolino54 minutes ago|

parent|

[-]

> 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

by LtWorf15 hours ago|

parent|

prev|

[-]

Yes because the formats and protocols they are for have changed so much right? -_-'

by gzread12 hours ago|

parent|

[-]

Yes, and surrounding expectations like async. Urllib doesn't pool connections.

by harrall20 hours ago|

prev|

[-]

Obviously PHP