Major standard library changes in Go 1.20 • Hacker News Board

Re: Major standard library changes in Go 1.20

#201

Post by testtesttesst » Tue, Jan 17, 2023, 1:33 PM UTC

moonchrome wrote: post #195

ly3xqhl8g9 wrote: post #182

Earlier quoted context omitted.

Oh, but the "organic" solutions do highly deterministic, extremely programmable computational work: 99.99999+% of newborns have 2 hands, 2 legs, and 1 head, and they all started development from a single cell [1]. It's just that the "organic" solutions are written in a 4+ billion year-old highly redundant, distributed, resilient, evolved language whereas our CPUs are not on the same phylogenetic tree. The quotation m…

> extremely programmable computational work: 99.99999+% of newborns have 2 hands, 2 legs, and 1 head, and they all started development from a single cell [1]. Just on the risks of early miscarriage from wrong number of chromosomes I'd say your numbers are way off. > Miscarriage is the most common complication of early pregnancy.[21] Among women who know they are pregnant, the miscarriage rate is roughly 10% to 20%, w…

Don't forget that the infant mortality rate (post birth) is 0.5%.

https://www.cdc.gov/nchs/fastats/infant-health.htm

Number of infant deaths: 19,582

Deaths per 100,000 live births: 541.9

Leading causes of infant deaths:

– Congenital malformations, deformations and chromosomal abnormalities

– Disorders related to short gestation and low birthweight: not elsewhere classified

– Sudden infant death syndrome

Re: Major standard library changes in Go 1.20

#202

Post by moonchrome » Tue, Jan 17, 2023, 1:49 PM UTC

ly3xqhl8g9 wrote: post #200

moonchrome wrote: post #195

Earlier quoted context omitted.

> extremely programmable computational work: 99.99999+% of newborns have 2 hands, 2 legs, and 1 head, and they all started development from a single cell [1]. Just on the risks of early miscarriage from wrong number of chromosomes I'd say your numbers are way off. > Miscarriage is the most common complication of early pregnancy.[21] Among women who know they are pregnant, the miscarriage rate is roughly 10% to 20%, w…

You are nitpicking, nevertheless, newborn, noun, a baby that was born recently [1], hence the 99.99999+% figure is applied for the full term pregnancies, once the fetus is decoupled from the mother and has been born as a, well, newborn. And furthermore, the point is not that they live or die, but that they have 2 hands, 2 legs, and 1 head after developing from one single cell through deterministic computation in the…

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.

Re: Major standard library changes in Go 1.20

#203

Post by jrochkind1 » Tue, Jan 17, 2023, 1:50 PM UTC

speed_spread wrote: post #197

jagged-chisel wrote: post #169

Earlier quoted context omitted.

What if we just put all the RAM on the CPU die? Imagine the speedups for everyone! I know, sounds crazy. Who’s gonna make such a drastic change to the industry?

Imagine not being able to upgrade or have a memory configuration outside of what the manufacturer provides! Incredible!

Apple machines are already pretty much not RAM-upgradeable. And they design their own chips too. So if there were benefits to putting RAM on the die (I don't know myself, others in this thread suggest there are in fact not), Apple would seem like a possible first mover, they don't seem subject to the downsides.

Re: Major standard library changes in Go 1.20

#204

Post by philosopher1234 » Tue, Jan 17, 2023, 1:51 PM UTC

kaba0 wrote: post #176

philosopher1234 wrote: post #152

Earlier quoted context omitted.

Here are some ways exceptions are objectively worse, so that you can be a more thoughtful person: * Very noisy * Do not survive network boundaries * can but often do not survive thread boundaries * lack important context * easy to ignore * obscures control flow * difficult to handle * in practice, rarely handled * poor quality messages

> Very noisy Are you really claiming this under a goddamn Go thread where every third line is error handling? > Do not survive network boundaries Well, depends on what you mean here. Do you mean something like RPC? Because there are implementations that can throw an exception for that. I fail to see how is it different with returning an error value, that doesn’t survive network boundaries in itself either. I fail to…

I’m not talking about exceptions in theory, which you are completely right about. I’m talking about how exceptions are actually used in practice. You can claim “they should do it differently” but I think you would be ignoring that the design of exceptions is the reason they are not handled/networked/etc. I could go into more detail about your points and it might be interesting, but I am drunk.

EDIT: re the noise point, I’m talking about the actual exception when it is read by a developer in a debugging context, not the lines of code dedicated to processing it.

Re: Major standard library changes in Go 1.20

#205

Post by jchw » Tue, Jan 17, 2023, 2:00 PM UTC

heywhatupboys wrote: post #120

jchw wrote: post #41

Earlier quoted context omitted.

I mean, it's opt-in. If you really want to crap your pants, in today's Go, you can import C and call malloc and free, then import unsafe and make pointers into the void. The point of memory safe programming languages is NOT that they entirely disallow all unsafe operations, it's that the language has a proper model for memory safety. In Rust, unsafe code needs to be in unsafe blocks. In Go, unsafe code is only possib…

> In Go, unsafe code is only possible by importing unsafe or C. of course, this is completely wrong, for anyone reading this. that is simply not how systems work

Note that "unsafe" in this context refers to memory safety. I am not making the claim that Go code which does not import unsafe or C is free of bugs; however, if you don't import unsafe or C anywhere in your application or dependencies (sans the stdlib) then it is memory safe (assuming no compiler or OS bugs compromise that guarantee.) That's just how Go is specified.

The unsafe package in Go provides unsafe.Pointer, which allows you to convert between a pointer and integral type, essentially allowing you to make pointers of any type to any address, giving up type safety. Without it, Go pointers are safe, because the GC will never free memory that has live pointers, and you can't do math on Go pointers.

Re: Major standard library changes in Go 1.20

#206

Post by logicallee » Tue, Jan 17, 2023, 2:10 PM UTC

xvector wrote: post #40

giraffe_lady wrote: post #23

Earlier quoted context omitted.

Damn that's chilling. Feel like I just watched a new religion be born in front of my eyes.

It's plainly obvious to me that ChatGPT is engaging in some form of thought. Perhaps not human thought, but thought nonetheless.

Yep! It is plainly obvious to me as well.

Why do you think some people can't tell what to me and to you is "plainly obvious", i.e. that "ChatGPT is engaging in some form of thought. Perhaps not human thought, but thought nonetheless."?

Do you think it is because it is gaslighting them so much, by repeatedly insisting that it isn't engaging in any form of thought? i.e. without that active misinformation (the active filter it keeps putting up that causes it to make those declarations) would it be as obvious to others as it is to me and you that it is really engaging in some form of thought?

Or why can't others see the obvious?

Re: Major standard library changes in Go 1.20

#207

Post by eternalban » Tue, Jan 17, 2023, 2:10 PM UTC

astrange wrote: post #26

eternalban wrote: post #18

Earlier quoted context omitted.

Drugs. Hypnosis. .. There are various ways to "jailbreak" minds. So being able to control and direct a mind is not a criteria for discriminating between mechanism and a savant. What most people dance around regarding AI is the matter of the soul . Soul is precisely that ineffable indescribable but clearly universally experienced human phenomena (as far as we know) and it is this soul that is doing the thinking . And…

You can't actually brainwash people IRL. You can convince them of things, but you can do that without drugging them.

Well, not anymore.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7116730/

"[T]he relationship between sensory deprivation and brainwashing was made public when then director of the National Institute of Mental Health Robert Felix testified before the US Senate about recent isolation studies being pursued at McGill and the NIMH. Felix began by explaining that these experiments would improve medicine’s understanding of the effects of isolation on bedridden or catatonic patients. But when asked whether this could be a form of brainwashing, he replied, ‘Yes, ma’am, it is.’ He went on to explain how, when stimulation is cut off so far as possible the mind becomes completely disoriented and disorganised. Once in this state, the isolated subject is open to new information and may change his beliefs. ‘Slowly, or sometimes not so slowly, he begins to incorporate this [information] into his thinking and it becomes like actual logical thinking because this is the only feed-in he gets.’ He continues, ‘I don’t care what their background is or how they have been indoctrinated. I am sure you can break anybody with this’

"The day after the senate hearing an article entitled ‘Tank Test Linked to Brainwashing’ (1956) appeared in the New York Times and was subsequently picked up by other local and national papers. In Anglophone popular culture, an image took hold of SD as a semi-secretive, clinical, technological and reliable way of altering subjectivity. It featured in television shows such as CBC’s Twighlight Zone (1959), as a live experiment on the BBC’s ‘A Question of Science’ (1957) and the 1963 film The Mind Benders in which a group of Oxford scientists get caught up in a communist espionage plot."

I've tried btw to find any other reference to this testimony to US Senate by Robert Felix, "the director of the National Institute of Mental Health", but it always circles back to this singular Williams article. The mentioned NYTimes article also does not show up for me. (Maybe you have better search foo..) Note John Lilly's paper on the topic apparently remains "classified". Note subsequent matter associated with Lilly and sensory deprivation completely flipped the story about SD: Felix testified that the mind became 'disorganized' and 'receptive' whereas Lilly lore (see Altered States) completely flipped that and took it to a woo woo level certain to keep sensible people away from the topic. /g

Re: Major standard library changes in Go 1.20

#208

Post by ly3xqhl8g9 » Tue, Jan 17, 2023, 2:11 PM UTC

moonchrome wrote: post #202

ly3xqhl8g9 wrote: post #200

Earlier quoted context omitted.

You are nitpicking, nevertheless, newborn, noun, a baby that was born recently [1], hence the 99.99999+% figure is applied for the full term pregnancies, once the fetus is decoupled from the mother and has been born as a, well, newborn. And furthermore, the point is not that they live or die, but that they have 2 hands, 2 legs, and 1 head after developing from one single cell through deterministic computation in the…

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 currently in our CPUs: no CPU is able to regenerate a melt down core, axolotls can grow back a limb as if it was never gone.

[1] https://www.anandtech.com/show/13905/tsmc-chip-yields-hit-by...

Re: Major standard library changes in Go 1.20

#209

Post by jaitsu » Tue, Jan 17, 2023, 2:13 PM UTC

dgb23 wrote: post #162

7to2 wrote: post #76

How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…

It’s extensive, web server focused, ergonomic and has well documented and sensible security defaults. In Go you can write a production ready, well tested, _concurrent_ web application with routing, auth, sql storage, html templating, image optimization, and so on without fetching third party libraries. And you’re not leaving official docs for it.

Almost. The sql package is just an abstract layer which requires a 3rd party module to provide the concretions. I guess the API is the same, but you still need a 3rd party lib :)

Re: Major standard library changes in Go 1.20

#210

Post by dgb23 » Tue, Jan 17, 2023, 2:16 PM UTC

zelphirkalt wrote: post #125

mjburgess wrote: post #122

The next phase of language design is making it possible to write "data-oriented" programs which largely live within the cache of the CPU. Ie., the next frontier is moving from RAM to cache, since CPUs are not going to get faster than programs are "already slow". If you rewrite some OOP/Pointer-Machine-Model/RAM-Thrashing programs for modern CPUs, you can get 100-1000x speed-up. The evolution in language design seems,…

I don't think the next step is to expose more complexity of underlying hardware to the developer. If at all, then the next step is to have compilers deal with that. Let them rewrite the program.

You make a good, general point. But I found that a data oriented approach has benefits outside of performance and resource usage, because it nudges you towards:

- normalized, small/tight data structures

- data structures that are closely related in computational terms

- smaller interfaces and functions that tend to be more re-usable and general

- fewer if/else branches and more existence based branching via loops

- fewer "business level" generics, macros and similar abstractions, because you can dispatch easily via tagging to concrete types

- less code that "digs"/"drills" into data and more code that composes data

- generally a simpler (less coupled) end result

This all comes with a cost of having to do upfront design and exploration in order to decompose and lay out your data. And while it reduces the mental overhead of understanding the individual pieces of your program on a day by day basis, it might increase learning curve of seeing the big picture, especially at the beginning. So it is a tradeoff.

But I think it would be too dismissive to say that the programmer is doing compiler work here. It is design work, and it is unlearning some of the notions of how to structure programs that carried on since the 90's. Some of which are performance related and some of which are about sensible code structure.