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

251–260 of 265 posts

Re: Major standard library changes in Go 1.20

#251

Post by logicallee »

smoldesu wrote: post #241
logicallee wrote: post #206

Earlier quoted context omitted.

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 fi…

> Or why can't others see the obvious? Because I've been told a lot of things, and I'd be a fool if I believed them all. I'll believe ChatGPT is onto something when I ask it to think about a treatment for cancer and get real results. For now, it's only capability is synthesizing realistic text. Easy enough to be mistaken for real thought, but clearly distinct when you ask it to do something novel.

Consider what would happen if you did ask it to think about a treatment for cancer and got real results. Clearly you would think it is just summarizing papers it read.

That makes sense, since it is not a cancer researcher.

So I'm way more impressed by ChatGPT than that. Even if it correctly data-mined and answered the question, it would not be that impressive. That's right: getting a cure from cancer when you ask is less impressive than what it actually does.

Because what it actually does is show the ability to judge novel situations, to invent and act creatively, and to keep abstract notions in its head. That is much more impressive than spitting out a cure for cancer.

Re: Major standard library changes in Go 1.20

#252

Post by xvector »

smoldesu wrote: post #241
logicallee wrote: post #206

Earlier quoted context omitted.

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 fi…

> Or why can't others see the obvious? Because I've been told a lot of things, and I'd be a fool if I believed them all. I'll believe ChatGPT is onto something when I ask it to think about a treatment for cancer and get real results. For now, it's only capability is synthesizing realistic text. Easy enough to be mistaken for real thought, but clearly distinct when you ask it to do something novel.

That doesn't seem like a very robust Turing test. But ChatGPT is indeed able to reason about cancer treatments at least as well as your average human.

Re: Major standard library changes in Go 1.20

#253

Post by [deleted] »

pjmlp wrote: post #250
doctor_eval wrote: post #240

Earlier quoted context omitted.

There is frequently a reverse proxy in front of all web services. It’s got nothing to do with the quality of the implementation behind the curtains. And “the actual load” is by definition managed by the endpoint not the router. I mean it would be trivial to implement that reverse proxy in Go. And I do mean trivial; Go also includes a reverse proxy utility, so you can implement something basic in about 5 LOC. At this…

So trivial that it isn't usually the case. A weekend project and going at scale isn't the same thing.

[deleted]

Re: Major standard library changes in Go 1.20

#254

Post by doctor_eval »

pjmlp wrote: post #250
doctor_eval wrote: post #240

Earlier quoted context omitted.

There is frequently a reverse proxy in front of all web services. It’s got nothing to do with the quality of the implementation behind the curtains. And “the actual load” is by definition managed by the endpoint not the router. I mean it would be trivial to implement that reverse proxy in Go. And I do mean trivial; Go also includes a reverse proxy utility, so you can implement something basic in about 5 LOC. At this…

So trivial that it isn't usually the case. A weekend project and going at scale isn't the same thing.

sigh

Re: Major standard library changes in Go 1.20

#255

Post by lakomen »

metadat wrote: post #3
candiddevmike wrote: post #2

Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

The only constant is change. Especially with Go, apparently. It's hard to evaluate the comparison of Golang of today to the one I originally discovered 11 years ago in 2012. Then, it was a breath of fresh air. Nowadays.. I find myself sighing. It works but the joy has faded. Bit rot is life.

Yeah I'm not using generics and they're a big turn off. If Rust wasn't so ugly and the JVM so Swiss-cheesy and stuck in paradigms, I would switch.

So I keep writing my old ways code in Go and act like the new features don't exist.

Big sigh

Re: Major standard library changes in Go 1.20

#256

Post by jagged-chisel »

jrochkind1 wrote: post #203
speed_spread wrote: post #197

Earlier quoted context omitted.

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.

This is exactly what "unified memory" is on Apple systems, the RAM is on the silicon with the CPU.

> ... the available RAM is on the M1 system-on-a-chip (SoC).

Re: Major standard library changes in Go 1.20

#257

Post by jagged-chisel »

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?

Judging by the replies, it seems no one is looking at Apple's "Unified Memory." RAM is on the same silicon with the CPU.

Re: Major standard library changes in Go 1.20

#258

Post by jagged-chisel »

gpderetta wrote: post #196
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?

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

Distance from the CPU. And traditionally, RAM sits waaaaaay across the motherboard. If you put it on the CPU die, it’s much closer and much faster. Still slower than L1 and L2 cache, sure, but much faster than waiting on the fetch across the motherboard.

Look into Apple’s unified memory.

Re: Major standard library changes in Go 1.20

#259

Post by gpderetta »

jagged-chisel wrote: post #257
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?

Judging by the replies, it seems no one is looking at Apple's "Unified Memory." RAM is on the same silicon with the CPU.

Apple RAM is not on the same silicon[1] as the CPU, just on the same package. Also it doesn't have significant latency advantages. It has higher throughput, possibly because of a custom controller. The biggest advantage is that the GPU doesn't have to go through the PCI bus to access it.

[1] my understanding is that RAM and CPU processes are very different and it is hard to produce a chip with both features while remaining optimal.

Re: Major standard library changes in Go 1.20

#260

Post by simiones »

pjmlp wrote: post #239
simiones wrote: post #224

Earlier quoted context omitted.

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.

Yet many of those depend on having something like Apache, NGIX, HA Proxy, IIS,... taking care of the actual load.

Kubernetes API server is not dependent on Apache, NGINX, HA Proxy, IIS, ... taking care of the actual load, since it's not getting any significant amount of traffic. In general API servers have much bigger scaling problems with actually executing the API calls rather than handling requests at scale. Having an NGINX or something similar to serve some static content and also reverse proxy to a Go server is sometimes nice if you're also serving a large UI app, but in that case NGINX is very much doing trivial work, and Go net/http is handling the real work.
Post reply on HN