Go 1.23 Released(go.dev) |
Go 1.23 Released(go.dev) |
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
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.
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
Better to default deny all.
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...
Just have to accept that you are not going to get perfect data. And it doesn't excuse one to behave like an asshole.
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.
The best way is not to have telemetry at all. But then that's a user-centric take.
- 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.
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)
}
Slices.All() seems similarly redundant and pointless.
Surely I must be misunderstanding something, I hope.
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.
maps.Collect(xiter.Filter2(func(k, v int) bool { return k%2 == 0 }, maps.All(m)))> 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.
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.
It's probably simple, but the control flow just felt convoluted.
for key, val := range m.Range
I like that a fair bit more than
m.Range(func(key, val any) bool {
It's changes like this that will make Go less productive for users over time, IMO. Java-fication.
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.
Great job Go. Hat tip and respect for this. Unlike .Net. I will enable this where it is appropriate.
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.)
Seems healthy to me.
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.
> 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?
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.
func inspect(n ast.Node) func(func(ast.Node) bool) {
return func(f func(ast.Node) bool) {
ast.Inspect(n, f)
}
}
for n := range inspect(f) {
fmt.Printf("%T\n", n)
}So how about a more general case ? A case where we do not have a `func Inspect` already in the stdlib ?
Maybe just replace it with (for example) `filepath.WalkDir` ?
Has anyone had any luck with the YT videos or courses way?
[0]: https://www.oreilly.com/library/view/learning-go-2nd/9781098...
The good news is that the language and stdlib docs are concise and extremely clear. One of the really impressive things about Go.
> 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?>
``` 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.
Forgive me for being cynical, but I don't like that out of the box the toolchain tries to pull all the code at `example.com/business/logic` through google servers.
The language maintainers need to balance a small specification or a small implementation versus the users' demand, but in most cases at least some user demands win routinely. This is especially true when the language has just one major implementation. There is a significant cost for making that implementation more complex, but there is a more significant cost for making millions of programs that rely on a single implementation more complex just to make that implementation simpler.
Anything less is voyeurism.*
* extreme language I know, but it's precisely how I feel about these acts.
None of the above is acceptable. Crash reporting can generate its output locally for people to manually send, if they choose to do so.
I meant (a) "someone" (suits?) said let's install telemetry, (b) the Go team said well hey come on let's make it opt-in rather than defaulting to "on", (c) suits said no we just sneak in the default "on" (cos google ebil).
Google is not quite the monolithic James Bond villainy of your caricature.
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.
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.
With `for x, y := range m.Range`, you know you are iterating over something, and you are getting an `x` and a `y`. For the purposes of understanding the range block and what it does, it doesn't really matter what `m.Range` is, only that it allows iteration. Just like you don't care in <=1.22 land whether `m.Range` is a slice, map, or channel, because for the purposes of understanding the code, that doesn't matter.
> 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 distributions¶
> 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 Version¶
> 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.
If they proposed kicking puppies twice a day, and after some discussion decided to not do that would we all be applauding their decision?
FWIW I wasn't suggesting "villainy" so much as "SNAFU". Google's record on privacy in general leaves something to be desired.