Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.13 Release Notes

golang.org

Post reply on HN
Print view View original

221–230 of 264 posts

Re: Go 1.13 Release Notes

#221

Post by majewsky »

ngrilly wrote: post #112
pcwalton wrote: post #108

Earlier quoted context omitted.

The features that each language offers are the same: threads, channels, and blocking I/O (though Rust has more features for safe concurrency--Rust prevents data races statically, while Go is not even memory safe in the presence of such races). What is different is the performance characteristics. In some cases, M:N will be more efficient; in some cases, 1:1 will be. But just as I wouldn't say Go is lacking FFI featur…

> blocking I/O Rust I/O are strictly similar to Go when using 1:1 OS threading, but become conceptually different when using async/await. > Rust has more features for safe concurrency--Rust prevents data races statically, while Go is not even memory safe in the presence of such races Agreed. That's a big advantage of Rust. > What is different is the performance characteristics. Performance is a feature. It's signific…

> The main advantage of the M:N model, compared to the 1:1 model, is the memory usage, because each goroutine starts with a small stack (a few kB).

Rust's async-fns compile into state machines, so they only allocate exactly the number of bytes that they need.

Re: Go 1.13 Release Notes

#222

Post by zubspace »

masklinn wrote: post #194
zubspace wrote: post #25

I actually just started to use go on windows just to check it out. First impressions from a newbie: - Getting started with go and vscode is kinda bad right now. I installed go, set up GOPATH, installed all kinds of extensions in vscode and then, somewhere down the official tutorial I learn about GO111MODULES, go mod init, vendor folders and the language server... I was completely confused and still am. I removed all…

> - Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird.. Without the : it means every assignment might be a declaration so you need a "declaration inference" system, and every language which does declaration inference has odd tradeoffs and corner cases e.g. implicit declaration in the local-most scope (Python), implicit method-wise non-local…

Your explanation makes sense. It would complicate the compiler in this regard.

It's funny, how many different answers I got. I guess, all those reasons combined justify :=

- Complicates compiler

- Prevents Typos

- Works well with err (also because of partial declarations)

- Variables can be shadowed inside a closure

Re: Go 1.13 Release Notes

#223

Post by bakery2k »

eptcyka wrote: post #207
nemo1618 wrote: post #86

Earlier quoted context omitted.

Strings are fixed-size, though. A string is a pointer and a length. It's true that you can't use a slice as a map key, though, even though slices are also fixed-size (pointer, length, and capacity). As I recall, the argument is that the equality rules for slices are unclear. (maps and funcs can't be used as keys either, for the same reason: they're not comparable.) Is a 0-length slice equal to a nil slice? Is a slice…

Would it be too hard to just compare arbitrary slices and arrays based on the contents of said data structures? Converting arbitrary bytes to strings should fail at least some times, since not all byte sequences are valid UTF-8, and afaiu, in Go, the string type should always contain valid UTF-8.

I thought strings in Go could contain arbitrary byte sequences?

Re: Go 1.13 Release Notes

#224

Post by bakery2k »

tapirl wrote: post #199
omaranto wrote: post #132

Earlier quoted context omitted.

Maybe "fixed size" was the wrong way to phrase it. What I meant is that a string points to an unlimited amount of data and all of that unlimited amount of data is taken into account when deciding equality of strings. And my question should have been, is string the only datatype with that feature? If it is, it means Go is like Lua, where if you want to use any compound data structure as a key in a map, you either mars…

> In Python you are allowed to use tuples of immutable objects as keys You can do this in Go too with structs.

Don't all the keys in a Go map have to have the same type? So if you use structs as keys, they all need to have the same length?

In Python, you can use (1, 2), (3, 4, 5) and (6, 7, 8, 9, 10) all as keys in the same map.

Re: Go 1.13 Release Notes

#225

Post by masklinn »

zubspace wrote: post #222
masklinn wrote: post #194

Earlier quoted context omitted.

> - Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird.. Without the : it means every assignment might be a declaration so you need a "declaration inference" system, and every language which does declaration inference has odd tradeoffs and corner cases e.g. implicit declaration in the local-most scope (Python), implicit method-wise non-local…

Your explanation makes sense. It would complicate the compiler in this regard. It's funny, how many different answers I got. I guess, all those reasons combined justify := - Complicates compiler - Prevents Typos - Works well with err (also because of partial declarations) - Variables can be shadowed inside a closure

> Your explanation makes sense. It would complicate the compiler in this regard.

The compiler part's easy, it's the meatpiler which gets into an odd funk when implicit declarations don't do the expected thing (which will eventually happen). Not having implicit declarations is much simpler and more straightforward for everyone involved.

I used to find implicit declarations NBD, but I've slowly soured on them (starting with CoffeeScript: I found its declaration inference decisions absolutely awful and that started me really thinking about implicit declarations, see http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffe... for more on the subject, or https://donatstudios.com/CoffeeScript-Madness for a more brutal take).

Re: Go 1.13 Release Notes

#226

Post by cesarb »

ithkuil wrote: post #190
cesarb wrote: post #168

Earlier quoted context omitted.

IMO, using an environment variable for that is not robust. If the environment variables have been cleared (for instance, due to "su -" or similar), or if they have never been set (for instance, because you just checked out the code on a new machine and forgot to configure the environment variables there, or because you did remember to configure the environment variables but forgot that startup scripts do not take eff…

go env -w allow you to configure your local go installation and set the default value of the config entry when the environment variable is not set. The config entries have the same name as environment variables.

From what I understood from the manual, the configuration stored by "go env -w" is per-machine (actually per-user), not per-repository. So if you checkout on a newly installed machine, and forget to do "go env -w" beforehand (from my experience, people forget even the "git config --global user.email", so it's not unlikely to forget the "go env -w"), you'll be using the defaults.

Re: Go 1.13 Release Notes

#227

Post by masklinn »

zubspace wrote: post #25

I actually just started to use go on windows just to check it out. First impressions from a newbie: - Getting started with go and vscode is kinda bad right now. I installed go, set up GOPATH, installed all kinds of extensions in vscode and then, somewhere down the official tutorial I learn about GO111MODULES, go mod init, vendor folders and the language server... I was completely confused and still am. I removed all…

> - The syntax is very weird after writing too much C#. Sometimes I have the feeling, that declarations are reversed just for the sake of it.

It's really C and languages directly derived from it which are the odd ones out. "postfix type" ordering dates back to at least Pascal, and is very common especially but not solely amongst languages with type inference.

Just look at what more direct C derivatives have to do to back-fill type inference: invent some weird-ass pseudo-type to take the type's place. I also think it maps better to how I read / write / think. "f is an integer", the definition of f is more relevant than its type.

> - I can parse 2GB of simple JSON files in less than 20s. I'm awed.

100MB/s doesn't seem that impressive? rapidjson or serde can do several times that, simdjson reaches 2GB/s.

Re: Go 1.13 Release Notes

#228

Post by ngrilly »

majewsky wrote: post #221
ngrilly wrote: post #112

Earlier quoted context omitted.

> blocking I/O Rust I/O are strictly similar to Go when using 1:1 OS threading, but become conceptually different when using async/await. > Rust has more features for safe concurrency--Rust prevents data races statically, while Go is not even memory safe in the presence of such races Agreed. That's a big advantage of Rust. > What is different is the performance characteristics. Performance is a feature. It's signific…

> The main advantage of the M:N model, compared to the 1:1 model, is the memory usage, because each goroutine starts with a small stack (a few kB). Rust's async-fns compile into state machines, so they only allocate exactly the number of bytes that they need.

I know. I was writing about the 1:1 model without async/await :)
Post reply on HN