Go 1.19 Released(go.dev)
go.dev
Go 1.19 Released
https://go.dev/doc/go1.19
155 comments
I was told that garbage collection knobs were an antifeature.
Well, you are in luck. Java provides more than five hundred flags to configure runtime behavior. So there is no limit on things you can achieve with that.
Great. I love it when my test matrix size exceeds the number of quarks in the known universe.
It hasn’t been true at all for modern GCs. G1GC basically has only one knob that you may change: the target pause time. This changes between better throughput vs lower latency (which two problems are mostly opposite ends of the same axis).
And your sarcasm aside, Java has the state-of-the-art GCs by a long shot.
And your sarcasm aside, Java has the state-of-the-art GCs by a long shot.
[deleted]
[deleted]
Obviously the fewer you need the better. Zero-knob GC not yet discovered.
Every missing knob is another reason for a risky rewrite hoping perf might improve.
Isn't that what Java's ZGC stands for ;-)?
Generics were an antifeature too.
No.
“Generics are great. we haven’t gotten around to doing it the right way”
vs
“if we start introducing knobs, soon enough, knob turning is going to be a full time role “
“Generics are great. we haven’t gotten around to doing it the right way”
vs
“if we start introducing knobs, soon enough, knob turning is going to be a full time role “
Ah you're right. I was remembering some opinions from Go folks on HN, but I should avoid conflating that with the actual Go team.
Is allocating a large array on startup to avoid gc cycles better?
Just trying to understand if this is what simple looks like.
2 knobs after a decade vs how many in Java? Yes, that is exactly what simple looks like.
After years of real world experience, I can say that the Go garbage collector worked fantastically across a range of applications that I've been involved in. No tool is perfect for every job, of course, and having hundreds of knobs does not make Java perfect for every job either.
After years of real world experience, I can say that the Go garbage collector worked fantastically across a range of applications that I've been involved in. No tool is perfect for every job, of course, and having hundreds of knobs does not make Java perfect for every job either.
I'd say it makes Java's GC worse at nearly every job as that means the defaults probably aren't what you want but are probably what you are going to use.
The Java problem is that you wind up in a blame game where one team blames the code and the other blames the GC settings and you wind up doing a lot of fruitless flailing. No knobs really cuts down on that nonsense.
In situations where you actually are allocating on the heap, Java’s default GC significantly out performs Go’s. Just look at the binary tree bench marks.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Even that simplification is too much. Java uses a generational GC, so the fewer objects that survive the nursery, the less work it has to do.
That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap". It means Java's GC is faster when you're spewing garbage onto the heap as fast as possible.
Since Go makes heavy use of stack allocation where possible, short-lived garbage usually doesn't end up on the heap, but this benchmark is designed to force that outcome. Go's garbage collector is optimized to minimize latency and STW, but this does come at the cost of decreased throughput. The opposite can be said of the majority of Java GC implementations, which trade latency and STW time for increased throughput.
That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap". It means Java's GC is faster when you're spewing garbage onto the heap as fast as possible.
Since Go makes heavy use of stack allocation where possible, short-lived garbage usually doesn't end up on the heap, but this benchmark is designed to force that outcome. Go's garbage collector is optimized to minimize latency and STW, but this does come at the cost of decreased throughput. The opposite can be said of the majority of Java GC implementations, which trade latency and STW time for increased throughput.
> Java uses a generational GC.
This depends on implementation. ZGC is not generational yet, but I don’t see how generational or not would invalidate a GC benchmark for the default implementation.
> That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap".
It actually does at least in the discussion of _default gc implementations_. Just because the default (and only) implementation for Go sacrifices throughput (and relies on the compiler to stack allocate) doesn’t invalidate the benchmark.
And honestly if I was in Vegas I’d still bet that ZGC (Java’s non-generational, latency sensitive GC) would beat Go’s implementation here.
This depends on implementation. ZGC is not generational yet, but I don’t see how generational or not would invalidate a GC benchmark for the default implementation.
> That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap".
It actually does at least in the discussion of _default gc implementations_. Just because the default (and only) implementation for Go sacrifices throughput (and relies on the compiler to stack allocate) doesn’t invalidate the benchmark.
And honestly if I was in Vegas I’d still bet that ZGC (Java’s non-generational, latency sensitive GC) would beat Go’s implementation here.
> This depends on implementation. ZGC is not generational yet, but I don’t see how generational or not would invalidate a GC benchmark for the default implementation.
I never said the benchmark was invalidated, I said that you interpreted the meaning of the benchmark wrong. I like how your reply completely ignored what I said the benchmark meant. That benchmark has a very narrow focus, and generational makes a huge difference for that one benchmark.
> And honestly if I was in Vegas I’d still bet that ZGC (Java’s non-generational, latency sensitive GC) would beat Go’s implementation here.
I would love to see a holistic set of benchmarks comparing them. Even just that one very narrow benchmark you linked would be fun to see — if ZGC is so good, surely one of the implementations of the benchmark on the website is using ZGC? But I haven’t had time to dig through them.
But, part of Go’s charm is that idiomatic code rarely puts tons of pressure on the GC anyways, and a GC can never be faster than stack allocation for a multitude of reasons… which is also why C# has value types.
I never said the benchmark was invalidated, I said that you interpreted the meaning of the benchmark wrong. I like how your reply completely ignored what I said the benchmark meant. That benchmark has a very narrow focus, and generational makes a huge difference for that one benchmark.
> And honestly if I was in Vegas I’d still bet that ZGC (Java’s non-generational, latency sensitive GC) would beat Go’s implementation here.
I would love to see a holistic set of benchmarks comparing them. Even just that one very narrow benchmark you linked would be fun to see — if ZGC is so good, surely one of the implementations of the benchmark on the website is using ZGC? But I haven’t had time to dig through them.
But, part of Go’s charm is that idiomatic code rarely puts tons of pressure on the GC anyways, and a GC can never be faster than stack allocation for a multitude of reasons… which is also why C# has value types.
Java's value types will be ready soon enough: https://openjdk.org/projects/valhalla
I hope it happens soon!
But, if I understood correctly, that design both requires you to explicitly mark a type as a value type when you define it and it doesn’t support inheritance, so I’m skeptical that it will see any real adoption for a long time.
Java hasn’t had decades to develop a culture around this feature the way that C# has, and neither are like Go where everything is value typed unless it is one of the built in pointer types, or you explicitly put the value behind a pointer. (The pointers themselves are values, of course, but I think few people are interested in that distinction here.)
Go isn’t perfect by a long shot, I just don’t think adding the millionth keyword is going to be a silver bullet for Java’s predisposition towards GC pressure.
But, if I understood correctly, that design both requires you to explicitly mark a type as a value type when you define it and it doesn’t support inheritance, so I’m skeptical that it will see any real adoption for a long time.
Java hasn’t had decades to develop a culture around this feature the way that C# has, and neither are like Go where everything is value typed unless it is one of the built in pointer types, or you explicitly put the value behind a pointer. (The pointers themselves are values, of course, but I think few people are interested in that distinction here.)
Go isn’t perfect by a long shot, I just don’t think adding the millionth keyword is going to be a silver bullet for Java’s predisposition towards GC pressure.
They'll be ready soon I guess, but "soon enough" would have had to be 5-6 years ago when we started shipping.
> That benchmark does not mean Java's GC is faster when you're "actually allocating on the heap"
The benchmark doesn’t show it, but it is nonetheless true. Java uses thread local allocation buffers, which is possible due to moving GC, and it is literally as fast as it gets (a single, non-atomic pointer bump)
The benchmark doesn’t show it, but it is nonetheless true. Java uses thread local allocation buffers, which is possible due to moving GC, and it is literally as fast as it gets (a single, non-atomic pointer bump)
Again, GCs just aren’t that simple. You seem to be taking a very literal interpretation of what was said, but that person was implying that Go is only fast when you’re avoiding the heap. They weren’t talking about the actual, literal speed of allocation. My interpretation of their comment is confirmed in their later reply to me, as far as I can tell.
Java’s GC design requires more barriers which hinder performance throughout the lifetime of a heap allocation, not just at the time the value was allocated.
Either way, Go also uses per-thread caches in its allocator to avoid contention between threads. I don’t believe it is a bump allocator, but this goes back to other tradeoffs being discussed. The number of barriers, the duration of STW, etc.
I don’t understand why so many people in here feel the need to declare the superiority of Java GC. Java’s garbage collectors are better for Java, due to the way that Java allocates practically everything on the heap. That doesn’t mean they have zero performance tradeoffs and that they’re perfect. They do have tradeoffs, and not just in complexity of tuning.
Java’s GC design requires more barriers which hinder performance throughout the lifetime of a heap allocation, not just at the time the value was allocated.
Either way, Go also uses per-thread caches in its allocator to avoid contention between threads. I don’t believe it is a bump allocator, but this goes back to other tradeoffs being discussed. The number of barriers, the duration of STW, etc.
I don’t understand why so many people in here feel the need to declare the superiority of Java GC. Java’s garbage collectors are better for Java, due to the way that Java allocates practically everything on the heap. That doesn’t mean they have zero performance tradeoffs and that they’re perfect. They do have tradeoffs, and not just in complexity of tuning.
As I mentioned in another comment, Java’s modern GCs don’t have many knobs at all - they are apt for most tasks by default.
I had a look through some of your comments here and elsewhere and just wanted to give you some friendly feedback: This style of commenting is quite toxic. I think you'll feel happier if you let go of the tribalism and engage with others in good faith.
I engage in good faith conversations all the time.
why is asking questions regarded as toxic? I genuinely want to know
It is not about asking questions in general, it is about asking questions in a suggestive way, if it suggests something toxic.
Go look in a mirror for an example of simple
> The compiler now uses a jump table to implement large integer and string switch statements. Performance improvements for the switch statement vary but can be on the order of 20% faster. (GOARCH=amd64 and GOARCH=arm64 only)
Nice improvement to switch statements!
Nice improvement to switch statements!
Ken Thompson (2012) description of switch statements in Go: https://groups.google.com/g/golang-nuts/c/IURR4Z2SY7M/m/R7OR...
> optimization of switches would be different for different architectures. every x86, amd, intel, and then all the non x86s. they all have very different execution times and cache times and pipeline times. there is no single answer. there is usually a huge pipeline cost for a computed jump.
> when you are considering native-client restrictions, jump tables become impossible.
> also note that go switches are different than c switches. non-constant cases have to be tested individually no matter what.
> having said that, a large (where large depends on architecture) dense switch would be faster than what is implemented now. BUT there are two parameters needed to implement it. how large and how dense. no matter what is used for large and dense, there will be a micro-benchmark on some machine, under some alignment, with some branch cache that will look wrong.
> what is implemented is as follows.
> 1. in order, all non-constant cases are compiled and tested as if-elses.
> 2. groups of larger than 3 constant cases are binary divided and conquered.
> 3. 3 or fewer cases are compared linearly.
> i honestly dont think there is a much better algorithm across all machines.
> optimization of switches would be different for different architectures. every x86, amd, intel, and then all the non x86s. they all have very different execution times and cache times and pipeline times. there is no single answer. there is usually a huge pipeline cost for a computed jump.
> when you are considering native-client restrictions, jump tables become impossible.
> also note that go switches are different than c switches. non-constant cases have to be tested individually no matter what.
> having said that, a large (where large depends on architecture) dense switch would be faster than what is implemented now. BUT there are two parameters needed to implement it. how large and how dense. no matter what is used for large and dense, there will be a micro-benchmark on some machine, under some alignment, with some branch cache that will look wrong.
> what is implemented is as follows.
> 1. in order, all non-constant cases are compiled and tested as if-elses.
> 2. groups of larger than 3 constant cases are binary divided and conquered.
> 3. 3 or fewer cases are compared linearly.
> i honestly dont think there is a much better algorithm across all machines.
The blog post is out: https://go.dev/blog/go1.19
I suspect the PATH handling change in go/exec is going to bite many people. You can't just keep
exec.LookPath("prog")
exec.LookPath("./prog")
Conversely, as someone who has written a lot of code using LookPath I was shocked (like, actually gasped) to learn in these release notes that it ever did the old behavior, and now need to go check several projects for security issues.
Edit: checking the actual os/exec docs instead of the release notes, it’s actually not as bad as it sounds. What the change actually seems to be is that relative paths are now ignored even if they are in $PATH.
Edit: checking the actual os/exec docs instead of the release notes, it’s actually not as bad as it sounds. What the change actually seems to be is that relative paths are now ignored even if they are in $PATH.
On Unix, it only did the old behavior if you explicitly had "." in your PATH (same as all other programs doing path lookup). The original (1979) default PATH included ".", but it's been considered a bad practice since the mid 1980s, and no modern Unixes include it in the default PATH. So for most Unix users, this is a no-op change.
But this is a change on Windows, where bad practices stick around because backward compatibility. (Lots of things would break if cmd.exe changed; but fortunately they fixed this in PowerShell.)
But this is a change on Windows, where bad practices stick around because backward compatibility. (Lots of things would break if cmd.exe changed; but fortunately they fixed this in PowerShell.)
I am quite sure that until the early 2000's it was configured by default in many UNIX deployments, and I did use many flavours of it, starting with Xenix in 1992.
For sure; by the late 2000s I was still seeing it, but it was fairly uncommon by then. When I said "considered a bad practice since the mid 1980s" I was specifically meaning since Grampp & Morris 1984[1]. It definitely continued to be common for decades after that. I remember lots docs that told you to run "configure" where now they'd tell you to run "./configure", but the docs tended to lag behind the actual change to the default PATH.
[1]: https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Se...
[1]: https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Se...
We're especially excited for this release because we discovered a decade old inconsistency with Go's notation of ASCII/UTF-8 that's now fixed in Go 1.19.
A demonstration of the issue: https://go.dev/play/p/R9dm6uYZSas?v=goprev which fails in 1.18 but passes in 1.19.
A little background of the issue:
1. Go uses UTF-8 encoding. UTF-8 is a superset 7 bit, 128 code point ASCII. (Two UTF-8 creators, Rob Pike and Ken Thompson, are also two of Go's creators.) 2. All UTF-8 points over byte 128 must be encoded as two bytes. All code points 128 and below are encoded as a single byte. 3. Single byte code points between 129 and 256 are valid in Go, but not as UTF-8. 4. Go uses different notations to make the distinction between 129+ code points that are two bytes and 1-256 code points that are a single byte, notably the code points in the 129-256 range. Go represents single byte code points with the \x notation, "\xXX", and multi-byte code points with the \u notation, \uXXXX. All ASCII and single byte 129-256 codes should always be represented with "\x" notation.
The core of the issue is that Go was printing code point 128, \x7F, as \u007f. As previously said, the "\u" notation is reserved for valid UTF-8 points past the ASCII range, which are always encoded as a minimum of two bytes. \x7F is a valid single byte code point in the ASCII range and should not be printed in the "\u" notation.
We discussed this issue on an old thread, and Rob filed a Github issue https://github.com/golang/go/issues/52062, and it was fixed within hours.
So the following line in the release note is us!
>Quote and related functions now quote the rune U+007F as \x7f, not \u007f, for consistency with other ASCII values.
How did we find this? We're fans of arbitrary base conversion (https://convert.zamicol.com) and we discovered this issue while checking our work in our Go libraries. If encoded as two bytes, base conversion would be less useful.
Thanks Go team!
A demonstration of the issue: https://go.dev/play/p/R9dm6uYZSas?v=goprev which fails in 1.18 but passes in 1.19.
A little background of the issue:
1. Go uses UTF-8 encoding. UTF-8 is a superset 7 bit, 128 code point ASCII. (Two UTF-8 creators, Rob Pike and Ken Thompson, are also two of Go's creators.) 2. All UTF-8 points over byte 128 must be encoded as two bytes. All code points 128 and below are encoded as a single byte. 3. Single byte code points between 129 and 256 are valid in Go, but not as UTF-8. 4. Go uses different notations to make the distinction between 129+ code points that are two bytes and 1-256 code points that are a single byte, notably the code points in the 129-256 range. Go represents single byte code points with the \x notation, "\xXX", and multi-byte code points with the \u notation, \uXXXX. All ASCII and single byte 129-256 codes should always be represented with "\x" notation.
The core of the issue is that Go was printing code point 128, \x7F, as \u007f. As previously said, the "\u" notation is reserved for valid UTF-8 points past the ASCII range, which are always encoded as a minimum of two bytes. \x7F is a valid single byte code point in the ASCII range and should not be printed in the "\u" notation.
We discussed this issue on an old thread, and Rob filed a Github issue https://github.com/golang/go/issues/52062, and it was fixed within hours.
So the following line in the release note is us!
>Quote and related functions now quote the rune U+007F as \x7f, not \u007f, for consistency with other ASCII values.
How did we find this? We're fans of arbitrary base conversion (https://convert.zamicol.com) and we discovered this issue while checking our work in our Go libraries. If encoded as two bytes, base conversion would be less useful.
Thanks Go team!
> Go was printing code point 128, \x7F
That's code point 127, which has always been quite a special case as the only non-printable ASCII codepoint larger than the smallest printable codepoint.
> All ASCII and single byte [128]-256 codes should always be represented with "\x" notation... the "\u" notation is reserved for valid UTF-8 points past the ASCII range... all valid UTF-8 "\u" notation characters must be a minimum of two bytes.
Says who?
I mean I guess some consistency (though, with what?) is nice, but you should be plenty prepared for the other format too. `strconv.Quote` is only meant to be equivalent to Go's source string literal representation and that allows both, and JSON only allows \u, and Python's source literals also allow both, and and and....
> UTF-8 points... single byte code points... multi-byte code points
This is... at best, unnecessarily and fundamentally confusing language.
That's code point 127, which has always been quite a special case as the only non-printable ASCII codepoint larger than the smallest printable codepoint.
> All ASCII and single byte [128]-256 codes should always be represented with "\x" notation... the "\u" notation is reserved for valid UTF-8 points past the ASCII range... all valid UTF-8 "\u" notation characters must be a minimum of two bytes.
Says who?
I mean I guess some consistency (though, with what?) is nice, but you should be plenty prepared for the other format too. `strconv.Quote` is only meant to be equivalent to Go's source string literal representation and that allows both, and JSON only allows \u, and Python's source literals also allow both, and and and....
> UTF-8 points... single byte code points... multi-byte code points
This is... at best, unnecessarily and fundamentally confusing language.
>Says who?
The playground example (https://go.dev/play/p/R9dm6uYZSas?v=goprev) is a great example. All single bytes, 0-255, print as the printable character or if non-printable as \x except 127. There's nothing special about 127 to deserve this.
Inversely, \u denotes multibyte for all code points except 127. Once again, why is 127 special?
There's two possible fixes: note that 127 is special (even without a reason, but at least document it), or change the behavior to align with everything else. UTF-8 itself was a response in part to perceived arbitrary decisions made in other encodings; I'm not surprised that the second fix was preferred.
Our chief concern was how many bytes were used in encoding, and that's when we ran into this issue. If not fixed, our tests in our library had to notate why 127 is special (because Go says so), or hope for a change. Now that it's fixed, there's no need for downstream documentation.
It's a minor change, but now no one else ever has to spend the time we took to look into this issue because now there are no surprises. That makes it worth it.
>That's code point 127
How does that joke go? There's only two hard things in computer science...
The playground example (https://go.dev/play/p/R9dm6uYZSas?v=goprev) is a great example. All single bytes, 0-255, print as the printable character or if non-printable as \x except 127. There's nothing special about 127 to deserve this.
Inversely, \u denotes multibyte for all code points except 127. Once again, why is 127 special?
There's two possible fixes: note that 127 is special (even without a reason, but at least document it), or change the behavior to align with everything else. UTF-8 itself was a response in part to perceived arbitrary decisions made in other encodings; I'm not surprised that the second fix was preferred.
Our chief concern was how many bytes were used in encoding, and that's when we ran into this issue. If not fixed, our tests in our library had to notate why 127 is special (because Go says so), or hope for a change. Now that it's fixed, there's no need for downstream documentation.
It's a minor change, but now no one else ever has to spend the time we took to look into this issue because now there are no surprises. That makes it worth it.
>That's code point 127
How does that joke go? There's only two hard things in computer science...
So, says you, because it was aesthetically unpleasant for you. That's a far cry from "should always be... reserved for... must".
Now we need to lockstep our team's version upgrade since I just learned some tooling will otherwise bounce it back and forth. "Thanks."
> There's nothing special about 127 to deserve this.
Other than the thing I said, which means it is now literally a special-case in the fmt code where it wasn't before.
Now we need to lockstep our team's version upgrade since I just learned some tooling will otherwise bounce it back and forth. "Thanks."
> There's nothing special about 127 to deserve this.
Other than the thing I said, which means it is now literally a special-case in the fmt code where it wasn't before.
>Now we need to lockstep our team's version upgrade since I just learned some tooling will otherwise bounce it back and forth
That sounds like an interesting issue. Could you perhaps go into more detail?
>means it is now literally a special-case in the fmt code
No. There is no special case, and the logic (literally) runs in the same switch case. https://go-review.googlesource.com/c/go/+/397255/4/src/strco...
That sounds like an interesting issue. Could you perhaps go into more detail?
>means it is now literally a special-case in the fmt code
No. There is no special case, and the logic (literally) runs in the same switch case. https://go-review.googlesource.com/c/go/+/397255/4/src/strco...
Nah, if you believe
- case r < ' ':
+ case r < ' ' || r == 0x7f:
Yes this is minor semantics. Tab, carriage return, new line, etc.. are a special cases: https://go-review.googlesource.com/c/go/+/397255/4/src/strco...
Range selection is not a special case, and it's equivalent to writing it as `case r == 0x00, r == 0x01, r == 0x02 ... r ==0x7f`. The short hand, `r < 0x20`, is far more readable. I would reiterate, the lack of the need for another literal `case` shows that logically this is not a special case.
In the sense of the abstract idea of ASCII, 0x7f is unique in its position, but so are all characters. There is no meaning in its positional placement in ASCII. It's totally arbitrary and was thought to be a useful convention. If position denoted other relevant, and unique, meaning to printing, then yes it could be a special case in certain circumstances. But its position has no additional information. And that's the key, no information means no special case.
Range selection is not a special case, and it's equivalent to writing it as `case r == 0x00, r == 0x01, r == 0x02 ... r ==0x7f`. The short hand, `r < 0x20`, is far more readable. I would reiterate, the lack of the need for another literal `case` shows that logically this is not a special case.
In the sense of the abstract idea of ASCII, 0x7f is unique in its position, but so are all characters. There is no meaning in its positional placement in ASCII. It's totally arbitrary and was thought to be a useful convention. If position denoted other relevant, and unique, meaning to printing, then yes it could be a special case in certain circumstances. But its position has no additional information. And that's the key, no information means no special case.
> There is no meaning in its positional placement in ASCII. It's totally arbitrary...
This is also not true.
This is also not true.
I love Go. Just checked my Go server pushing terabytes of data per month has over 4 years of uptime now. Run and forget...
Every time new version of Go is released I am thinking about updating it, but then why if it works...
Every time new version of Go is released I am thinking about updating it, but then why if it works...
If it's being exposed, possibly because of security updates?
Fair point! The server is on a private network and it is exposed via nginx reverse proxy that is regularly updated.
Not to poop on your parade, but there's been a bunch of security updates you might want to get?
> On Windows only, the mime package now ignores a registry entry recording that the extension .js should have MIME type text/plain.
As someone whose primary dev machine runs Windows, this is a very convenient improvement to a pitfall I ran into. I probably won't stop manually adding the JS mimetype for a while though.
As someone whose primary dev machine runs Windows, this is a very convenient improvement to a pitfall I ran into. I probably won't stop manually adding the JS mimetype for a while though.
I got no dog in this hunt but I've come to really despise tools that grab random stuff from the registry or the environment. There are a myriad of ways that bites developers that just want stuff to work.
I mean mapping of file extension to filetype is fine as an OS feature. On Unix that's /etc/mime.types (or /usr/share/misc/mime.types, depending on the system), on Windows that's the registry. What I despise is are tools that vomit random stuff in to your config, whether that's the registry or ~/.config/.
Finally.
> Go’s memory model now explicitly defines the behavior of the sync/atomic package.
> Go’s memory model now explicitly defines the behavior of the sync/atomic package.
No official blog post yet, but the official Twitter account announced it: https://twitter.com/golang/status/1554515292390408192 and https://groups.google.com/g/golang-nuts/c/m3V8y4D02ao
At first glance I don't see anything done about migrating the standard library to use generics. Is there any roadmap? I remember a cascade of related improvements when Java introduced generics.
The new generic atomic.Pointer[T] has been added[1]. More general improvements for slices and maps are being prototyped in the x/exp repos[2][3] to get it right and not get stuck with a sucky implementation in the stdlib.
[1]: https://pkg.go.dev/sync/atomic@master#Pointer
[2]: https://pkg.go.dev/golang.org/x/exp/maps
[3]: https://pkg.go.dev/golang.org/x/exp/slices
[1]: https://pkg.go.dev/sync/atomic@master#Pointer
[2]: https://pkg.go.dev/golang.org/x/exp/maps
[3]: https://pkg.go.dev/golang.org/x/exp/slices
I think they've mentioned that they expect that their generics spec will evolve, plus they're waiting to see what idioms emerge before refactoring the standard library.
For now there are some experimental things in the exp module. See the maps and slices packages there. But yes, my understanding is also that they kind of waiting to see how generics work out. They've promised to make no breaking changes to Go v1, so adding any functions to the standard library is not to be taken lightly.
https://pkg.go.dev/golang.org/x/exp#section-readme
https://pkg.go.dev/golang.org/x/exp#section-readme
I think almost everyone is waiting to see those idiom too (myself included). If I'm going to rewrite stuff, I want to be able to justify it (less LOC may be be enough) and "do it right". Hopefully I get to see them in the sdlib soon!
That doesn't ever have to be done.
Generics are a language level feature, so it must be done at the language/compiler level, otherwise people are forced to implement it using "go generate" or other metaprogramming. The standard library doesn't ever have to change in that regard. If people want a generic version of some function, they can just write it themself. Its possible/likely that more generic functions will be added to standard library, but its not a foregone conclusion that it needs to happen, or even should happen.
Generics are a language level feature, so it must be done at the language/compiler level, otherwise people are forced to implement it using "go generate" or other metaprogramming. The standard library doesn't ever have to change in that regard. If people want a generic version of some function, they can just write it themself. Its possible/likely that more generic functions will be added to standard library, but its not a foregone conclusion that it needs to happen, or even should happen.
> Doc comments now support links, lists, and clearer heading syntax. This change helps users write clearer, more navigable doc comments, especially in packages with large APIs. As part of this change gofmt now reformats doc comments to apply a standard formatting to uses of these features.
A lot of exciting new features, but really happy to see this one.
A lot of exciting new features, but really happy to see this one.
[deleted]
yoidaj(1)
Nice!
Most tooling is not even working with 1.18 ahah
> The pure Go resolver will now use EDNS(0) to include a suggested maximum reply packet length, permitting reply packets to contain up to 1232 bytes
Cowards!
Cowards!
I like go and I can program it very well. But for full stack web dev Rails is still my go to choice. Less headaches. I don’t need to setup everything by myself (sql layer, middlewares, background jobs, validation patterns, i18n, authentication, authorization, security concerns, caching, mailing, migrations and a million other things).
There’s just nothing comparable from a developers productivity perspective to what Rails offers.
Would I write a command line tool in Go? For sure.
How do others think about Go for web dev?
There’s just nothing comparable from a developers productivity perspective to what Rails offers.
Would I write a command line tool in Go? For sure.
How do others think about Go for web dev?
After using Rails for 15 years, I'm looking for a future on Go. The niche where Rails is great is larger apps that don't need anything custom or deviating from the built-in Rails Way.
Simpler apps or services are simple in Go. Apps with heavy customization are also great with Go, and there's now plenty of libraries to help you outsource heavy lifting.
Simpler apps or services are simple in Go. Apps with heavy customization are also great with Go, and there's now plenty of libraries to help you outsource heavy lifting.
Not comparing a language with a framework would be a reasonable starting place.
Useless comment. What framework you use?
I feel super productive in Go. The strong typing and static compilation just make everything simple and easy
Hugo is huge.
[0]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...