Hacker News Reader

Comment by 7to2 | Hacker News Reader

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.

View on HN

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.

Java seems to have just as much if not more available in its standard lib.

Though some modern features are lacking, like a JSON parser or web server.

It does contain several Javascript (!) interpreters, so you could probably glue those together as a JSON parser :)

Java has had a basic http server built in since 1.6

https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver...

It does have a web server: https://openjdk.org/jeps/408

> It is not a goal to provide a feature-rich or commercial-grade server.

That server is not remotely comparable to the one in Go.

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.

It is tailored for the same purpose as Go's one, hello world.

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.

The fact that is lacks any kind of administration console, and security integration with enterprise connectors shows it is at hello world level.

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.

Yet many of those depend on having something like Apache, NGIX, HA Proxy, IIS,... taking care of the actual load.

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.

So trivial that it isn't usually the case.

A weekend project and going at scale isn't the same thing.

sigh

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.

Does anyone actually use it? I’ve never even heard of this thing and I’m a professional Java dev

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

The specific web server in the JEP is relatively new, but there has been an http server implementaion since 1.6:

https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver...

Cool, I had no idea about this.

I see it's still available after the modularization effort, and it is:

https://docs.oracle.com/en/java/javase/18/docs/api/jdk.https...

From your description it sounds like it is a completely different beast from net/http

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

Not as Java and .NET.

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.

Go probably pales in comparison to .NET [0]. Its about 1 million APIs

[0] https://apisof.net/

No "outside of Python" qualifier needed.

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 :)

Most people don’t use the flags package either and opt for 3rd party, like cobra.

> with routing Don't you need some 3rd party lib for that (if you don't want to implement your own router)?

> know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time),

Compared to sat Rust Go has a very large and practical std lib ! You can actually do something with it I/O wise.

To save some of my karma points, Rust do have a big "community with crates"

In the land of C++, we have a sparse standard library and no standard package management solution

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.

I just want to second this. It takes time to love Go, but it’s worth the effort.

Actually, the single binary alone is worth the effort. But it goes much deeper than that.

You can browse the standard library here: https://pkg.go.dev/std

> what about support of smtp

Yes, https://pkg.go.dev/net/smtp

> data serialization formats

What you can find in the "encoding/*" subpackages: JSON, XML, Gob, CSV, ...

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.

except for the date api... it took me a couple days to understand the silly idiosyncratic magic string to format dates.

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 similar to the default date(1) output, except that puts the year at the very end, after even the timezone.

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.

You could consider Clojure. It is backed by the java ecosystem, which is substantial. Not quite the same as python's "batteries included" approach.

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.

Java has substantial industry backing, but you cannot argue that it has a battery-included standard library.

But to answer the question: yes, Go has support for SMTP in net/smtp and a lot of different serialization formats in encoding/

You can browse it all here: https://pkg.go.dev/std

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.

Looks like the situation improved a bit: https://cryptography.rs/

I would still like to have a more comprehensive or high level stdlib for Rust that is maintained by a core Rust team.

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.

What's wrong with Python that you want an alternative?

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’m learning a bit of Django and I can’t believe how much ceremony is involved.

Idiomatic Go eschews frameworks and - as a former Java developer - that is something I really like about it.

Dynamic Typing, Dependency management, Bundling, Speed

I desperately miss static typing.

Reply on news.ycombinator.com