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

61–70 of 265 posts

Re: Major standard library changes in Go 1.20

#61

Post by jitl »

threeseed wrote: post #52
impulser_ wrote: post #46

Earlier quoted context omitted.

The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve. Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks. Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to…

[flagged]

I think Rust at least twice as complex Go, and an order of magnitude is not unreasonable estimate. For example, there’s only `string` in Go. How many string types are there in Rust? Even a beginner must understand &str vs String. The concept of lifetimes I find easy, but that isn’t the case for everyone - and the ramifications of the borrow checker are often a “brick wall” for me.

Anyone who’s written Typescript or Python can pick up Go and write average quality Go code in a few days after going through the tour (https://go.dev/tour/list). 10 years ago, I did the tour and the next day wrote an animated GIF for the terminal. Everything I needed was in the standard library (yes, including GIF parsing), although I eventually used a package for color quantization.

If there’s a learning resource like the Go tour for Rust that can get me from zero to writing an animated gif player in a couple of days, I’d love to hear about it! So far I haven’t been able to make my way through the Rust book at an exciting pace.

Re: Major standard library changes in Go 1.20

#62

Post by mseepgood »

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

Earlier quoted context omitted.

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…

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…

> Will "Go 2.0" with breaking changes happen or not?

It has been made clear that this will not happen. The changes of the last years ARE the "Go 2" initiative, but there won't be a major version bump.

Re: Major standard library changes in Go 1.20

#63

Post by amscanne »

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

Earlier quoted context omitted.

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…

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…

It moves slowly for sure, but there are answers to your questions in plain sight. This might be a good place to start: https://go.dev/blog/toward-go2 (published five years ago, on the 10th anniversary Go).

Re: Major standard library changes in Go 1.20

#64

Post by shaunsingh0207 »

klodolph wrote: post #58
threeseed wrote: post #57

Earlier quoted context omitted.

> developing in Go requires much less time and effort Show me the empirical evidence otherwise it's just an opinion. I also have an opinion which is that Go and Rust are about equal in complexity.

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)

Re: Major standard library changes in Go 1.20

#65

Post by jitl »

p-e-w wrote: post #53
impulser_ wrote: post #46

Earlier quoted context omitted.

The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve. Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks. Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to…

Almost nobody builds a server from scratch in either Go or Rust. People use libraries and frameworks for that, because while the basics are easy enough to understand, getting the details wrong means security vulnerabilities and subtle, hard-to-find bugs. So unless you're only interested in playing around, what the core language can do isn't important. When writing a server in Rust, probably the first thing you would…

I don’t enjoy Go very much (gave up due to err != nil exhaustion), so please enjoy your Rust.

However note that needing to pull in libraries and frameworks, make those choices, etc is explicitly more complex than Go’s approach with a very strong standard library that does most of the things you want. Besides all of the other things that’s complicated about Rust, you also need to learn the ins and outs of the ecosystem, memorize the names of a bunch of packages, remember what fits together with what from Cargo. I guess in Rust the HTTP library of choice today is “tower” and you need “tokio” so it can do IO? Can’t tell from the names, so need to memorize. The choice in Go is simple and understandable in plain English: “net/http” does HTTP things.

Re: Major standard library changes in Go 1.20

#66

Post by oefrha »

p-e-w wrote: post #53
impulser_ wrote: post #46

Earlier quoted context omitted.

The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve. Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks. Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to…

Almost nobody builds a server from scratch in either Go or Rust. People use libraries and frameworks for that, because while the basics are easy enough to understand, getting the details wrong means security vulnerabilities and subtle, hard-to-find bugs. So unless you're only interested in playing around, what the core language can do isn't important. When writing a server in Rust, probably the first thing you would…

People build servers from scratch (net/http) in Go without frameworks all the time. If you don’t know that you should probably refrain from starting vs flamewars.

Re: Major standard library changes in Go 1.20

#67

Post by klodolph »

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

Earlier quoted context omitted.

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…

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…

As far as I can tell, the consensus for generics was "it will happen, but we really want to get this right, and it's taking time."

I know some people did the knee-jerk attacks like "Go sucks, it should have had generics long ago" or "Go is fine, it doesn't need generics". I don't think we ever needed to take those attitudes seriously.

> Will error handling be overhauled or not?

Error handling is a thorny issue. It's the biggest complaint people have about Go, but I don't think that exceptions are obviously better, and the discriminated unions that power errors in Rust and some other languages are conspicuously absent from Go. So you end up with a bunch of different proposals for Go error handling that are either too radical or little more than syntactic sugar. The syntactic sugar proposals leave much to be desired. It looks like people are slowly grinding through these proposals until one is found with the right balance to it.

I honestly don't know what kind of changes to error handling would appear in Go 2 if/when it lands, and I think the only reasonable answer right now is "wait and find out". You can see a more reasonable proposal here:

https://github.com/golang/proposal/blob/master/design/go2dra...

Characterizing it as a "lack of vision" does not seem fair here--I started using Rust back in the days when boxed pointers had ~ on them, and it seemed like it took Rust a lot of iterations to get to the current design. Which is fine. I am also never quite sure what is going to get added to future versions of C#.

I am also not quite sure why Go gets so much hate on Hacker News--as far as I can tell, people have more or less given up on criticizing Java and C# (it's not like they've ossified), and C++ is enough of a dumpster fire that it seems gauche to point it out.

Re: Major standard library changes in Go 1.20

#68

Post by konart »

threeseed wrote: post #57
konart wrote: post #55

Earlier quoted context omitted.

>Go from losing more mindshare to Rust This sounds like a common mantra from people who love Rust to the point they'd use it even for basic scripting. No, Go does not losing any mindshare to Rust whatsoever. Rust is an interesing choice when you need all these memory management tricks but treality is - in most cases you don't really care because Go is just good enough. Add to this that developing in Go requires much…

> developing in Go requires much less time and effort Show me the empirical evidence otherwise it's just an opinion. I also have an opinion which is that Go and Rust are about equal in complexity.

This is a comment based on an opinion (based on experience of the author and some of this collegues), yes.

I will come to you with "the empirical evidence" as soon as I decide to write a paper on the topic.

Needless to say we both are entitled to our respective opinions and will have to live with that.

Re: Major standard library changes in Go 1.20

#69

Post by klodolph »

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)

I think it does depend on the kind of code you are writing. I also think it is a bit of a cop-out to say that "once satisfying the borrow checker becomes second nature"... maybe I just write different code from you, but I periodically run into really thorny situations in Rust where figuring out how to satisfy the borrow checker is difficult. This happens most often in application programming, it's not something that I really run into when I'm writing libraries.

Really core stuff is nice to write in Rust. Parsers, core algorithms, that kind of thing.

However, I write a lot of code in Go that does stuff like glue together libraries, call APIs, etc. That stuff is really nice to use in Go.

I'd also say that when I need to use a library in Rust, it's a coin-flip whether the library has a straightforward interface, or whether it is some monster with tons of template parameters, or maybe even a bunch of macro rules that you are supposed to use. Go libraries tend to be much simpler to use than Rust libraries.

Re: Major standard library changes in Go 1.20

#70

Post by konart »

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)

> most of my scratchpad code

How about the code written for commercial purposes? As in "you have to write a service that satisfies business requirements and you have to finish by time T"

Post reply on HN