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.
Major standard library changes in Go 1.20
181–190 of 265 posts
Re: Major standard library changes in Go 1.20
#182Earlier 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…
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
#183The 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,…
Re: Major standard library changes in Go 1.20
#184Earlier 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.
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
#185How 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
Re: Major standard library changes in Go 1.20
#186Earlier 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.
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
#187Earlier 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.
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
#188Earlier 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.”
Re: Major standard library changes in Go 1.20
#189[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.
Re: Major standard library changes in Go 1.20
#190Earlier 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.