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

71–80 of 265 posts

Re: Major standard library changes in Go 1.20

#71

Post by erik_seaberg »

shaunsingh0207 wrote: post #64
klodolph wrote: post #58

Earlier quoted context omitted.

I write both Go and Rust. Rust is definitely more complex. Go, the language, is simpler, which means that Go code is more verbose and explicit. Rust, the language, is more complex. People take advantage of the complexity and implement all sorts of macros and templates. The code is shorter but less explicit. I don't think this is really a "citation needed" kind of discussion. This is basically how Rust is advocated--y…

> Rust, the language, is more complex. People take advantage of the complexity and implement all sorts of macros and templates. I'd say you pay for the complexity when you learn the language. Once satisfying the borrow checker becomes second nature, it feels just as fast to write as go (in my opinion, after switching from go to rust for most of my scratchpad code)

And you’re going to amortize what you learned over years. A short learning curve is like a toolbox that’s nearly empty.

Re: Major standard library changes in Go 1.20

#72

Post by revskill »

candiddevmike wrote: post #2

Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

No, Go programmers are get paid to get if err != nil done correctly.

Re: Major standard library changes in Go 1.20

#73

Post by klodolph »

cormacrelf wrote: post #44
slimsag wrote: post #29

Earlier quoted context omitted.

> now you're just going to do it? "you can’t import it by default", "you probably shouldn’t be using it at all", "experimental arena package", and 'you must opt-in to even be able to use it via an GOEXPERIMENT environment variable' As for screams from Rust/Go people about how bad C is, it said: > This is highly efficient, but also highly dangerous. What if the programmer makes a mistake [...] > > To mitigate the risk…

> and goes on to explain that each arena has its own unique/distinct address space That does not seem to be how it is implemented now. Try the example use-after-free on https://uptrace.dev/blog/posts/go-memory-arena.html under 'Address Sanitizer'. There is no error at all when you dereference, it silently keeps working as freed pointers often do (until they don't). Maybe they will add the virtual address space thing…

If you want network buffers in Go, you can just use []byte. The Go GC is designed to make this work well, so nobody in Go is asking for a separate buffer type like you have in Java. In Java you have Buffer in the first place because there are good reasons why you might not want to use byte[].

Unboxed C types in Go can be done with cgo (it's not necessarily pleasant, but it works).

Re: Major standard library changes in Go 1.20

#75

Post by klodolph »

astrange wrote: post #54
zozbot234 wrote: post #33

Earlier quoted context omitted.

> I mean, you should hear the screams from Rust/Go people about how bad C is, and now you're just going to do it? Wait until you learn how Rust now has a crate that implements seamless concurrent tracing GC, just like Go... https://redvice.org/2023/samsara-garbage-collector/

Sounds fine to me. That's safe. But if you have a compacting GC, you shouldn't need an arena. You should be able to get away with fixing the GC.

> You should be able to get away with fixing the GC.

Practically speaking, "fixing the GC" is just a really, super hard problem. You're making a tradeoff between memory usage, CPU usage, pause times, and the performance of various features like pinned objects.

It makes sense that you may want different tradeoffs in different parts of your program. "Fixing the GC" is right up there with "just make a smart enough compiler" type sentiment that gets you in trouble--it's easy to say that you desire a better GC or better compiler, but when you actually try to make a better GC or better compiler, you find out that it doesn't solve the problems you were hoping it would solve.

Go's GC is tuned aggressively for short pause times. A lot of people actually want short pause times in their GCs, enough so that it's a selling point for Go. In Go, those short pause times were achieved partly by sacrificing CPU efficiency. You can't just go in and "fix" the CPU efficiency problems, but you can make new APIs that give you an escape hatch.

Re: Major standard library changes in Go 1.20

#76

Post by 7to2 »

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.

Re: Major standard library changes in Go 1.20

#77

Post by heretoo »

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…

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

Re: Major standard library changes in Go 1.20

#78

Post by [deleted] »

amscanne wrote: post #50
p-e-w wrote: post #35

[flagged]

This is a strange take to me. The last thing in the world that I would accuse the Go developers of is being frantic. There have been discussions about generics for a decade. See this post, for example, that goes into a bit of the history: https://go.dev/blog/generics-proposal Keep in mind that the arena thing is not from the Go developers for general purpose usage, I suspect it’s an internal detail that might be usef…

[deleted]

Re: Major standard library changes in Go 1.20

#79

Post by mseepgood »

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…

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

Re: Major standard library changes in Go 1.20

#80

Post by [deleted] »

amscanne wrote: post #50
p-e-w wrote: post #35

[flagged]

This is a strange take to me. The last thing in the world that I would accuse the Go developers of is being frantic. There have been discussions about generics for a decade. See this post, for example, that goes into a bit of the history: https://go.dev/blog/generics-proposal Keep in mind that the arena thing is not from the Go developers for general purpose usage, I suspect it’s an internal detail that might be usef…

[deleted]
Post reply on HN