Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

211–220 of 265 posts

Re: Major standard library changes in Go 1.20

#211

Earlier quoted context omitted.

I can barely understand what you're saying.

In entirety or a specific part?

i Think I couldn’t quite get your specific criticism and the supporting reasons. I had a feeling of strain while I was trying to parse what you wrote

Re: Major standard library changes in Go 1.20

#212

Earlier quoted context omitted.

I'm not nitpicking - I'm saying the reason most babies are born with 2 legs hands and a head is because genetic defects die off before birth (plus the screening we have for early termination nowadays) - and the failure rate starting from a single cell is huge.

The genetic defects failure rate is irrelevant, TSMC also throws away bad batches [1], mistakes happen, life is complex and multifaceted, etc. The issue is if biology is a deterministic computational platform, and the argument I was making, using the hyperbolic figure of 99.99999%, I will grant you this, is that not only biology is a deterministic computational platform, but it is better than the one we can achieve c…

But at that point your argument is almost tautological - all children born alive are fit to survive ? Being born with such huge asymmetry (missing limbs) and still surviving is low probably (impossible without a head).

I'd say a more convincing argument for deterministic machinery is identical twins - I don't know how much variation there is to put in numbers.

Re: Major standard library changes in Go 1.20

#213

Earlier quoted context omitted.

I'm not nitpicking - I'm saying the reason most babies are born with 2 legs hands and a head is because genetic defects die off before birth (plus the screening we have for early termination nowadays) - and the failure rate starting from a single cell is huge.

The genetic defects failure rate is irrelevant, TSMC also throws away bad batches [1], mistakes happen, life is complex and multifaceted, etc. The issue is if biology is a deterministic computational platform, and the argument I was making, using the hyperbolic figure of 99.99999%, I will grant you this, is that not only biology is a deterministic computational platform, but it is better than the one we can achieve c…

[deleted]

Re: Major standard library changes in Go 1.20

#214

Earlier quoted context omitted.

The genetic defects failure rate is irrelevant, TSMC also throws away bad batches [1], mistakes happen, life is complex and multifaceted, etc. The issue is if biology is a deterministic computational platform, and the argument I was making, using the hyperbolic figure of 99.99999%, I will grant you this, is that not only biology is a deterministic computational platform, but it is better than the one we can achieve c…

But at that point your argument is almost tautological - all children born alive are fit to survive ? Being born with such huge asymmetry (missing limbs) and still surviving is low probably (impossible without a head). I'd say a more convincing argument for deterministic machinery is identical twins - I don't know how much variation there is to put in numbers.

"But at that point your argument is almost tautological"

Yes, that is the point: biodevelopment is deterministic and computational. Watch the Michael Levin video linked above: they cut the head of a planarian worm, it grows back a head; they cut the tail, it grows back a tail; they cut the tail and the head and change the bioelectric gradients, it grows back two heads or two tails.

Re: Major standard library changes in Go 1.20

#215

Earlier quoted context omitted.

In entirety or a specific part?

i Think I couldn’t quite get your specific criticism and the supporting reasons. I had a feeling of strain while I was trying to parse what you wrote

Specific criticism: the lack of direction or misdirection (bad goals) leads to changing (or even overriding previous decisions as in the example case of the use of [] postfix (after the type) placement) reasoning of how & why language is implemented in a certain way. A complex history is not certainly not limited to Go, but a more complicated process makes reading & writing the code an exercise in trying to understand & remember the relevant language history.

Re: Major standard library changes in Go 1.20

#217
post #86

Earlier quoted context omitted.

It’s the same paradigm. You still have to do if err != nil. Multierrors have been in the community forever. It’s just been added to the standard library is all.

Well. Kinda. Except that now if someone does `errors.Join` and they pass it to existing code that was using `errors.Unwrap` to inspect an error chain... ... they now get a not-unwrap-able error. Which they can still `As` to inspect... ...but since it's a tree, they can't recursively-`As` to find all instances of a type of error in a chain, like they could before (if you find something in one branch, you can only trav…

Why would the other code be manually unwrapping and then doing an As test instead of using errors.As? That's extremely Hyram's Law behavior. :-) I agree though that if you have an error log reporting system it should be updated to understand the new multierrors. OTOH, if it's not, it will just see the multierrors as a single node and work fine otherwise.

Re: Major standard library changes in Go 1.20

#218
The arena goexperiment contains code used inside Google in very limited use cases that we will maintain, but the discussion on https://go.dev/issue/51317 identified serious problems with the very idea of adding arenas to the standard library. In particular the concept tends to infect many other APIs in the name of efficiency, a bit like sync.Pool except more publicly visible.

It is unclear when, if ever, we will pick up the idea and try to push it forward into a public API, but it's not going to happen any time soon, and we don't want users to start depending on it: it's a true experiment and may be changed or deleted without warning.

The arena text in the release notes made them seem more official and supported than they really are. We've deleted that mention from the release notes to try to set expectations better. Posting here to leave a note for people who are curious where they went.

Re: Major standard library changes in Go 1.20

#219
post #98

Earlier quoted context omitted.

I think I can sympathise, it's hard to keep up with all the development in PL, so it's easy to convince yourself that all those new inventions are stupid anyway and you don't need them, you'll do it your way. And then, slowly over a couple of decades, other people will be making it their life's work to add in the things that you thought were stupid because inevitably the need for them surfaces.

Or you've seen an approach fail spectacularly in a programming language you're familiar with, which causes you to throw out the baby with the bath water.

Any specific examples you can share?

Re: Major standard library changes in Go 1.20

#220
post #174

Earlier quoted context omitted.

Caches are much more limited than RAM though. If every program under the sun starts targetting them directly, is the 100-1000x speedup hold true? Legit question, I have no idea about how this would behave.

Reserve cache for performance sensitive programs? (OS support?)

How does the OS know for which programs I require better performance?
Post reply on HN