Given that net/url has supported RFC 6874 since before RFC 9844 came along, our choices are:

* Keep supporting the RFC 6874 syntax.

* Drop support for it, require strict RFC 3986, have no support for zone IDs in URLs at all. Breaks existing users, utterly infeasible.

* Stop supporting RFC 6875 and start supporting an unescaped % as the zone ID separator, which conforms to no standard I know of. Also breaks existing users, infeasible.

* Some sort of hybrid where we try to support both %25 and % as a separator? Ugh.

Of these, keeping the existing support as-is until or unless a new standard comes along seems like the best option.

RFC 6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (https://www.rfc-editor.org/rfc/rfc6874.html)

Which says that, yes, you need to %-encode the %, so a URL containing a host of fe80::4%eth0 becomes http://[fe80::4%25eth0]/. Yes, that's ugly. Sorry.

> TL;DR: computers were a mistake.

I agree entirely.

(For what it's worth, I am a maintainer of Go's net/url package, and I believe net/url correctly handles zone ids in URLs. It's always possible there's something wrong I'm not aware of. Please let me know if there is!)

Go is pretty much entirely developed in public; there are some Google-internal customizations but none of them are particularly exciting and almost all changes start in the open source repo and are imported from there.

    octal_lit      = "0" [ "o" | "O" ] [ "_" ] octal_digits .

Regular pulse oxygen meters are cheap and reliable.

In the case of encoding/json/v2, enabling GOEXPERIMENT=jsonv2 has two major effects:

1. It flips encoding/json (the original, not /v2) to use the new implementation. This is supposed to be a fully backwards-compatible change, modulo some changes to the text of some errors. We're very interested to hear of any cases of existing programs breaking when the experiment is turned on, because (aside from the aforementioned error text, which you shouldn't be depending on) it likely indicates a bug that needs fixing. This is the "new code, please test" half of the change.

2. It enables the new API (encoding/json/v2, encoding/json/jsontext, some new options in encoding/json). This is the "unstable API, might change in response to feedback" half of the change.

I don't believe this claim is made anywhere.

We've decided that we are not going to make any further attempts to change the syntax of error handling in the foreseeable future. That frees up attention to consider other issues (with errors or otherwise).

Because by and large our female ancestors raised the children, were offered no choice in whether to raise the children, and their opinions of the situation were not recorded.

"git reset --hard" is "...and also change all the files in the working directory to match the new branch commit".

"git reset --soft" is "...but leave the working directory alone".

My big realization was that there’s a lot of macho information there about the care of cast iron, and it’s pretty much all pointless because the stuff is indestructible and the seasoning doesn’t matter much. Every time I make tortillas in a pan the seasoning gets wrecked, and it’s just not a problem. So long as you get the pan to the right temp and have enough fat, nothing sticks regardless of the quality of the seasoning. Skimp on the oil or set the temp too low, and stuff sticks no matter how good the seasoning.

I wash the pans with soap and water (and not too much scrubbing), I never season them deliberately, and they work wonderfully. It’s a very forgiving cooking surface.

DoChan doesn't close the channel because there isn't any reason to do so.

Some background for anyone not familiar with Go errors:

A Go error is an interface value with an Error method that returns the error's text. A simple error can be constructed with the errors.New function:

  var ErrNotFound = errors.New("not found")

We can also compare an error to some value: "if err == ErrNotFound {}". In this case, we say that ErrNotFound is a "sentinel" (some error value that you compare against). This is about 2.3ns on my laptop; there are two pointer comparisons in this case and a bit more overhead in comparing interface values. (You can actually make this check almost arbitrarily expensive; you could have an error value that's a gigabyte-large array, for example.)

It's common to annotate an error, adding some more useful information to it. For example, we might want our "not found" error to say what was not found:

  return fmt.Errorf("%q: not found", name) // "foo": not found

A problem with using fmt.Errorf in this way is that you can't test the error against a sentinel any more. This was addressed a while back in Go 1.13 with the addition of error wrapping. You can return an error that wraps the sentinel (note the %w format verb):

  return fmt.Errorf("%q: %w", name, ErrNotFound) // "foo": not found

  if errors.Is(err, ErrNotFound) { ... }

The example in this blog post went a step further, though, and created an error with not just a single layer of wrapping but one with four. The error text in the wrapped error cases is:

  GetValue couldn't get a value: queryValueStore couldn't get a value: queryDisk couldn't get a value: not found

Creating a stack of four wrapped errors like this on my laptop is 396ns, and inspecting it with errors.Is is another 21ns. 21ns is waaaaay more than the 0.5ns for a simple "err != nil" check, but again the runtime here is massively dominated by the expense of creating the error--which in this case involves repeatedly creating formatted strings and throwing them away, and two allocations for each layer in the stack.

In general, when doing low level optimization of Go code, avoiding allocations is the biggest bang for your buck. If microseconds matter, you absolutely should pay attention to the cost of constructing error values. But the cost of inspecting those values doesn't usually become an issue unless nanoseconds count, and will generally be dominated by the cost of construction.

Also, even the slowest cases here are running about 0.5-1.5μs, which absolutely matters in some cases, but is irrelevant in many others.

(Consider: Horse is five letters, but 馬 is one character. Even at three bytes per character, Chinese wins.)

The term "Stockholm Syndrome" originates from a police consultant inventing a syndrome to diagnose a woman he had never met, in order to discredit her criticism of the largely incompetent police response to her and several other people being taken hostage by a bank robber.

https://www.independent.co.uk/news/world/americas/stockholm-...