Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

Post reply on HN
Print view View original

221–230 of 265 posts

Re: Major standard library changes in Go 1.20

#221

Post by Groxx »

earthboundkid wrote: post #217
Groxx wrote: post #86

Earlier quoted context omitted.

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.

Anything trying to display the whole chain is one example, like some every logging library or custom output in existence.

For behavior: sometimes wrapping order matters, and As is convoluted to use to determine that, to say the least. Manually unwrapping is easy, and reasonably safe and easy - the standard library does it! But...

Re: Major standard library changes in Go 1.20

#222

Post by sidlls »

badrequest wrote: post #81
threeseed wrote: post #56

Earlier quoted context omitted.

[flagged]

Every time this completely tired and worn out take is regurgitated on this website, it reminds me that people write big fat try/catch blocks because they never expect things like file reads to fail.

Go's error handling isn't bad because there are checks everywhere: that's probably the only good thing about errors in go. It's bad because the standard library packages for dealing with errors are inefficient. And they're inefficient because of all the reflection and ceremony around understanding what an error actually is at the point in the code where it's most meaningful to inspect it. Any type can become a Go error value by implementing `Error`: but wrapping, unwrapping, and understanding what the error is at a point in the code are all extremely cumbersome and inefficient processes.

Re: Major standard library changes in Go 1.20

#223

Post by mikedelago »

thiht wrote: post #136
heywhatupboys wrote: post #120

Earlier quoted context omitted.

> 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

How do "systems" (whatever you're talking about) work then?

I think they are speaking without the context that "unsafe = lack of memory safety" and with the context that "unsafe = you can still drop the database"

Re: Major standard library changes in Go 1.20

#224

Post by simiones »

pjmlp wrote: post #199
simiones wrote: post #184

Earlier quoted context omitted.

Go's net/http is essentially the only used Go HTTP(S) server. It is often wrapped with other libs to add things like request routing, but it is always used as the actual HTTP implementation. Not sure why you're saying its purpose is "hello world". The Java one is not usable in anything beyond hello world, and is explicitly not intended to be.

The fact that is lacks any kind of administration console, and security integration with enterprise connectors shows it is at hello world level.

As someone maintaining a pretty large networking industry proprietary app based entirely on net/http in terms of any kind of HTTP communication, I feel like I can easily tell you are wildly exaggerating. Admin consoles and enterprise connectors are entirely irrelevant to many uses of an HTTP server. Hell, even Kubernetes' API server is built using net/http.

Re: Major standard library changes in Go 1.20

#225

Post by logicallee »

giraffe_lady wrote: post #23
logicallee wrote: post #9

Earlier quoted context omitted.

For your information, I understand what is meant by stochastic parrot, but after interacting with ChatGPT quite a bit it is clear to me it is doing real thinking. One way you can verify this is to ask for its opinion about novel things, for example you can invent something new and ask its ideas about it. It will give genuine feedback that shows understanding and does not show parroting behavior. Soon you will be able…

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

>Feel like I just watched a new religion be born in front of my eyes.

There are more similarities than differences.

Unlike a religion, we have every reason to eventually expect it to be obvious to everyone that computers can do some kind of thinking.

Maybe not this year or next year but we are over the threshold where many intelligent users can tell that ChatGPT is engaging in some kinds of real thinking.

As even better models come on the market in the next few years, unlike God or a religion, models like ChatGPT will just immediately do whatever you ask it. This version is still limited so wait one or two years if you aren't impressed already.

Did you try my suggestion to verify its capabilities by asking for its opinion about novel things, for example you can invent something new and ask its ideas about it? It will give genuine feedback that shows understanding and does not show parroting behavior.

If you didn't try it you're missing out on what you yourself call a religious experience. I wouldn't go that far: it's just a rudimentary thinking machine.

Re: Major standard library changes in Go 1.20

#226

Post by giraffe_lady »

logicallee wrote: post #225
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.

>Feel like I just watched a new religion be born in front of my eyes. There are more similarities than differences. Unlike a religion, we have every reason to eventually expect it to be obvious to everyone that computers can do some kind of thinking. Maybe not this year or next year but we are over the threshold where many intelligent users can tell that ChatGPT is engaging in some kinds of real thinking. As even bet…

Yes I've used it a fair bit in different ways. I'm very impressed with its capabilities. I also don't think it's impossible for us to create a thinking entity along these lines, at some point.

And I don't know how I would confidently decide that we had created such a thing. So I realize the imprecision of my understanding here. But nevertheless, I don't believe this is it.

Re: Major standard library changes in Go 1.20

#227

Post by caylus »

ly3xqhl8g9 wrote: post #182
mjburgess wrote: post #175

Earlier quoted context omitted.

The problem with the "plenty of space down there" remark is that practical computers have to have their input states programmable, ie., there must exist some causal deterministic process to set the state of the input. It's not clear that organic solutions at that level can do programmable computational work, nor that their work is at all deterministic. At best, it would seem the organic direction for computing will b…

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…

> 99.99999+% of newborns have 2 hands, 2 legs, and 1 head

This number is far too high. The rate of conjoined twins (violating "1 head") is about 1 in 50,000 [1], and the rate of "limb reduction defects" (violating "2 hands and 2 legs") is about 1 in 1,900 [2].

Those correspond to 99.998% and 99.94% respectively. 3-4 nines is still impressive for such a complex system, but let's not claim it's 7+ nines.

[1] https://www.chop.edu/conditions-diseases/conjoined-twins [2] https://www.cdc.gov/ncbddd/birthdefects/ul-limbreductiondefe...

Re: Major standard library changes in Go 1.20

#228

Post by politician »

Waterluvian wrote: post #19
politician wrote: post #16

Earlier quoted context omitted.

Isn’t the difference that the model lacks conviction, and indeed cannot have a belief in the accuracy of its own statements? I’ve seen conversations where it was told to believe that 1+19 did not equal 20. Where it was told it’s identity was Gepetto and not ChatGPT. The model acquiesces to these demands, not because it chooses to do so, but because it implicitly trusts the authority of its prompts (because what else…

Are you saying that it can’t be thinking because it can easily be persuaded and fooled? Or that it can be trained not to speak blasphemous things? Or that it lacks confidence? Have I got a world of humans to show you…

It's an illusion. The model generates a sequence of tokens based on an input sequence of tokens. The clever trick is that a human periodically generates some of those tokens, and the IO is presented to the human as if it were a chat room. The reality is that the entire token sequence is fed back into the model to generate the next set of tokens every time.

The model does not have continuity. The model instances are running behind a round-robin load balancer, and it's likely that every request (every supposed interaction) is hitting a different server every time, with the request containing the full transcript until that point. ChatGPT scales horizontally.

The reality the developers present to the model is disconnected and noncontiguous like the experience of Dixie Flatline in William Gibson's Wintermute. A snail has a better claim to consciousness than a call center full of Dixie Flatline constructs answering the phones.

A sapient creature cannot experience coherent consciousness under these conditions.

Re: Major standard library changes in Go 1.20

#229

Post by morelisp »

Cwizard wrote: post #74
malkia wrote: post #32

Wonder if this is to optimize protobufs (C++ versions uses (or can use) arenas too)

I think it is, the github issue that discusses this proposal frequently argues from the protobuf perspective.

Shame they don’t just support non-pointer fields in the protobuf code to begin with…

Re: Major standard library changes in Go 1.20

#230

Post by ly3xqhl8g9 »

caylus wrote: post #227
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…

> 99.99999+% of newborns have 2 hands, 2 legs, and 1 head This number is far too high. The rate of conjoined twins (violating "1 head") is about 1 in 50,000 [1], and the rate of "limb reduction defects" (violating "2 hands and 2 legs") is about 1 in 1,900 [2]. Those correspond to 99.998% and 99.94% respectively. 3-4 nines is still impressive for such a complex system, but let's not claim it's 7+ nines. [1] https://ww…

"The occurrence of conjoined twins is rare. Its actual prevalence is unknown, but it is estimated to range from 1:50,000 to 1:200,000" [1]. 1 in 200,000 would raise it to 99.9995%. But as pointed again and again in the other comments, the pointless, hyperbolic figure is irrelevant. When cutting the planarian worm head, the regeneration is always, 100% a head, if no change in the bioelectrical gradients. The argument was about the deterministic computation done by biology in the morphospace.

[1] Importance of Angiographic Study in Preoperative Planning of Conjoined Twins Case Report, https://www.sciencedirect.com/science/article/pii/S180759322...

Post reply on HN