It accesses the module proxy proxy.golang.org, which is run by Google. If you want to opt-out of this module mirror, you can turn it off by setting GOPROXY=direct.
The proxy has a clear privacy policy: https://proxy.golang.org/privacy
It collects anonymized usage metrics like other package registries (rubygems.org, nuget.org, crates.io) do.
Which also serves a useful purpose for devs, it's an easy way to avoid typosquatting by making sure you're not looking at a package with a similar name to the one you want but with only 2,000 views instead of 2,000,000
Not only that, but despite all of the other syntactic sugar Go is lacking (usually sorely, such as a “try” error handler), the switch statement is really just an “if” statement in disguise.
var someVar, anotherVar string
// ...
switch {
case someVar == "whatever":
fmt.Println("Tell me how, exactly,")
case anotherVar == "nope":
fmt.Println("this compiles to a jump table?")
default:
fmt.Println("Spoiler: it doesn't.")
}
> the switch statement is really just an “if” statement in disguise
If the switch is over a fixed set of strings, then can't the backend generate a perfect hash function ala gperf and then proceed to use the computed hash value to implement a jump table?
Go currently uses a binary search for integer switches (and I believe serial comparisons otherwise). Jump tables are in development and likely to appear around 1.19 or 1.20. As you say, there's a lot of edge cases to consider when figuring out whether a table or comparisons are the better choice.
Note that my example “switches” over two independent variables. Even if the Go compiler did generate a table, for this example it would really be generating two tables: and then we're back to the “how is this better than an `if`?” question.
I mean in Java vs. C# fights people still bring up that C# generics are reified while Java generics rely on casting and erase type information at runtime, so probably not.
> No mention of why they left them out in non-interface types.
Actually it does:
"Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all. If we disregard interfaces, any parameterized method can be implemented as a parameterized function."
"And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable."
So methods with type parameters would a) not be usable with interfaces and b) not be usable with reflection.
I'm not too worried about his claims. His claim was about the Foundation being shadow-controlled by Amazon (they employed the board chair who had more influence while they lacked an Executive Director). The foundation manages the assets (donations, legal marks, etc) and has no control of the actual language. For Amazon to take control, theyd have to get the board involved and then leverage the assets against the developers. Nothing like this has happened and there is now an Executive Director.
When observing that incident, I noticed that those joining the bandwagon didn't seem to have direct knowledge of the situation. Those that did, stayed quiet or made general statements about the claims not being accurate regarding why there wasn't an Executive Director yet (interim or not). To me, this suggests something happened that, professionally, people feel should be kept confidential and I try to support that by not doing further speculation.
I mean, I am pretty far from all of that and I'm not really sure how it works. It's just generally a bit worrying when you hear from a few independent sources: "don't trust (X), they're behaving badly"
