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

171–180 of 265 posts

Re: Major standard library changes in Go 1.20

#171

Post by hknmtt »

doctor_eval wrote: post #168
hknmtt wrote: post #119

[flagged]

> even talking about interfaces like "magic methods" No, this was referring to a mechanism used in the stdlib to see if an object passed in as one interface type, could be coerced to another interface type in order to perform some operation more efficiently. I’m a Go developer, and I didn’t know this happened, it’s basically not visible from the API function signatures, you have to look at the implementation. I love…

there is nothing wrong with asking if provided object is more capable than it seems so we can perform more efficient logic on it. that has nothing to do with magic methods, numbers... no magic whatsoever. "magic" in code refers to usually hidden and/or fixed behavior. this is not even in the same ballpark.

Re: Major standard library changes in Go 1.20

#173

Post by logicchains »

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

A 100x speedup makes sense because a cache miss costs around 100 nanoseconds, compared to arithmetic operations themselves costing under one nanosecond. If you traverse a data structure in which everything's a pointer, every access may well be a cache miss, especially if the rest of the code is also pointer-heavy and thrashes the cache.

Re: Major standard library changes in Go 1.20

#174

Post by asah »

cassianoleal wrote: post #161
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,…

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?)

Re: Major standard library changes in Go 1.20

#175

Post by mjburgess »

ly3xqhl8g9 wrote: post #166
KapKap55 wrote: post #126

Earlier quoted context omitted.

The 100x plus speedup is no exaggeration either, I've noticed some incredulity from others at the numbers. For a very simple comparison, I recently was testing a (poorly) custom built data-oriented Entity-Component-System for usage in games with a more typical "componentized" object approach. No multithreading or anything complicated. On my system, the typical approach could generate about 1000 new objects and attach…

-----s.-ms.-us.-ns|---------------------------------------------------------- 0.1 ns - NOP 0.3 ns - XOR, ADD, SUB 0.5 ns - CPU L1 dCACHE reference (1st introduced in late 80-ies ) 0.9 ns - JMP SHORT 1 ns - speed-of-light ?~~~~~~~~~~~ 1 ns - MUL ( i**2 = MUL i, i ) 3~4 ns - CPU L2 CACHE reference (2020/Q1) 5 ns - CPU L1 iCACHE Branch mispredict 7 ns - CPU L2 CACHE reference 10 ns - DIV 19 ns - CPU L3 CACHE reference (…

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 be about building robots rather than CPUs.

Re: Major standard library changes in Go 1.20

#176

Post by kaba0 »

philosopher1234 wrote: post #152
kaba0 wrote: post #109

Earlier quoted context omitted.

Exceptions are objectively better in every way (especially checked exceptions, which would definitely deserve a second chance!) You get as small/large-grained handling as you need, get sane default behavior (bubbling up to a place where you can actually handle that error), and stack-traces, while you never accidentally overlook a potential failing call (will the 100th if err 3 liner properly handle the error case or…

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 come up with any example where exceptions are worse than error return types in the context of threads.

come on, exceptions give you a stack trace with the whole history of what got called from where. How is that worse than your “file missing” error without any explanation?

> easy to ignore

Checked exceptions are a thing. But it is enough to handle them higher up and it will be handled one way or another, while it is much easier to simply fail to handle an err.

> in practice, rarely handled

I can just as well claim that go-style error handling is more often then not not handling properly the issue at hand, and is most definitely not tested for the error case. A bubbled up exception stopping the program/at least a given thread handling a request is a much better outcome then silent failure.

> poor quality messages

They get as high or low quality messages as one wants. I prefer a proper stacktrace with line numbers over a single obscure line I might occasionally be able to debug by grepping a code base.

Re: Major standard library changes in Go 1.20

#177

Post by Olreich »

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?

You don’t even solve the problem by moving the memory on-die, as the majority of time is not spent sending the signal on traces, it’s waiting for the relatively slow memory to find, read, and send the data on the bus.

Expanding the cache so everything fits in it is one way to achieve the performance uplift of cache hits, but cache is expensive compared to memory, and current cache sizes are tiny compared to RAM. If cache gets 50x bigger tomorrow, chips will get at least 10x as hot, power-hungry, and expensive.

Re: Major standard library changes in Go 1.20

#178

Post by doctor_eval »

hknmtt wrote: post #171
doctor_eval wrote: post #168

Earlier quoted context omitted.

> even talking about interfaces like "magic methods" No, this was referring to a mechanism used in the stdlib to see if an object passed in as one interface type, could be coerced to another interface type in order to perform some operation more efficiently. I’m a Go developer, and I didn’t know this happened, it’s basically not visible from the API function signatures, you have to look at the implementation. I love…

there is nothing wrong with asking if provided object is more capable than it seems so we can perform more efficient logic on it. that has nothing to do with magic methods, numbers... no magic whatsoever. "magic" in code refers to usually hidden and/or fixed behavior. this is not even in the same ballpark.

> there is nothing wrong with asking if provided object is more capable than it seems so we can perform more efficient logic on it.

There certainly is something wrong if you can’t see this in the API declaration.

Some Go stdlib calls declare that they accept one interface, but then test the passed in object against another, unrelated interface, which provides additional functionality.

Because the second interface is undeclared and hard coded, the functionality is hidden from the user, who has to somehow know about the inner workings of the API in order to benefit from it.

> "magic" in code refers to usually hidden and/or fixed behavior.

Which is exactly what is happening in this case.

Re: Major standard library changes in Go 1.20

#179

Post by tptacek »

threeseed wrote: post #56
tptacek wrote: post #21

Earlier quoted context omitted.

This is the same way of handling errors Go has always had. The point of Go errors is that they're just values; you program them like you would anything else. People have had multi-error packages for years, and Go encouraged it. Now there's a standard one.

[flagged]

This isn't responsive to the thread; it's just introducing a language-war argument at an opportune point. Please don't pick Go vs. other-language fights; they sprawl like kudzu and take over the entire thread, as you can see here. This wasn't a comment about whether exceptions are better or worse than error values, but now there's a really dumb flame war about that below.

Re: Major standard library changes in Go 1.20

#180

Post by simiones »

philosopher1234 wrote: post #153
simiones wrote: post #147

Earlier quoted context omitted.

Given that it was only added in Java 18 and it is a simple static file server (no way to run custom code when serving a URL), I don't think it's in any way widely used at the moment. Edit: or will ever be. It is definitely explicitly not an equivalent of go's net/http. Indeed, there is probably never going to be an equivalent of net/http in the Java stdlib (since they prefer to rely on the user choosing one of the ex…

From your description it sounds like it is a completely different beast from net/http

Yes, per the JEP that was linked, it is only intended as a toy server for quick example code, essentially:

> Provide a command-line tool to start a minimal web server that serves static files only. No CGI or servlet-like functionality is available. This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts.

> It is not a goal to provide a feature-rich or commercial-grade server. Far better alternatives exist in the form of server frameworks (e.g., Jetty, Netty, and Grizzly) and production servers (e.g., Apache Tomcat, Apache httpd, and NGINX).

Post reply on HN