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

111–120 of 265 posts

Re: Major standard library changes in Go 1.20

#111

Post by groestl »

badrequest wrote: post #81
threeseed wrote: post #56

Earlier quoted context omitted.

[flagged]

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.

> they never expect things like file reads to fail.

They not only expect file reads to fail, they also expect stack overflows, out of memory etc etc. and a lot more. They also know that, more often than not, the place where something fails is not the place where you have enough information to recover properly.

Re: Major standard library changes in Go 1.20

#112

Post by fancybouncy »

dzikimarian wrote: post #105
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…

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.

Re: Major standard library changes in Go 1.20

#113

Post by jrockway »

kubb wrote: post #97
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.

Please be respectful, nobody is regurgitating anything. People are frustrated because half of their programs are if err != nil { return nil, somestruct{}, false, "", err }

I've written several hundred thousands of lines of Go at this point, and the error handling mechanics have never bothered me. There are two things that bother me about errors; error messages that don't capture enough detail to reproduce the situation (user ids, for loop iterator, etc.; you don't get these in stack traces either), and people that discard one error to return another one (i.e. a blind defer x.Close()). With go 1.20, I have one less concern. If that makes you mad, I feel like these people that smugly reply "touch grass" are on to something.

Re: Major standard library changes in Go 1.20

#114

Post by eptcyka »

klodolph wrote: post #73
cormacrelf wrote: post #44

Earlier quoted context omitted.

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

Why do Go enthusiasts look at types that specialize more generic data structures to ensure invariants and scoff? Maybe go only ever needed []byte, and nothing else - it's always just bytes anyway, right?

Moreover, when the go team accomplishes the same goals by extending the language instead of using a library, this is well received.

Re: Major standard library changes in Go 1.20

#115

Post by groestl »

kubb wrote: post #98
mixedCase wrote: post #13

Earlier quoted context omitted.

The joys and woes of reinventing computer programming right where it was left off in the early 70s.

I think I can sympathise, it's hard to keep up with all the development in PL, so it's easy to convince yourself that all those new inventions are stupid anyway and you don't need them, you'll do it your way. And then, slowly over a couple of decades, other people will be making it their life's work to add in the things that you thought were stupid because inevitably the need for them surfaces.

Or you've seen an approach fail spectacularly in a programming language you're familiar with, which causes you to throw out the baby with the bath water.

Re: Major standard library changes in Go 1.20

#116

Post by SergeAx »

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?

Re: Major standard library changes in Go 1.20

#117

Post by kroolik »

fancybouncy wrote: post #112
dzikimarian wrote: post #105

Earlier quoted context omitted.

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.

It's really annoying. Esp. For a person that uses golang occasionally, like me. Thankfully, Goland learned how to autocomplete these inside format strings.

Re: Major standard library changes in Go 1.20

#118

Post by r2vcap »

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…

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.

Re: Major standard library changes in Go 1.20

#120

Post by heywhatupboys »

jchw wrote: post #41
astrange wrote: post #25

Adding manual arena memory management seems like a weird choice for a supposedly memory-safe and GC'd language where this is supposed to be an implementation issue. 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?

I mean, it's opt-in. If you really want to crap your pants, in today's Go, you can import C and call malloc and free, then import unsafe and make pointers into the void. The point of memory safe programming languages is NOT that they entirely disallow all unsafe operations, it's that the language has a proper model for memory safety. In Rust, unsafe code needs to be in unsafe blocks. In Go, unsafe code is only possib…

> In Go, unsafe code is only possible by importing unsafe or C.

of course, this is completely wrong, for anyone reading this. that is simply not how systems work

Post reply on HN