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

241–250 of 265 posts

Re: Major standard library changes in Go 1.20

#241

Post by smoldesu »

logicallee wrote: post #206
xvector wrote: post #40

Earlier quoted context omitted.

It's plainly obvious to me that ChatGPT is engaging in some form of thought. Perhaps not human thought, but thought nonetheless.

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.

Re: Major standard library changes in Go 1.20

#242

Post by metaltyphoon »

bit_flipper wrote: post #83
7to2 wrote: 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

Go probably pales in comparison to .NET [0]. Its about 1 million APIs

[0] https://apisof.net/

Re: Major standard library changes in Go 1.20

#243

Post by mknyszek »

cormacrelf wrote: post #44
slimsag wrote: post #29

Earlier quoted context omitted.

> now you're just going to do it? "you can’t import it by default", "you probably shouldn’t be using it at all", "experimental arena package", and 'you must opt-in to even be able to use it via an GOEXPERIMENT environment variable' As for screams from Rust/Go people about how bad C is, it said: > This is highly efficient, but also highly dangerous. What if the programmer makes a mistake [...] > > To mitigate the risk…

> and goes on to explain that each arena has its own unique/distinct address space That does not seem to be how it is implemented now. Try the example use-after-free on https://uptrace.dev/blog/posts/go-memory-arena.html under 'Address Sanitizer'. There is no error at all when you dereference, it silently keeps working as freed pointers often do (until they don't). Maybe they will add the virtual address space thing…

The functionality to poison the address space is there, and it does work.

What you're encountering is one of two exceptions in the implementation where you might not get an immediate failure:

1. If you use only a very small amount of an arena chunk and free it, it goes back on a reuse list as an optimization. Accessing that chunk's memory, despite the fact that the arena was freed, is entirely memory safe: nothing else will use that memory. That address space will be properly poisoned once the arena chunk is full, or close to it. 2. If the GC is actively marking, arena chunk poisoning is delayed to avoid races with the GC that might cause it to dereference a pointer into poisoned memory. The arena chunk is poisoned as soon as the GC is done.

The API explicitly does not guarantee a crash on use-after-free[1] because the Go team wanted a valid implementation of arenas to be simply "new" for New and noop for Free. The point is to just stay memory safe and have a high probability of catching an issue _in production_ where presumably arenas are filled up (otherwise why are you using arenas?).

Edit: arguably that optimization should just be turned off for MSAN/ASAN mode for greater user-friendliness, which seems reasonable. I think that was just an oversight.

[1]: https://cs.opensource.google/go/go/+/master:src/arena/arena....

Re: Major standard library changes in Go 1.20

#244

Post by metaltyphoon »

jaitsu wrote: post #209
dgb23 wrote: post #162

Earlier quoted context omitted.

It’s extensive, web server focused, ergonomic and has well documented and sensible security defaults. In Go you can write a production ready, well tested, _concurrent_ web application with routing, auth, sql storage, html templating, image optimization, and so on without fetching third party libraries. And you’re not leaving official docs for it.

Almost. The sql package is just an abstract layer which requires a 3rd party module to provide the concretions. I guess the API is the same, but you still need a 3rd party lib :)

Most people don’t use the flags package either and opt for 3rd party, like cobra.

Re: Major standard library changes in Go 1.20

#245

Post by cormacrelf »

mknyszek wrote: post #243
cormacrelf wrote: post #44

Earlier quoted context omitted.

> and goes on to explain that each arena has its own unique/distinct address space That does not seem to be how it is implemented now. Try the example use-after-free on https://uptrace.dev/blog/posts/go-memory-arena.html under 'Address Sanitizer'. There is no error at all when you dereference, it silently keeps working as freed pointers often do (until they don't). Maybe they will add the virtual address space thing…

The functionality to poison the address space is there, and it does work. What you're encountering is one of two exceptions in the implementation where you might not get an immediate failure: 1. If you use only a very small amount of an arena chunk and free it, it goes back on a reuse list as an optimization. Accessing that chunk's memory, despite the fact that the arena was freed, is entirely memory safe: nothing el…

> If you use only a very small amount of an arena chunk and free it, it goes back on a reuse list as an optimization. Accessing that chunk's memory, despite the fact that the arena was freed, is entirely memory safe: nothing else will use that memory.

I still have a pointer into the chunk. If you reuse the chunk in a different arena, I still have a pointer into the chunk. At no point is it invalidated, and the new arena will now start allocating new stuff from the start of the chunk. Right? And my old pointer still works, and the data inside it is at some point overwritten. How is that memory safe?

Are you eventually unmapping the virtual address space and remapping the underlying allocation somewhere else? So the poisoning happens when the chunk is picked up for reuse by a new arena?

Re: Major standard library changes in Go 1.20

#246

Post by Groxx »

Joker_vD wrote: post #127
Groxx wrote: post #87

Earlier quoted context omitted.

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.

yeah, the inconsistency there in both standard libraries is... strange to say the least. more info is more gooder IMO, the runtime cost is SO much lower than the troubleshooting cost.

Re: Major standard library changes in Go 1.20

#247

Post by dmux »

derkades wrote: post #123
kaba0 wrote: 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.

Java has had a basic http server built in since 1.6

https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver...

Re: Major standard library changes in Go 1.20

#248

Post by dmux »

simiones wrote: post #147
philosopher1234 wrote: post #145

Earlier quoted context omitted.

Does anyone actually use it? I’ve never even heard of this thing and I’m a professional Java dev

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…

The specific web server in the JEP is relatively new, but there has been an http server implementaion since 1.6:

https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver...

Re: Major standard library changes in Go 1.20

#249

Post by maurice2k »

maurice2k wrote: post #198
bogeholm wrote: post #150

Earlier quoted context omitted.

> Rust had a lot community content, but not a comprehensive stdlib; last checked 3-4 years ago Still the case now (depending on your definition of ‘comprehensive’ of course). It’s an explicit non-goal of Rust to include “everything” (eg. http, crypto, random numbers) in std because of the stability promises - you can’t make breaking changes to std unless you’re fixing a soundness issue AFAIR.

I was evaluating Rust for some cryptography use case and there were only "random" community libs available that lacked support here and there. And I actually had no trust in any of those libs. A stdlib must not contain everything but a solid cryptography lib is probably a good idea.

Looks like the situation improved a bit: https://cryptography.rs/

I would still like to have a more comprehensive or high level stdlib for Rust that is maintained by a core Rust team.

Re: Major standard library changes in Go 1.20

#250

Post by pjmlp »

doctor_eval wrote: post #240
pjmlp wrote: post #239

Earlier quoted context omitted.

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

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.

Post reply on HN