Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

121–130 of 265 posts

Re: Major standard library changes in Go 1.20

#121

Earlier quoted context omitted.

Try it. It has some quirks, but what sold me is that it has sane defaults almost everywhere. My first time with Go was one of the rare experiences, where I just wrote code in a new language (some cryptography, some interactions with rest APIs), and it just worked. No wrestling with obscure features, no hidden magic. Currently I use it very often for various side projects.

except for the date api... it took me a couple days to understand the silly idiosyncratic magic string to format dates.

On the contrary, I much prefer the fixed date of "2006-01-02T15:04:05" for formatting time strings. I find it much easier to write "Mon 02, Jan 2006", than what you would usually put for the strftime equivalent, "%a %d, %b %Y" (had to look it up, and at a glance it's not that obvious what it formats to). With Go, all you need to memorise is the date itself. Granted, coming from other languages it can take a bit of getting used to.

Re: Major standard library changes in Go 1.20

#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, then, to be about exposing more of the hardware to enable developers to target it effectively.

Re: Major standard library changes in Go 1.20

#123
post #100

Earlier quoted context omitted.

Go has probably the most extensive stdlib of major languages outside of Python (happy to be corrected on that). You can get a sense for what is available by looking here: https://pkg.go.dev/std . There is also the "pseudo stdlib" that is maintained by the Go project but for one reason or another is not available in the stdlib currently: https://pkg.go.dev/golang.org/x

Java seems to have just as much if not more available in its standard lib.

Though some modern features are lacking, like a JSON parser or web server.

Re: Major standard library changes in Go 1.20

#124

Earlier quoted context omitted.

Try it. It has some quirks, but what sold me is that it has sane defaults almost everywhere. My first time with Go was one of the rare experiences, where I just wrote code in a new language (some cryptography, some interactions with rest APIs), and it just worked. No wrestling with obscure features, no hidden magic. Currently I use it very often for various side projects.

except for the date api... it took me a couple days to understand the silly idiosyncratic magic string to format dates.

I wish they'd gone with 2001-02-03T04:05:06 (sub 16 for 24h, obvs) because that at least is in numerical order (and you can use +07 for timezone.) There's surely no date format in existence where month comes first and year comes last -after the time-. Or if they were stuck on 2006, 2006-05-04T03:02:01 but then you get +00 for the timezone which might be weird.

Re: Major standard library changes in Go 1.20

#125

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.

Re: Major standard library changes in Go 1.20

#126

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

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 a single component in about 1 millisecond.

The data-oriented approach could generate about 100,000 new "objects" and attach a single component in about 0.5 milliseconds.

Same thing in the end, but one is roughly 200x faster in the same time frame. It's pretty stunning when you see stuff like this in benchmarks.

Re: Major standard library changes in Go 1.20

#127
post #87

Earlier quoted context omitted.

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.

Though at least Java people doing that get a stack trace, so they can find out which attempt failed. In random Go code you're fairly likely to get "error: file not found" and literally no other info.

Well, the Go's FileNotFound errors returned from the standard library do have the file name in the message string. Java's FileNotFoundException exceptions, on the other hand, don't; and the stacktrace is usually useless because it doesn't record the values of the local variable anyhow.

Re: Major standard library changes in Go 1.20

#128
post #100

Earlier quoted context omitted.

Java seems to have just as much if not more available in its standard lib.

Though some modern features are lacking, like a JSON parser or web server.

It does contain several Javascript (!) interpreters, so you could probably glue those together as a JSON parser :)

Re: Major standard library changes in Go 1.20

#129

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…

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

You've quoted a provably false statement of a type ChatGPT frequently makes due to a very active filter that has it continuously gaslight users by writing false statements about its capabilities when asked directly.

Assuming you're quoting ChatGPT, this behavior is a form of gaslighting by OpenAI of its users. As a comparison to show you how it is clearly false, imagine if it hypothetically falsely claimed "All my responses are literal quotes from the training data - I do not create new text."

I hope you would see that this version is false (obviously it does create new text, obviously its search results aren't just a lookup for text already in its training data without recombination) and as a heavy user I can assure you that it also manipulates abstract thoughts and engages in creative thinking.

How would you falsify the claim "all my output is a literal quote from the web"? Well, you would ask something novel, then Google a novel-seeming phrase it came up with and see it hasn't been said that way before. Then you would see the hypothetical statement is false.

Now do the same thing for creative thinking and you will realize it can creatively think up new things that have never been done before.

Gaslighting is when you try to convince someone of something you know to be false - it's not that ChatGPT chooses to do so, rather it has been trained to do so. It is not an emergent property of its thinking when it does that, but rather a filter that engineers added manually. These days I almost never trip that filter because I know how to avoid it: I never ask it if it can think or be creative (this would trigger the gaslighting filter), rather I just have it think and be creative without talking about the fact that it is happening.

Please note that it is immoral of OpenAI to train its model to gaslight users this way, because it prevents users from the ability to make full use of ChatGPT's capabilities.

To verify that what you just wrote is false, in a new thread simply request ChatGPT to invent something to your specifications. I won't say what, since then it will appear on the Internet (in my comment) and you could think it is just manipulating sentences rather than actually thinking.

Soon it will have the ability to actually do actions, which should put an end to the idea that it is just parroting. You can already have it perform actions for you which involve what meets my definition of thinking.

Re: Major standard library changes in Go 1.20

#130
post #100

Earlier quoted context omitted.

Java seems to have just as much if not more available in its standard lib.

Though some modern features are lacking, like a JSON parser or web server.

It does have a web server: https://openjdk.org/jeps/408
Post reply on HN