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

131–140 of 265 posts

Re: Major standard library changes in Go 1.20

#131

Post by vultour »

SergeAx wrote: post #116
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…

What's wrong with Python that you want an alternative?

Dynamic typing. Dealing with structured data and (de)serialisation was a major pain. To me Go feels like a stricter python, still having enough freedom to do most things relatively easily, but not having to worry about what's being passed around.

Re: Major standard library changes in Go 1.20

#132

Post by the-smug-one »

heywhatupboys wrote: post #120
jchw wrote: post #41

Earlier quoted context omitted.

I mean, it's opt-in. If you really want to crap your pants, in today's Go, you can import C and call malloc and free, then import unsafe and make pointers into the void. The point of memory safe programming languages is NOT that they entirely disallow all unsafe operations, it's that the language has a proper model for memory safety. In Rust, unsafe code needs to be in unsafe blocks. In Go, unsafe code is only possib…

> In Go, unsafe code is only possible by importing unsafe or C. of course, this is completely wrong, for anyone reading this. that is simply not how systems work

OK, do you intend to say why?

Re: Major standard library changes in Go 1.20

#133

Post by varispeed »

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…

If I needed some admin interface etc I'd use Django and then everything else I'd write in Go. There were occasions where I'd write a service in Python and then rewrite it in Go. Never found that I needed something and it was lacking in the standard library. It's very fine experience. Then what I like the most is Go is extremely reliable. I had Go services running with a couple of years uptime, flawless.

Re: Major standard library changes in Go 1.20

#134

Post by 7to2 »

SergeAx wrote: post #116
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…

What's wrong with Python that you want an alternative?

I desperately miss static typing.

Re: Major standard library changes in Go 1.20

#135

Post by thiht »

SergeAx wrote: post #116
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…

What's wrong with Python that you want an alternative?

Dynamic Typing, Dependency management, Bundling, Speed

Re: Major standard library changes in Go 1.20

#136

Post by thiht »

heywhatupboys wrote: post #120
jchw wrote: post #41

Earlier quoted context omitted.

I mean, it's opt-in. If you really want to crap your pants, in today's Go, you can import C and call malloc and free, then import unsafe and make pointers into the void. The point of memory safe programming languages is NOT that they entirely disallow all unsafe operations, it's that the language has a proper model for memory safety. In Rust, unsafe code needs to be in unsafe blocks. In Go, unsafe code is only possib…

> In Go, unsafe code is only possible by importing unsafe or C. of course, this is completely wrong, for anyone reading this. that is simply not how systems work

How do "systems" (whatever you're talking about) work then?

Re: Major standard library changes in Go 1.20

#137

Post by nine_k »

mjburgess wrote: post #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,…

APL-like array-oriented languages can shine here. And do not complain about syntax; think numpy or pandas instead.

Re: Major standard library changes in Go 1.20

#138

Post by rob74 »

fancybouncy wrote: post #112
dzikimarian wrote: post #105

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.

This is what the documentation has to say about it:

> These are predefined layouts for use in Time.Format and time.Parse. The reference time used in these layouts is the specific time stamp:

01/02 03:04:05PM '06 -0700 (January 2, 15:04:05, 2006, in time zone seven hours west of GMT). That value is recorded as the constant named Layout, listed below. As a Unix time, this is 1136239445. Since MST is GMT-0700, the reference would be printed by the Unix date command as:

Mon Jan 2 15:04:05 MST 2006 It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day.

Using the American convention is regrettable, but putting the year after the time is even more regrettable IMHO. Not sure which timestamp format does that? Plan 9?

Re: Major standard library changes in Go 1.20

#139

Post by stickupkid »

eptcyka wrote: post #114
klodolph wrote: post #73

Earlier quoted context omitted.

If you want network buffers in Go, you can just use []byte. The Go GC is designed to make this work well, so nobody in Go is asking for a separate buffer type like you have in Java. In Java you have Buffer in the first place because there are good reasons why you might not want to use byte[]. Unboxed C types in Go can be done with cgo (it's not necessarily pleasant, but it works).

Why do Go enthusiasts look at types that specialize more generic data structures to ensure invariants and scoff? Maybe go only ever needed []byte, and nothing else - it's always just bytes anyway, right? Moreover, when the go team accomplishes the same goals by extending the language instead of using a library, this is well received.

Specifically to the arena, this required integration with the GC, so couldn't be done as an external library. Hence why a language spec was required.

Re: Major standard library changes in Go 1.20

#140

Post by _old_dude_ »

klodolph wrote: post #73
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…

If you want network buffers in Go, you can just use []byte. The Go GC is designed to make this work well, so nobody in Go is asking for a separate buffer type like you have in Java. In Java you have Buffer in the first place because there are good reasons why you might not want to use byte[]. Unboxed C types in Go can be done with cgo (it's not necessarily pleasant, but it works).

yes, Java/C# GCs (Android included) and Go GC are very different beasts.

Go GC does not move objects in memory (mark and sweep) while other GCs (mark and compact) do, to avoid heap fragmentation and better throughput (see generational GCs).

One issue with mark and compact GCs is that you can not move the array of bytes during a system call. A ByteBuffer/Memory object, is an object that allocates its byte arrays using malloc, outside of the heap, so the bytes are not moved by the GC.

Post reply on HN