3 ms·
> The stdlib is one of the most complete what does this mean? Go lib seems tiny compared to JDK. anytime i review some Go code from adjacent team i'm turned of
by nh23423fefe 10mo ago
> The stdlib is one of the most complete
what does this mean? Go lib seems tiny compared to JDK. anytime i review some Go code from adjacent team i'm turned off by weird stuff like append and slices everywhere, as well as a bunch of strange string packages
When I think of a massive stdlib I think of a language like groovy
- embedding-shape 10mo agoThen ask a JS web developer what "big standard library" would mean, and Go probably would fit somehow with that definition :) It seems to be very relative depending on where you come from.
- MobiusHorizons 10mo agoThe api surface is relatively small, but the capabilities you get from it (http serving, json parsing, crypto, in addition to table stakes like io, args, flags etc) are very high. Having a small api surface is why you need to use primatives so often, but the upside benefit to that is there is less domain specific knowledge, since you end up using familiar types and libraries in more of your code.
- CamouflagedKiwi 10mo agoWhen I use Go, I find I can get more real work done with only the standard library than with any other language I've used (including Java, although that was quite a while ago now). It may not have the most stuff, it is more focused - but I'm okay with esoteric stuff not being in there since the tradeoff seems to be that there are high-quality implementations of e.g. an HTTP client and server, crypto functions, a unit testing library, JSON en/decoding etc, which I can definitely use in production. Conversely in Java the answer seems to be to use BouncyCastle / Tomcat / Jackson / etc, so while there may be a big stdlib, it ends up being less useful.
- lemoncucumber 10mo agoPython's standard library seems comparable IME
- jonfw 10mo agoIn my experience, people building APIs w/ python are almost always using frameworks, while people building APIs w/ golang are almost always using stdlib
- lagniappe 10mo agoI would not agree with that assertion. Just off the top of my head, being familiar with both: - context - net/http as a full server framework, not just a request library - net/http/pprof - runtime/pprof - runtime/trace - embed - testing as the canonical, required test framework - net/rpc - net/http/cgi - net/http/fcgi - net/http/httptest - os/signal with integrated channel-based delivery - sync/atomic with language-aligned memory model semantics - runtime as a documented and supported API surface
- CamouflagedKiwi 9mo agoI've found it way more hit and miss in terms of quality. From some examples I gave: - JSON: Yup, stdlib is good here - HTTP client: There is urllib.request, although people maybe reach for requests more. - HTTP server: No, it's just some super basic thing (it's not even 'nice' to write for local dev). Would never let anything here near production. - Unit testing: Yes, I think unittest is pretty good (I actually like it a lot, and think pytest is overrated). - Crypto functions: No, not equivalent. There is hashlib but basically anything else you're pointed at pycrypto or cryptography with all the associated ecosystem nonsense (oh I need a Rust compiler now? Great...). The difference is Python _has_ all of these things in the standard library, but the quality is super mixed, and not all of them are suitable for real use.