5 ms·
Golang lack of support for basic stuff like this is quite annoying.
by therealdrag0 8mo ago
Golang lack of support for basic stuff like this is quite annoying.
- serf 8mo agothe 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 8mo agoGoogle 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 8mo agoHuh? The universal idiomatic answer to "how to use UUIDs in Go programs" for the past decade has been to pull in a Google dep.
- zdw 8mo agoNow do Javascript.
- sheept 8mo agocrypto.randomUUID()?
- tptacek 8mo agoWhat'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.
- harrall 8mo agoObviously PHP
- JimDabell 8mo agoPerhaps 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.newguid?view=net-7.0&redirectedfrom=MSDN#System_Guid_NewGuid https://learn.microsoft.com/en-us/dotnet/api/system.guid.new... > Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm... > JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand... > Python: https://docs.python.org/3/library/uuid.html https://docs.python.org/3/library/uuid.html > Ruby: https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/SecureRandom.html#method-c-uuid https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/S...
- throwaway894345 8mo agoNo 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.
- thayne 8mo agoI 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.
- throwaway894345 8mo ago
- artimaeis 8mo agoMy 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 8mo agoLike Python though, while the batteries are included, many of them are dead.
- 0x696C6961 8mo agoIt begs the question, why don't these languages put out a v2 stdlib?
- remus 8mo agoBroadly 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 8mo agoWhy it is "huge amount of work" ? Do the code reliably breaks in every new python version ?
- LtWorf 8mo agoYes, 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
- nwhnwh 8mo agohttps://github.com/rs/xid https://github.com/rs/xid
- catlifeonmars 8mo agoWhat other basic stuff are you thinking of?
- patrickmcnamara 8mo agoI'd love to see proper WebSocket support, and JWTs.
- catlifeonmars 8mo agoWhat other languages have web socket support or JWT validation as part of their standard libraries? I don’t disagree with you btw. JWT signing/verification and JWK support is especially something I would prefer had first class implementations. (I’m much less concerned with JWT parsing, which is trivial).
- vbezhenar 8mo agoUUID 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 8mo agoI 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 8mo ago16 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 8mo agoWell that depends on your luck, it could be a valid one about 1/16th of the time.
- jasomill 8mo ago1/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.
- rollulus 8mo agoNice, thanks and I agree.
- 3eb7988a1663 8mo agoWhile it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?
- orangeisthe 8mo ago[flagged]
- LtWorf 8mo agoOpen the python documentation if you're curious of why people are downvoting you.
- sethammons 8mo agoI don't buy this for one moment. Python and breaking changes are lovers. Nobody I have ever worked with builds or tries to build stdlib python. Most Go devs to pride themselves on minimal dependencies.
- LtWorf 8mo agoHonestly, I don't understand what you wrote so I cannot reply.
- deleted 8mo ago[deleted]
- HendrikHensen 8mo agoI 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 or Flask, and requests or httpx. For SQL there's SQLAlchemy I guess and probably some other alternatives (my Python knowledge is not that great), whereas again with Go the abstraction is just in the standard library and you only include the driver for the specific database. We use Renovate to manage dependency upgrades. It runs once a week. Every Python project has a handful or more dependency upgrades waiting every week, primarily due to the huge amount of dependencies and transitive dependencies in each project. The Go projects sometimes have one or two, but most of the time they're silent because there is nothing to upgrade (partly due to just having so few dependencies to begin with).
- p0w3n3d 8mo agoIt makes you look on GitHub for implementations, which later can be hijacked and used for malicious reasons
- foresto 8mo agoWhat stuff do you have in mind? I was disappointed by Go's poor support for human-focused logging. The log module is so basic that one might as well just use Printf. The slog module technically offers a line-based handler, but getting a traditional format out of it is painful at best, it lacks features that are common elsewhere, and it's somehow significantly slower than the json handler. I can only guess that it was added as an afterthought, by someone who doesn't normally do that kind of logging. To be fair, I suppose this might make sense if Go is intended only for enterprisey environments. I often do projects outside of those environments, though, so I ended up spending a lot of time on a side quest to build what I expected to be built-in. I haven't explored enough of the stdlib yet to know what else that I might expect is not there. If you have a wish list, would you care to share it?