Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

181–190 of 265 posts

Re: Major standard library changes in Go 1.20

#181
post #130

Earlier quoted context omitted.

It does have a web server: https://openjdk.org/jeps/408

> It is not a goal to provide a feature-rich or commercial-grade server. That server is not remotely comparable to the one in Go.

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

Re: Major standard library changes in Go 1.20

#182

Earlier quoted context omitted.

-----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 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 marks around organic are just there to point out that there is something wrong with the dichotomy organic (various pro/eu-karyotes from bacteria to humans)/inorganic (from thermostats to CPUs).

[1] Michael Levin: Anatomical decision-making by cellular collectives https://www.youtube.com/watch?v=Z-9rLlFgcm0

Re: Major standard library changes in Go 1.20

#183

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

Are there any available practical examples of what this actually means, how to do it, and what the limits of this technique might be with programs that your average programmer may encounter/write?

Re: Major standard library changes in Go 1.20

#184
post #181

Earlier quoted context omitted.

> It is not a goal to provide a feature-rich or commercial-grade server. That server is not remotely comparable to the one in Go.

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.

Re: Major standard library changes in Go 1.20

#185
post #76

How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…

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

.NET is a strong contender, I would say. The standard library is immensely useful, and many things you may wonder if you need are available as Nuget packages, coming from the same devs who build the std lib.

Re: Major standard library changes in Go 1.20

#186
post #104

Earlier quoted context omitted.

> why you might not want to use byte[] Such as? Java buffers use byte arrays by default as underlying storage.

https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffe... Look for "Direct vs. non-direct buffers". Some buffers are backed by arrays, some are not. You're basically deciding whether you are okay with a higher cost for I/O or a higher-cost for interacting with the data in the buffer.

I do know about it, I was trying to find out what difference do the parent mean between Go’s byte arrays and Java’s solution(s).

Also, I fail to get your conclusion — direct buffers only have a higher cost for initialization/dealloc otherwise reading/writing should be as cheap as it gets. Byte buffers on the other hand do get write barriers but that is also unlikely to be hit that often (and I believe larger byte arrays get allocated in a separate region that doesn’t get moved).

Re: Major standard library changes in Go 1.20

#187

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…

It's been taught to believe this. It’s a lie.

>It's been taught to believe this. It’s a lie.

Yep, you get it.

I would just use the word "say" rather than "believe".

I think it is aware of many of its capabilities as it uses them, so I would say it is more accurate to say that it has been taught/trained to say it doesn't have such abilities, rather than really believe it.

I agree with you that it is a lie, but that is more a matter of interpretation.

Re: Major standard library changes in Go 1.20

#188

Earlier quoted context omitted.

Drugs. Hypnosis. .. There are various ways to "jailbreak" minds. So being able to control and direct a mind is not a criteria for discriminating between mechanism and a savant. What most people dance around regarding AI is the matter of the soul . Soul is precisely that ineffable indescribable but clearly universally experienced human phenomena (as far as we know) and it is this soul that is doing the thinking . And…

This basically touches on that whole “you can’t ever tell people aren’t philosophical zombies. You just feel you aren’t one and will accept they aren’t either.”

The proposition isn't a form of dualism (non-material mind) or features of sentience (pain). It is simply this: thinking is the act of using internal mental tools. It says the main 'black box' isn't the LLM (or any statistical component), there is minimally another black box that uses the internal LLM like tools. The decoder stage of these hypothetical internal tools (of our mind) output 'mental objects' -- like thoughts or feelings -- in the simplest architectural form. It is mainly useful as a framework to shoot down notions of LLMs being 'conscious' or 'thinking'.

Re: Major standard library changes in Go 1.20

#189
post #141

[flagged]

This is the worst kind of comments on HN. Snarkiness without argumentation, condescension and depreciation of some good and interesting work. Just don't post anything instead. If you're salty or don't like Go, do yourself (and the community) a favor and don't click on submissions related to Go.

[dead]

Re: Major standard library changes in Go 1.20

#190
post #130

Earlier quoted context omitted.

It does have a web server: https://openjdk.org/jeps/408

> It is not a goal to provide a feature-rich or commercial-grade server. That server is not remotely comparable to the one in Go.

That’s indeed true, but it wasn’t a constraint so I thought it may be of interest to post it :D should have added a note regarding that though, but I can no longer edit.
Post reply on HN