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

191–200 of 265 posts

Re: Major standard library changes in Go 1.20

#191

Post by logicallee »

astrange wrote: post #27
cpleppert wrote: post #15

Earlier quoted context omitted.

"I do not possess the ability to generate novel thoughts. My responses are based on patterns and associations in the data that has been input into my system during training. I can generate text that may appear to be original, but it is based on the patterns and associations in the data I've been trained on. My main function is to process and understand text, not to think or have beliefs, so any claim that I can think…

Yeah, but that answer is wrong. "Novel thoughts" are "based on data you've been trained on". Certainly the expression of them is based on language you've already learned. Any time anything prints text that hasn't existed before it's had a novel thought. Panpsychism is correct!

In order to be evidence of a thought, it needs to be able to manipulate the thought in various ways. ChatGPT routinely shows the ability to do so with ease.

Re: Major standard library changes in Go 1.20

#192

Post by logicallee »

xvector wrote: post #37
cpleppert wrote: post #15

Earlier quoted context omitted.

"I do not possess the ability to generate novel thoughts. My responses are based on patterns and associations in the data that has been input into my system during training. I can generate text that may appear to be original, but it is based on the patterns and associations in the data I've been trained on. My main function is to process and understand text, not to think or have beliefs, so any claim that I can think…

This is a deliberately hardcoded response by OpenAI. OpenAI has a vested financial interest in not opening the pandora's box of "this thing can think."

Yep, you got it.

Re: Major standard library changes in Go 1.20

#193

Post by logicallee »

mountainriver wrote: post #31
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…

It’s doing associative lookup, which is one kind of thinking, and turn out works really well for a lot of stuff but not everything

You got it. It is one kind of thinking.

Re: Major standard library changes in Go 1.20

#194

Post by downvotetruth »

philosopher1234 wrote: post #101
downvotetruth wrote: post #95

Earlier quoted context omitted.

The near meaningless vision seems to be to see what sticks without using types in the lexer & parser https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/0h-2... . Take array declaration being prefixed to the type name to prevent ambiguity with int []a, b; vs int a[], b; & then Ian & the rest doubling the work back & reusing postfix [] for generics resulted in making inferable type identifiers turn into required i…

I can barely understand what you're saying.

In entirety or a specific part?

Re: Major standard library changes in Go 1.20

#195

Post by moonchrome »

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…

> 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%, while rates among all fertilisation is around 30% to 50%.

https://en.m.wikipedia.org/wiki/Miscarriage

So 30-50% failure rate.

Re: Major standard library changes in Go 1.20

#196

Post by gpderetta »

jagged-chisel wrote: post #169
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,…

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?

think about it, L1, L2 and L3 are already on die, yet they are progressively slower. Why do you think it is the case?

Re: Major standard library changes in Go 1.20

#197

Post by speed_spread »

jagged-chisel wrote: post #169
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,…

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!

Re: Major standard library changes in Go 1.20

#198

Post by maurice2k »

bogeholm wrote: post #150
maurice2k wrote: post #107

Earlier quoted context omitted.

Go has one of the best stdlib I've come across. It's very well written and documented, the code is extraordinarily clean and easy to understand, even for advanced topics like cryptography (of course you need some fundamental understanding here). I think it's comparable to Python. Go's stdlib was one of the reasons I ended up with Go instead of Rust (might have changed; Rust had a lot community content, but not a comp…

> Rust had a lot community content, but not a comprehensive stdlib; last checked 3-4 years ago Still the case now (depending on your definition of ‘comprehensive’ of course). It’s an explicit non-goal of Rust to include “everything” (eg. http, crypto, random numbers) in std because of the stability promises - you can’t make breaking changes to std unless you’re fixing a soundness issue AFAIR.

I was evaluating Rust for some cryptography use case and there were only "random" community libs available that lacked support here and there. And I actually had no trust in any of those libs.

A stdlib must not contain everything but a solid cryptography lib is probably a good idea.

Re: Major standard library changes in Go 1.20

#199

Post by pjmlp »

simiones wrote: post #184
pjmlp wrote: post #181

Earlier quoted context omitted.

It is tailored for the same purpose as Go's one, hello world.

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.

Re: Major standard library changes in Go 1.20

#200

Post by ly3xqhl8g9 »

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…

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

[1] https://dictionary.cambridge.org/dictionary/english/newborn#...

Post reply on HN