How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc?
I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a strong industry backing.
Go has probably the most extensive stdlib of major languages outside of Python (happy to be corrected on that). You can get a sense for what is available by looking here: https://pkg.go.dev/std. There is also the "pseudo stdlib" that is maintained by the Go project but for one reason or another is not available in the stdlib currently: https://pkg.go.dev/golang.org/x
.NET is a strong contender, I would say. The standard library is immensely useful, and many things you may wonder if you need are available as Nuget packages, coming from the same devs who build the std lib.
That’s indeed true, but it wasn’t a constraint so I thought it may be of interest to post it :D should have added a note regarding that though, but I can no longer edit.
Go's net/http is essentially the only used Go HTTP(S) server. It is often wrapped with other libs to add things like request routing, but it is always used as the actual HTTP implementation. Not sure why you're saying its purpose is "hello world".
The Java one is not usable in anything beyond hello world, and is explicitly not intended to be.
As someone maintaining a pretty large networking industry proprietary app based entirely on net/http in terms of any kind of HTTP communication, I feel like I can easily tell you are wildly exaggerating. Admin consoles and enterprise connectors are entirely irrelevant to many uses of an HTTP server. Hell, even Kubernetes' API server is built using net/http.
There is frequently a reverse proxy in front of all web services. It’s got nothing to do with the quality of the implementation behind the curtains. And “the actual load” is by definition managed by the endpoint not the router.
I mean it would be trivial to implement that reverse proxy in Go. And I do mean trivial; Go also includes a reverse proxy utility, so you can implement something basic in about 5 LOC.
At this point it’s hard to believe you’re being genuine.
Kubernetes API server is not dependent on Apache, NGINX, HA Proxy, IIS, ... taking care of the actual load, since it's not getting any significant amount of traffic. In general API servers have much bigger scaling problems with actually executing the API calls rather than handling requests at scale. Having an NGINX or something similar to serve some static content and also reverse proxy to a Go server is sometimes nice if you're also serving a large UI app, but in that case NGINX is very much doing trivial work, and Go net/http is handling the real work.
Given that it was only added in Java 18 and it is a simple static file server (no way to run custom code when serving a URL), I don't think it's in any way widely used at the moment.
Edit: or will ever be. It is definitely explicitly not an equivalent of go's net/http. Indeed, there is probably never going to be an equivalent of net/http in the Java stdlib (since they prefer to rely on the user choosing one of the existing server frameworks, such as Jetty).
Yes, per the JEP that was linked, it is only intended as a toy server for quick example code, essentially:
> Provide a command-line tool to start a minimal web server that serves static files only. No CGI or servlet-like functionality is available. This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts.
> It is not a goal to provide a feature-rich or commercial-grade server. Far better alternatives exist in the form of server frameworks (e.g., Jetty, Netty, and Grizzly) and production servers (e.g., Apache Tomcat, Apache httpd, and NGINX).
Hell, I'll argue Go standard library is more extensive and better than Python's. Case in point: HTTP. The batteries included in Python definitely reflect the era of their creation.
It’s extensive, web server focused, ergonomic and has well documented and sensible security defaults.
In Go you can write a production ready, well tested, _concurrent_ web application with routing, auth, sql storage, html templating, image optimization, and so on without fetching third party libraries. And you’re not leaving official docs for it.
Almost. The sql package is just an abstract layer which requires a 3rd party module to provide the concretions. I guess the API is the same, but you still need a 3rd party lib :)
Go is a good alternative. It has support for smtp and data serialization formats. I highly recommend it. Using a single compiled binary for deployment will be a nice addition too. If you have patience to try it for 2-3 months you may fall in love with it.
One of my favourite Go security features is the single binary output, it means I can build my binaries into a distroless base image container for running in K8S. It removes a huge attack and vulnerability surface that containers introduce.
My team uses Go whereas the rest of the company heavily uses Python. Our vulnerability scanner tool detects hundreds of high score CVEs just in their container images. Comparably there have been times I haven’t updated our distroless base image for a year and there isn’t even a single vulnerability (this one: https://github.com/GoogleContainerTools/distroless/blob/main...)
In terms of defending your software supply chain, eliminating the cruft that is required to run an interpreted language in a container make a a huge difference.
Ironically the need to include a distro is true with Java as well. It’s not about running an interpreter so much as having your runtime living external to your code.
Go has a runtime, of course, but it’s part of the binary.
Try it. It has some quirks, but what sold me is that it has sane defaults almost everywhere.
My first time with Go was one of the rare experiences, where I just wrote code in a new language (some cryptography, some interactions with rest APIs), and it just worked. No wrestling with obscure features, no hidden magic.
Currently I use it very often for various side projects.
I wish they'd gone with 2001-02-03T04:05:06 (sub 16 for 24h, obvs) because that at least is in numerical order (and you can use +07 for timezone.) There's surely no date format in existence where month comes first and year comes last -after the time-. Or if they were stuck on 2006, 2006-05-04T03:02:01 but then you get +00 for the timezone which might be weird.
On the contrary, I much prefer the fixed date of "2006-01-02T15:04:05" for formatting time strings. I find it much easier to write "Mon 02, Jan 2006", than what you would usually put for the strftime equivalent, "%a %d, %b %Y" (had to look it up, and at a glance it's not that obvious what it formats to). With Go, all you need to memorise is the date itself. Granted, coming from other languages it can take a bit of getting used to.
This is what the documentation has to say about it:
> These are predefined layouts for use in Time.Format and time.Parse. The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT). That value is recorded as the constant named Layout, listed below. As a Unix time, this is 1136239445. Since MST is GMT-0700, the reference would be printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day.
Using the American convention is regrettable, but putting the year after the time is even more regrettable IMHO. Not sure which timestamp format does that? Plan 9?
It's really annoying. Esp. For a person that uses golang occasionally, like me. Thankfully, Goland learned how to autocomplete these inside format strings.
Go's standard library is much better than Python's. Python does not actually provide what you list as bare minimum since the http library is not production ready. Go's net/http is and it's what most people actually use.
I agree that golang's standard library is high quality, nice, readable, permissive license. I have had several experiences porting parts of the Golang standard library to other languages such as C++ and have really enjoyed it. Golang's standard library has rich tests, such as fuzz tests, so the results after porting were also easily verifiable.
Groovy would be the most "batteries included" JVM language I think ... latest version even bundled YAML support in the standard library. Of course, it has all the downsides of a "kitchen sink" approach to language design.
Go has one of the best stdlib I've come across.
It's very well written and documented, the code is extraordinarily clean and easy to understand, even for advanced topics like cryptography (of course you need some fundamental understanding here).
I think it's comparable to Python.
Go's stdlib was one of the reasons I ended up with Go instead of Rust (might have changed; Rust had a lot community content, but not a comprehensive stdlib; last checked 3-4 years ago).
> Rust had a lot community content, but not a comprehensive stdlib; last checked 3-4 years ago
Still the case now (depending on your definition of ‘comprehensive’ of course). It’s an explicit non-goal of Rust to include “everything” (eg. http, crypto, random numbers) in std because of the stability promises - you can’t make breaking changes to std unless you’re fixing a soundness issue AFAIR.
I was evaluating Rust for some cryptography use case and there were only "random" community libs available that lacked support here and there. And I actually had no trust in any of those libs.
A stdlib must not contain everything but a solid cryptography lib is probably a good idea.
If I needed some admin interface etc I'd use Django and then everything else I'd write in Go. There were occasions where I'd write a service in Python and then rewrite it in Go. Never found that I needed something and it was lacking in the standard library. It's very fine experience.
Then what I like the most is Go is extremely reliable. I had Go services running with a couple of years uptime, flawless.
Dynamic typing. Dealing with structured data and (de)serialisation was a major pain. To me Go feels like a stricter python, still having enough freedom to do most things relatively easily, but not having to worry about what's being passed around.
Interesting, three replies and all about strict types. In my own experience moving to Go from PHP downsides was exactly strict typing and (de)serialization. It is a major pain to handle variable JSON schemas, especially in verbose multi-nested objects in Go without falling back to reflections, which is faux pas there.
I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a strong industry backing.