Hacker News new | ask | show | jobs
by TheDong 1587 days ago
> seems to be anti-go to package such niche capabilities in the stdlib

Go seems to tend heavily on the side of packaging things into the stdlib.

It has stuff like "net/rpc/jsonrpc" (a json-rpc 1.0 impl, even though you should use grpc or json-rpc 2.0, both of which are not in the stdlib). It has crap like net/smtp and archive/tar. It has image/jpeg for some unknown reason.

If you look at rust, basically half of go's stdlib exists as external crates (even if they're officially maintained, akin to the golang.org/x/ packages in go). Everything from json, to http, to image support in rust is outside the stdlib, and honestly that has ultimately let rust evolve better support for each of those things.

C, C++, (to a lesser extent) java, D, etc.. basically every language in a similar space to Go has a much smaller and more compact stdlib.

The go stdlib clearly doesn't err on the side of being small.

2 comments

Deno is another project that is trying to add more to a stdlib. In some ways this is really fantastic because in the JavaScript ecosystem there is so much fatigue in deciding what libraries to use. On the flip side, if you couple too much into the stdlib then you’re limiting the huge benefit of an open market.
> It has image/jpeg for some unknown reason.

I don't know why they added this and the other image packages specifically, but I used this the other day and it was nice to not have to bring in a separate package.

I mean, they realized their mistake for other image formats, hence: golang.org/x/image: https://pkg.go.dev/golang.org/x/image

Now it's really confusing to have to figure out to import stdlib image for jpeg, but x/image for bmp.

For bonus points, check out "image/draw" vs "golang.org/x/image/draw".