Major standard library changes in Go 1.20 • Hacker News Board

Re: Major standard library changes in Go 1.20

#261

Post by simiones » Wed, Jan 18, 2023, 3:39 PM UTC

dmux wrote: post #248

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…

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...

Cool, I had no idea about this.

I see it's still available after the modularization effort, and it is:

https://docs.oracle.com/en/java/javase/18/docs/api/jdk.https...

Re: Major standard library changes in Go 1.20

#262

Post by [deleted] » Wed, Jan 18, 2023, 4:06 PM UTC

logicallee wrote: post #251

smoldesu wrote: post #241

Earlier quoted context omitted.

> 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.

Consider what would happen if you did ask it to think about a treatment for cancer and got real results. Clearly you would think it is just summarizing papers it read. That makes sense, since it is not a cancer researcher. So I'm way more impressed by ChatGPT than that. Even if it correctly data-mined and answered the question, it would not be that impressive. That's right: getting a cure from cancer when you ask is…

[deleted]

Re: Major standard library changes in Go 1.20

#263

Post by kervantas » Wed, Jan 18, 2023, 6:51 PM UTC

dgb23 wrote: post #162

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…

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.

> with routing Don't you need some 3rd party lib for that (if you don't want to implement your own router)?

Re: Major standard library changes in Go 1.20

#264

Post by mknyszek » Wed, Jan 18, 2023, 6:56 PM UTC

cormacrelf wrote: post #245

mknyszek wrote: post #243

Earlier quoted context omitted.

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

> 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.

It doesn't allocate at the start of the chunk, it just picks up wherever the last one left off. That allocated memory in the chunk from previous arena allocations is not reused until the chunk as a whole is unmapped and the GC can confirm that no more pointers point into that chunk's address space (if you leave a dangling pointer, you only waste address space). This points-into property is cheap to check, it's equivalent to whether the chunk has been marked by the GC.

Again, I think that MSAN/ASAN should probably just be more strict with these kinds of use-after-frees. You won't crash, but it's still technically incorrect. (Not much can be done about the "GC is in the mark phase" case, unfortunately. Otherwise MSAN/ASAN will complain when the GC inevitably tries to access a pointer into a delayed chunk.)

Re: Major standard library changes in Go 1.20

#265

Post by yencabulator » Wed, Jan 18, 2023, 8:40 PM UTC

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

Hell, I'll argue Go standard library is more extensive and better than Python's. Case in point: HTTP. The batteries included in Python definitely reflect the era of their creation.