Earlier quoted context omitted.
I can barely understand what you're saying.
In entirety or a specific part?
Major standard library changes in Go 1.20
211–220 of 265 posts
Re: Major standard library changes in Go 1.20
#212Earlier 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…
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
#213Earlier 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…
Re: Major standard library changes in Go 1.20
#214Earlier 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.
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
#215Earlier 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
Re: Major standard library changes in Go 1.20
#216"major standard library changes" is not something you want to here as a consumer of said library.
Re: Major standard library changes in Go 1.20
#217Earlier 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…
Re: Major standard library changes in Go 1.20
#218It 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
#219Earlier 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.
Re: Major standard library changes in Go 1.20
#220Earlier 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?)