[HN Gopher] Go 1.23 Released
___________________________________________________________________
Go 1.23 Released
Author : ankraft
Score : 141 points
Date : 2024-08-13 17:37 UTC (5 hours ago)
(HTM) web link (go.dev)
(TXT) w3m dump (go.dev)
| scotthew1 wrote:
| direct link to the release notes: https://go.dev/doc/go1.23
| ptman wrote:
| And a different take on the changes:
| https://antonz.org/go-1-23/
| hu3 wrote:
| Opt-in telemetry. A very rare sight these days. Glad to see.
|
| Not even Mozilla does that with Firefox [1].
|
| > Starting in Go 1.23, the Go toolchain can collect usage and
| breakage statistics that help the Go team understand how the Go
| toolchain is used and how well it is working. We refer to these
| statistics as Go telemetry.
|
| > Go telemetry is an opt-in system, controlled by the go
| telemetry command. By default, the toolchain programs collect
| statistics in counter files that can be inspected locally but are
| otherwise unused (go telemetry local).
|
| > To help us keep Go working well and understand Go usage, please
| consider opting in to Go telemetry by running go telemetry on. In
| that mode, anonymous counter reports are uploaded to
| telemetry.go.dev weekly, where they are aggregated into graphs
| and also made available for download by any Go contributors or
| users wanting to analyze the data. See "Go Telemetry" for more
| details about the Go Telemetry system.
|
| [1] "Firefox collects telemetry data by default. We collect this
| data to help improve the performance and stability of Firefox.
| Telemetry data is made up of two data sets: interaction data and
| technical data." - https://support.mozilla.org/en-
| US/kb/telemetry-clientid
| delduca wrote:
| Until they decide it to be enabled by default.
| eps wrote:
| Exactly. Give it a couple of releases and the default "for
| new installations" will be On. Two more releases and all
| other installs will be opted in. Classic pattern for
| shoveling stuff down the throat of resisting gray masses.
| Foxboron wrote:
| At which point us, the Linux packagers and other package
| maintainers, is just going to patch it out. I wouldn't be
| very worried.
| cma wrote:
| And Google makes you call it something other than Go,
| like Firefox did to linux packagers:
|
| > The Go trademark and the Go Logo ( ) - collectively,
| the "Go Trademarks" - are trademarks of Google and are
| treated separately from the copyright license grants
| contained in the BSD-licensed Go repositories, as
| described below.
|
| > Substantially unmodified distributionsP
|
| > Substantially unmodified distributions may use the Go
| Trademarks if the derivative work complies with the terms
| of the Go programming language's open source license and
| is made in a good faith attempt to replicate the quality
| and substance of the original project.
|
| > Examples of modifications that would be considered
| substantially unmodified include language translation and
| localization, bug and security patches, and necessary
| interoperability/compatibility modifications.
|
| > The Go Trademarks may be used in connection with such
| substantially unmodified distributions following the
| "Naming Conventions for Authorized Uses".
|
| > Substantially modified distributions may include
| explicit changes to functionality, interfaces, or
| features.
|
| They can modify these trademark terms later too with a
| "backwards incompatible" change:
|
| > Guideline VersionP
|
| > These Trademark Guidelines are version 1.0 and may be
| followed by subsequent versions. These Guidelines may be
| edited for clarity; the major version will be increased
| when changes introduce new requirements, define new
| criteria, or otherwise present a backwards incompatible
| change.
| Foxboron wrote:
| It's not 2006 anymore.
| fngjdflmdflg wrote:
| I don't understand what you mean by this. Are you saying
| you can patch out telemetry in Linux package managers are
| Firefox doesn't care? What does that have to do with
| 2006? I think GP has a valid point otherwise as people
| will just install the thing named Firefox and not check
| to see if there is a telemetry free version going by a
| different name.
| Foxboron wrote:
| https://en.wikipedia.org/wiki/Debian%E2%80%93Mozilla_trad
| ema...
| icholy wrote:
| Sir, you seem to have dropped your tinfoil hat.
| candiddevmike wrote:
| There was a lengthy discussion to persuade them to not have it
| on by default: https://github.com/golang/go/discussions/58409
| mholt wrote:
| > Opt-in telemetry. A very rare sight these days.
|
| Because it doesn't work. o:-)
|
| (Introduces a slant/bias to the data.)
|
| https://twi.github.io/blog/making-go-telemetry-opt-in-is-a-m...
| tjoff wrote:
| Same with opt out.
|
| Just have to accept that you are not going to get perfect
| data. And it doesn't excuse one to behave like an asshole.
| LtWorf wrote:
| You forget that most people here work at startups that have
| compulsory telemetry.
| wsve wrote:
| I'm open to being convinced otherwise, but I feel like I'm the
| only one who doesn't get why opt-out telemetry is such a big
| deal.
|
| Sure, if it's a software library, I don't want it doing random
| network calls during my runtime. That's just rude.
|
| But if it's a user application (including a compiler), I don't
| see what the fuss is about. Of all the myriad of ways our data
| is harvested every single day, telemetry seems very unhelpful
| to advertisers and hackers, but very helpful to the people
| whose job it is to make the software you use better. I'd love
| to help them make the software I use better
| kingsleyopara wrote:
| Privacy concerns aside, I personally don't appreciate
| binaries making network requests unless it's strictly
| required for them to function.
| 0cf8612b2e1e wrote:
| You don't know what they are sending. Maybe today it is
| innocuous data. Tomorrow, they ship off your ssh keys.
|
| Better to default deny all.
| rkharsan64 wrote:
| It seems like the right way to respect a user's privacy, but
| opt-in telemetry just doesn't work.
|
| I see the concerns as a user (and disable telemetry wherever I
| can), but at the same time if I were to add telemetry to my OSS
| project, I would either make it opt out, or just not add it at
| all.
|
| The people who actually enable telemetry are a huge minority,
| and the data collected would be completely useless due to bias.
|
| The best way, in my opinion, is to have completely
| unidentifiable telemetry (not sure if something like this even
| exists), or nothing at all.
| slowmovintarget wrote:
| > The best way...
|
| The best way is not to have telemetry at all. But then that's
| a user-centric take.
| traceroute66 wrote:
| > Opt-in telemetry. A very rare sight these days. Glad to see.
|
| Ahem. Cough.
|
| Given Google's ties to Go, of course it was NOT opt-in when
| originally announced.
|
| After, shall we say, a "lively" discussion on the relevant
| Github topic[1], it was changed to opt-in. :D
|
| Opt-in is the correct stance.
|
| [1]https://github.com/golang/go/discussions/58409
| bananapub wrote:
| there's infinity things to criticise google for, but "the go
| team want useful metrics" isn't one of them.
| rollcat wrote:
| Google can already see every installation of every Go
| program/package in existence, unless you set GOPROXY=direct (or
| a custom proxy). The default is to use
| https://proxy.golang.org, which is operated by Google.
| ianlancetaylor wrote:
| The default proxy has a privacy policy:
| https://sum.golang.org/privacy.
| divan wrote:
| boring <3
| tmountain wrote:
| The way it should be.
| ronsor wrote:
| Adding support for encrypted client hello to the TLS library is
| pretty exciting. I've been waiting a while for that.
| fourseventy wrote:
| I don't like the "range-over-func" addition. I feel like it is
| adding complexity and syntactic sugar to the language that has
| thus far been mostly avoided.
| glzone1 wrote:
| Are you talking about
|
| for key, val := range m.Range
|
| I like that a fair bit more than
|
| m.Range(func(key, val any) bool {
| candiddevmike wrote:
| But now I have to understand what m.Range does, and I can't
| assume it's a slice or a map etc. Prior to this change, you
| could almost always correctly assume what a for loop is doing
| as it was very primitive.
|
| It's changes like this that will make Go less productive for
| users over time, IMO. Java-fication.
| jerf wrote:
| You put your cursor on the "Range" portion of m.Range, and
| hit "Jump to Definition".
|
| You can also just not import things that do crazy things
| with iterators. Based on the history of the community, that
| will actually be fairly easy. I'm yet to see anything crazy
| with generics get into a library that I use. I'm abundantly
| positive there's going to be a dozen "hey let's go do crazy
| things with rangefunc" libraries in the next couple of
| weeks, probably some will even make it to HN (with
| predictable comments bemoaning how complicated Go is
| getting even though these libraries have an expected use
| rate in the low dozens of people in the next few years),
| but the odds of them penetrating into common practice
| remain low. (Higher than previous attempts at such
| libraries, because rangefunc fixes some basic issues with
| them. But still low overall, I think.)
|
| I think you could go many, many years programming Go in the
| next few years and not encounter any funny iterators in
| real code. If you just assume the iterator is doing what it
| looks like it should be doing and isn't doing anything
| funny, you're going to be 99%+ correct in the Go
| programming world.
| mariusor wrote:
| > You put your cursor on the "Range" portion of m.Range,
| and hit "Jump to Definition".
|
| Well, that's one reason why people usually run away from
| languages high in magic like Java/JS to something like
| Go: not needing a fancy IDE to make sense of what's
| happening with a single line of code.
| bartonfink wrote:
| Are you thick or just a jerk? Range is now precisely the
| same as any other function call as far as comprehension
| goes. If you claim you can't make sense of any code using
| the new Range then I question how much code you have ever
| made sense of.
| icholy wrote:
| The change adds no syntax.
| fourseventy wrote:
| "for key, val := range m.Range" is syntactic sugar for using
| the m.Range iterator directly "m.Range(func(key, val any)
| bool".
|
| In a vacuum I think it's fine, but I don't want to see stuff
| like this getting added to the language routinely. I prefer a
| small language.
| pptr wrote:
| I think the key difference is that in a loop body you can
| return from the outer function. In a function passed to
| m.Range you can't.
| tedunangst wrote:
| Go 1.22 is still right there.
| TwentyPosts wrote:
| The first time I looked at the syntax, it honestly looked like
| gibberish to me.
|
| It's probably simple, but the control flow just felt
| convoluted.
| silisili wrote:
| Same. This is one of the first times I'd checked release notes
| and not really understood most of it at first glance.
| thiht wrote:
| Hard disagree. A standard way to define iterators was long
| overdue, and using the existing `range` construct was the right
| solution.
|
| This change will end up removing some mental load, at an
| extremely low complexity cost. Basically you define an iterator
| just by defining a function. No additional keyword, no state to
| manage, just a function.
| epage wrote:
| As someone who was advocating for a similar warning in Rust
| (finally added to clippy in 1.78), I'm glad to see this
| improvement in `go vet`
|
| > The go vet subcommand now includes the stdversion analyzer,
| which flags references to symbols that are too new for the
| version of Go in effect in the referring file. (The effective
| version is determined by the go directive in the file's enclosing
| go.mod file, and by any //go:build constraints in the file.) > >
| For example, it will report a diagnostic for a reference to the
| reflect.TypeFor function (introduced in go1.22) from a file in a
| module whose go.mod file specifies go 1.21.
| progbits wrote:
| Don't most Rust crates solve this by running MSRV builds/tests?
|
| Or is the goal to catch it eg. in precommit hook?
| minkles wrote:
| > Go telemetry is an opt-in system
|
| Great job Go. Hat tip and respect for this. Unlike .Net. I will
| enable this where it is appropriate.
| efilife wrote:
| Where is it? I honestly want to know
| maccard wrote:
| This is a great example of why it's utterly useless. In the
| link we're discussing, the release notes say:
|
| > To help us keep Go working well and understand Go usage,
| please consider opting in to Go telemetry by running go
| telemetry on. In that mode, anonymous counter reports are
| uploaded to telemetry.go.dev weekly, where they are
| aggregated into graphs and also made available for download
| by any Go contributors or users wanting to analyze the data.
| See "Go Telemetry" for more details about the Go Telemetry
| system.
|
| If someone who is genuinely interested in knowing where it is
| can't click one link for information, what chance do the go
| team have of people turning it on?>
| neonsunset wrote:
| FWIW .NET tooling telemetry can be easily opted-out, which the
| SDK explicitly tells you about, and there is a page that has
| full list of the kind of data that is collected (CLI usage
| metrics and tooling crash stack traces). You can also review
| the metrics yourself.
|
| About: https://learn.microsoft.com/en-
| us/dotnet/core/tools/telemetr...
|
| Collected metrics: https://dotnet.microsoft.com/en-
| us/platform/telemetry
|
| Source code:
| https://github.com/dotnet/sdk/tree/main/src/Cli/dotnet/Telem...
|
| In either case, many teams have CIs with
| 'DOTNET_CLI_TELEMETRY_OPTOUT=1' and call it a day even if it
| makes no difference to them.
| traceroute66 wrote:
| > Great job Go. Hat tip and respect for this
|
| Whoah. Easy there cowboy.
|
| It was not opt-in when originally announced.
|
| After an extended, shall we say, "lively" discussion on
| Github[1], they did the right thing and made it opt-in.
|
| (N.B. The discussion was heavily moderated and redacted, it was
| even more "lively" at the time.)
|
| [1]https://github.com/golang/go/discussions/58409
| ffpip wrote:
| Any good resources on learning go?
|
| Has anyone had any luck with the YT videos or courses way?
| candiddevmike wrote:
| If you are familiar with programming, Tour of Go is a good
| overview of the language: https://go.dev/tour/
| DoctorOW wrote:
| I hope I don't sounds rude saying this but Go code is generally
| self evident. I personally got my Go knowledge from reading Go
| code on GitHub or the like. There's a certain beauty to Go code
| in that you can grasp what code does pretty easily, which
| definitely helps with learning.
| sapiogram wrote:
| You've clearly never opened Kubernetes' source code.
| wrs wrote:
| Go is superficially readable, but be careful. It has some (in
| my experience) quite non-evident semantic aspects, such as
| interface nils and channel "edge cases" (which aren't "edge"
| at all, you do have to handle them). The Timer thing they
| just fixed is an example of how the Go core team really
| expects you to read the manual.
|
| The good news is that the language and stdlib docs are
| concise and extremely clear. One of the really impressive
| things about Go.
| trevor-e wrote:
| I wouldn't say that's true, I personally find Go code more
| confusing to read than the average language. For example:
|
| ``` func (r _rect) area() int { return r.width_ r.height }
| ```
|
| This syntax is strange to me despite being a simple example.
| I can tell that it's a function that takes in a rect pointer,
| is maybe named area() (but I'm now confused why this
| definition doesn't have an argument?), and returns an integer
| value. I've tried reading larger Go files and constantly run
| into syntax confusion like this and get exhausted.
|
| So sure, I understand the gist of this code, but this is more
| difficult to understand IMO than any Python, Ruby, Java,
| Swift, Rust, Gleam code I've read.
| aadhavans wrote:
| 'Learning Go' by Jon Bodner [0] was the book I chose. A front-
| to-back reading got me up to speed with the language.
|
| [0]: https://www.oreilly.com/library/view/learning-
| go-2nd/9781098...
| nalgeon wrote:
| If you find the official release notes a bit dry (they really
| are), I've prepared an interactive version with lots of examples:
|
| - Iterators (range / types / pull / slices / maps).
|
| - Timer changes (garbage collection and reset/stop behavior).
|
| - Canonical values with the `unique` package.
|
| - HTTP cookie handling.
|
| - Copying directories.
|
| - Slices and atomics changes.
|
| https://antonz.org/go-1-23
| danielvaughn wrote:
| Thank you for your service, this is awesome! I'd love to see
| language maintainers post interactive release notes like this.
| felixge wrote:
| This is great, thank you.
| metadat wrote:
| I want to understand the purpose of maps.All().
|
| In the example: m := map[string]int{"a": 1,
| "b": 2, "c": 3} for k, v := range maps.All(m) {
| fmt.Printf("%v:%v ", k, v) } fmt.Println("")
| for k, v := range m { fmt.Printf("%v:%v ", k, v) }
|
| These both output the same thing. What's the point of the
| addition?
|
| Slices.All() seems similarly redundant and pointless.
|
| Surely I must be misunderstanding something, I hope.
| sakjur wrote:
| They're useful because they let you pass a slice or map to
| something built to handle the new func(func (...) bool) style
| iterators.
|
| If I create a IterateOver(fn func(func (K, V any) bool))
| function, you cannot pass a slice since that doesn't match
| fn's type, but if you wrap it with slices.All it'll work.
| ianlancetaylor wrote:
| You can use it with other functions that use iterators. For
| example, here is code that makes a copy of a map keeping only
| the even keys.
| maps.Collect(xiter.Filter2(func(k, v int) bool { return k%2
| == 0 }, maps.All(m)))
| rkharsan64 wrote:
| From the release notes [1], which I think this post should
| actually point to:
|
| > For backward compatibility, existing usages of //go:linkname
| found in a large open-source code corpus remain supported. Any
| new references to standard library internal symbols will be
| disallowed.
|
| How does this work? Does the compiler have a whitelist of allowed
| uses?
|
| [1]: https://go.dev/doc/go1.23
| tedunangst wrote:
| The source has to be annotated to export the function.
| rkharsan64 wrote:
| Just confirming if I understand this correctly: they went
| through a big chunk of existing code, and then made any
| internal symbols used in that corpus accessible via
| //go:linkname?
|
| I don't know why, but I (stupidly) assumed that they wouldn't
| allow new code to be written that uses those symbols, while
| allowing old code to work. :)
|
| This explanation makes a lot more sense. So, you can keep
| using the symbols exposed with this change (until a future
| release hides/changes them), but cannot use any other
| internal symbol(s) anymore.
| ianlancetaylor wrote:
| Yes.
| 38 wrote:
| Why is it not dated?
___________________________________________________________________
(page generated 2024-08-13 23:01 UTC)