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

101–110 of 265 posts

Re: Major standard library changes in Go 1.20

#101

Post by philosopher1234 »

downvotetruth wrote: post #95
p-e-w wrote: post #59

Earlier quoted context omitted.

Yes, generics (and many other proposals, like improved error handling) have been discussed for a long time. But for an almost equally long time, nothing happened. Go was stagnating for years until very recently, and the consensus seemed to be that the well-known deficiencies of the language were simply "what Go is", and anyone who doesn't like it just doesn't get it. Now suddenly we have generics, and a bunch of othe…

The near meaningless vision seems to be to see what sticks without using types in the lexer & parser https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/0h-2... . Take array declaration being prefixed to the type name to prevent ambiguity with int []a, b; vs int a[], b; & then Ian & the rest doubling the work back & reusing postfix [] for generics resulted in making inferable type identifiers turn into required i…

I can barely understand what you're saying.

Re: Major standard library changes in Go 1.20

#102

Post by scaredginger »

rawoke083600 wrote: post #93
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…

> 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

Re: Major standard library changes in Go 1.20

#104

Post by kaba0 »

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 you might not want to use byte[]

Such as? Java buffers use byte arrays by default as underlying storage.

Re: Major standard library changes in Go 1.20

#105

Post by dzikimarian »

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.

Re: Major standard library changes in Go 1.20

#106

Post by kaba0 »

lnxg33k1 wrote: post #38
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…

Yeah I think a language is safe or unsafe according to the ecosystem they live in. A project a developer works on is hardly 100% self-developed and depends on library and third party code, so I understand you have experiments you need to enable, but once it starts spreading in libraries, I think the whole safety guarantee just goes out of the window? As a rust student myself, even the unsafe{} block is stupid

Rust’s unsafe is still much safer than your average C code. The borrow checker checks inside unsafe blocks as well, you can just circumvent it through pointers.

But the great thing with unsafe blocks is that you get to create a safe API abstraction on top. You manually verify closely the unsafe parts, and if you got that short part right you can use the safe wrapper wherever you want safely.

Re: Major standard library changes in Go 1.20

#107

Post by maurice2k »

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

Re: Major standard library changes in Go 1.20

#108

Post by kaba0 »

zdragnar wrote: post #45
metadat wrote: post #3

Earlier quoted context omitted.

The only constant is change. Especially with Go, apparently. It's hard to evaluate the comparison of Golang of today to the one I originally discovered 11 years ago in 2012. Then, it was a breath of fresh air. Nowadays.. I find myself sighing. It works but the joy has faded. Bit rot is life.

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

Re: Major standard library changes in Go 1.20

#109

Post by kaba0 »

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.

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 just make your code continue to run in a no longer valid state?).

Re: Major standard library changes in Go 1.20

#110

Post by Arbortheus »

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.

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.

Post reply on HN