neild · HackerTrans

neild

no profile record

投稿

The Myth of Google’s Plus

blog.zarfhome.com

3 ポイント投稿者 neild3 年前0 コメント

Why Bitcoin will fail

apenwarr.ca

55 ポイント投稿者 neild15 年前0 コメント

SCons is full of win today

esr.ibiblio.org

2 ポイント投稿者 neild15 年前0 コメント

コメント

2 か月前議論

Fair enough, but that leaves us with no way to represent zone IDs in URLs at all. Neither http://[fe80::4%eth0]/ nor http://[fe80::4%25eth0]/ is valid under RFC 3986.

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.

2 か月前議論

> In theory, there is guidance for how to properly handle IPv6 zones in user interfaces in RFC 9884, but there's no such guidance for URLs.

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!)

4 か月前議論

Mint (T-Mobile MVNO) has been great for me, $20/month/line and my one experience with international travel was good ($20 for 10 days). I used to be on Verizon and the quality of service doesn’t seem any worse while the price is dramatically lower.

4 か月前議論

Sounds ridiculous, but worked on mine! So far, the fix has stuck, too.

6 か月前議論

Much more prosaic (if slightly embarrassing), I'm afraid: The update was non-trivial (this CL is simple, but there are some accompanying ones in x/text which are not) and it didn't hit the top of the priority list for anyone who understands x/text.

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.

7 か月前議論

To be very pedantic, there are two separate services: The module proxy (proxy.golang.org) serves cached modules and makes no guarantees about how long cache entries are kept. The sum database (sum.golang.org) serves module checksums, which are kept forever in a Merkle tree/transparency log.

8 か月前議論

0600 and 0_600 are octal literals:

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

11 か月前議論

In my experience, the Apple Watch blood oxygen monitoring was horribly inaccurate. It would report wildly variable results, often telling me that I had a blood oxygen level of 80% (which, if true, would indicate that I should be getting myself to an emergency room ASAP).

Regular pulse oxygen meters are cheap and reliable.

11 か月前議論

It means we're not confident the API is stable yet. There might be further changes before the final, non-experimental version, depending on user feedback and further experience with the current proposal.

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 really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose.

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).

昨年議論

I have a 2024 Kia EV6, and this is pretty much what it does: Central screen displays CarPlay, backup camera, and infrequently-used settings controls, dials and knobs for most things, one secondary touchbar (row of buttons, but it’s really a touchscreen so the buttons can change) for climate controls. Pretty much perfect, although only wired CarPlay. (The 2025 models apparently have wireless.)

2 年前議論

> I say this not to be flippant or sarcastic but rather to ask how our ancestors seemed fine with the above but we seem less so?

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.

2 年前議論

The "move a branch from one commit to another without changing anything" command is "git reset".

"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".

2 年前議論

I do almost all my cooking on cast iron—no philosophical reason, it just works well and once I figured out how to use it I found that I pretty much always reach for a cast iron pan over stainless steel or non-stick. (Except non-stick for omelettes and stainless steel for anything where I want the find.)

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.

2 年前議論

A non-blocking send doesn't work in this case. Consider: User provides DoChan an unbuffered channel, and then reads a value from it. If the send is nonblocking and occurs before the user reads from the channel, the value is lost.

2 年前議論

Returning a channel avoids questions of what happens if sending to a caller-supplied channel blocks. DoChan returns a channel with a single-element buffer, so a single send to the channel will always succeed without blocking, even if the caller has lost interest in the result and discarded the channel.

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

2 年前議論

Of possible interest to anyone testing concurrent Go code in general and time in particular, a proposed standard library package: https://go.dev/issue/67434

2 年前議論

There are some interesting results in here, but the slower cases are a bit misleading. The majority of time in the slow cases is spent constructing errors, not in errors.Is.

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")

A nil error indicates success, and a non-nil error indicates some other condition. This is the infamous "if err != nil {}" check. Comparing an error to nil is pretty fast, since it's just a single pointer comparison. On my laptop, it's about 0.5ns. Comparing a bool is about 0.3ns, so "err != nil" is quite a bit slower than "!found", but it's really unlikely the 0.2ns is going to be relevant outside of extremely hot loops.

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

This is quite a bit more expensive than "return ErrNotFound". The fmt.Errorf function will parse a format string, produce the error text, and make two allocations (one for the error string, one for a small struct that holds it). This is about 84ns on my laptop--168 times slower than the fast path! But 84ns is still pretty fast, and you can't get away from the need for at least one allocation if you want to return an error that's varies based on the inputs of the function that produced it. (You can get faster than fmt.Errorf if it matters, but this comment is already getting large.)

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

And you can then use the errors.Is function to ask whether an error is equal to ErrNotFound, or if it wraps ErrNotFound:

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

On my laptop, producing a wrapping error like this and testing it with "err != nil" is about 91ns, and testing it with "errors.Is(err, ErrNotFound)" is about 98ns. So using Is is adding 7ns of overhead, which is not nothing, but is also pretty much lost in the noise compared to creating the error in the first place.

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

(That is, by the way, a very difficult error to read. Don't hand users errors that look like that.)

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.

2 年前議論

In addition, Chinese characters encode more information than English letters, so a text written in Chinese will generally consume fewer bytes than the same text in English even when using UTF-8.

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

2 年前議論

The article doesn't refer to that incident, so far as I can see. It does mention Patty Hearst, who was kidnapped a year after the Stockholm bank robbery.

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-...