Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

Post reply on HN
Print view View original

151–160 of 265 posts

Re: Major standard library changes in Go 1.20

#151

Post by philosopher1234 »

kaba0 wrote: post #108
zdragnar wrote: post #45

Earlier quoted context omitted.

How many languages go through the first 11 years of life without significant changes? There are lisps, which have no syntax to change, and I guess elixir, which is itself just a syntax for a very mature runtime (BEAM). Hell, even C underwent pretty major changes from 72 onwards, because every compiler supported entirely different features. Things like void functions and returning structs or unions. Granted, this pred…

> How many languages go through the first 11 years of life without significant changes Only if a language with basically zero new concepts could have just learned from the litany of other managed languages’ mistakes..

Can you give an example of a feature where the designers of go failed to consider other languages mistakes? Every discussion of there’s I’ve read has been thoughtful, open, and well cited.

Re: Major standard library changes in Go 1.20

#152

Post by philosopher1234 »

kaba0 wrote: post #109
badrequest wrote: post #81

Earlier quoted context omitted.

Every time this completely tired and worn out take is regurgitated on this website, it reminds me that people write big fat try/catch blocks because they never expect things like file reads to fail.

Exceptions are objectively better in every way (especially checked exceptions, which would definitely deserve a second chance!) You get as small/large-grained handling as you need, get sane default behavior (bubbling up to a place where you can actually handle that error), and stack-traces, while you never accidentally overlook a potential failing call (will the 100th if err 3 liner properly handle the error case or…

Here are some ways exceptions are objectively worse, so that you can be a more thoughtful person:

* Very noisy

* Do not survive network boundaries

* can but often do not survive thread boundaries

* lack important context

* easy to ignore

* obscures control flow

* difficult to handle

* in practice, rarely handled

* poor quality messages

Re: Major standard library changes in Go 1.20

#153

Post by philosopher1234 »

simiones wrote: post #147
philosopher1234 wrote: post #145

Earlier quoted context omitted.

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 ex…

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

Re: Major standard library changes in Go 1.20

#154

Post by philosopher1234 »

threeseed wrote: post #89
badrequest wrote: post #81

Earlier quoted context omitted.

Every time this completely tired and worn out take is regurgitated on this website, it reminds me that people write big fat try/catch blocks because they never expect things like file reads to fail.

Most exceptions in Java are checked so you choose to either explicitly handle them at the point they are thrown, group them with other exceptions or ignore them completely and let the entire program fail. At least you have the choice unlike in Go.

>most exceptions in Java are checked

The opposite is true.

Re: Major standard library changes in Go 1.20

#155

Post by doctor_eval »

kaba0 wrote: post #130
derkades wrote: post #123

Earlier quoted context omitted.

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

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.

Re: Major standard library changes in Go 1.20

#156

Post by doctor_eval »

thefounder wrote: post #82
7to2 wrote: post #76

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…

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.

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.

Re: Major standard library changes in Go 1.20

#157

Post by pjmlp »

bit_flipper wrote: post #83
7to2 wrote: post #76

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…

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

Not as Java and .NET.

Re: Major standard library changes in Go 1.20

#159

Post by doctor_eval »

Arbortheus wrote: post #110
thefounder wrote: post #82

Earlier quoted context omitted.

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 t…

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.

Re: Major standard library changes in Go 1.20

#160

Post by doctor_eval »

SergeAx wrote: post #116
7to2 wrote: post #76

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…

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

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.

Post reply on HN