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

Go 1.17 Release Notes

golang.org

Post reply on HN
Print view View original

61–70 of 222 posts

Re: Go 1.17 Release Notes

#61

Post by barsonme »

ridiculous_fish wrote: post #58
avl999 wrote: post #26

Go is my favorite language to write code in. I was very skeptical when I first started learning it for a new job with error handling that looked archaic in comparison to exceptions but once I got the hang of it it has quickly become my preferred language of choice for any project. Once generics are finally added the language should basically be a no-brainer for any serious production code.

From a distance it looks difficult to write in. For example, two recommended ways to delete from a slice: a = append(a[:i], a[i+1:]...) // or a = a[:i+copy(a[i:], a[i+1:])] Both seem harder than necessary. Is that code just idiomatic, and Go programmers recognize it instantly? Or maybe they don't deal with slices that often? https://github.com/golang/go/wiki/SliceTricks

No, you deal with slices all the time. You just recognize the idiom.

You can restructure it if you don't need to preserve order:

    a[i] = a[len(a)-1] 
    a = a[:len(a)-1]
In general* Go does not hide complexity from you. It's a blessing and a curse.

*: because the Internet is a nitpicky place.

Re: Go 1.17 Release Notes

#62

Post by benhoyt »

barsonme wrote: post #59
benhoyt wrote: post #46

Earlier quoted context omitted.

Wow, this update is awesome: my GoAWK interpreter ( https://github.com/benhoyt/goawk ) runs a simple CPU-bound AWK program 38% faster when compiled with Go 1.17 (compared to 1.16). $ time goawk_go1.16 'BEGIN { for (i=0; i I wonder why it's so much better than their advertised 5% perf improvement? Here's a quick CPU profile: https://i.imgur.com/csJyOYq.png ... I don't get too much out of it at a glance, just seems lik…

just an fyi: you can use the -diff_base flag to diff the profiles without opening both profiles side-by-side.

Oh, good to know, thanks!

Re: Go 1.17 Release Notes

#63

Post by prattmic »

benhoyt wrote: post #46
benhoyt wrote: post #29

To me, the most interesting change is the performance improvement due to the new register-based calling convention. Your CPU-bound programs will magically get 5% faster when compiled with 1.17: > Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. Benchmarks for a representative set of Go packages and programs show performance improvements of about 5%, and a ty…

Wow, this update is awesome: my GoAWK interpreter ( https://github.com/benhoyt/goawk ) runs a simple CPU-bound AWK program 38% faster when compiled with Go 1.17 (compared to 1.16). $ time goawk_go1.16 'BEGIN { for (i=0; i I wonder why it's so much better than their advertised 5% perf improvement? Here's a quick CPU profile: https://i.imgur.com/csJyOYq.png ... I don't get too much out of it at a glance, just seems lik…

The benefits come primarily from avoiding extra work spilling arguments to/from the stack on function calls. If you are making lots and lots of function calls, particularly to small functions that can't be inlined, there could certainly be much bigger improvements.

Re: Go 1.17 Release Notes

#64

Post by hakube »

How do you add dependencies and in Go? I'm still confused. I use the VSCode extension and the code I wrote that uses external packages gets deleted when I save my file even though the package is installed

Re: Go 1.17 Release Notes

#65

Post by dilyevsky »

atombender wrote: post #55
dilyevsky wrote: post #39

Earlier quoted context omitted.

Python/Js are interpreted by default and not good system programming choices. Go is compiled. This comparison totally misses the mark. In fact Go was developed mostly as C++ but sometimes Python replacement at Google.

And yet Go seems to have not captured many C++ developers, but rather developers from languages like Python, Ruby, and JavaScript. The Go team originally wanted to replace C++, especially inside Google, but they didn't succeed. According to googlers on Hacker News, very few projects inside Google actually use Go. The reason Go attracted these kinds of developers is precisely that it isn't a systems programming langua…

It def convinced me. I wrote c++ for almost 10 year before switching to Go. Even after c++11 have come out it was still night and day. Anecdotally the team i left at google rewrote some of my stuff from c++ in Go that I didn’t get to at the time

Re: Go 1.17 Release Notes

#66

Post by munificent »

37ef_ced3 wrote: post #53
DenseComet wrote: post #36

Earlier quoted context omitted.

Go isn't low level in the same way that Rust is. Both languages have their places, but Go seems to be more of a better Python/JS, whereas Rust is a better C++.

Go should be understood as a replacement for C and C++. If you're writing a compiler, or some other project where extreme high performance is not necessary (e.g., if you're willing to be, say, a factor of 2 slower than C) then Go is a good choice. Go's performance is excellent, and should be sufficient for all but the most demanding applications. It's not a crummy scripting language like Python/JS.

> Go should be understood as a replacement for C and C++.

I think Go is a good replacement for the things people used C and C++ for twenty years ago, but less of a replacement for the things people use C and C++ for today.

Back then, C/C++ was your default "write big server program that needs to go relatively fast" language, and Go is targeting that. But in the meantime, Java got fast enough and hardware got cheap enough that Python, Ruby, and JavaScript have also eaten into that domain.

Today, I see C and C++ used primarily for embedded work and games. I don't see Go as being a great fit for either of those.

Re: Go 1.17 Release Notes

#67

Post by zarzavat »

37ef_ced3 wrote: post #53
DenseComet wrote: post #36

Earlier quoted context omitted.

Go isn't low level in the same way that Rust is. Both languages have their places, but Go seems to be more of a better Python/JS, whereas Rust is a better C++.

Go should be understood as a replacement for C and C++. If you're writing a compiler, or some other project where extreme high performance is not necessary (e.g., if you're willing to be, say, a factor of 2 slower than C) then Go is a good choice. Go's performance is excellent, and should be sufficient for all but the most demanding applications. It's not a crummy scripting language like Python/JS.

Go is a replacement for a certain subset of C/C++ projects that are I/O heavy, e.g. web servers. However the GC precludes it from many uses of C/C++, e.g. you couldn't write an AAA game in it, or a kernel, or a toaster.

Re: Go 1.17 Release Notes

#68

Post by galleywest »

hakube wrote: post #64

How do you add dependencies and in Go? I'm still confused. I use the VSCode extension and the code I wrote that uses external packages gets deleted when I save my file even though the package is installed

Are you using the imports in your file? The VS Code Go addon has "format on save" enabled by default and Go will not compile if there are unused imports - so VS Code deletes the unused imports on save by default.

Otherwise try a "go mod init" in the root of your project.

Re: Go 1.17 Release Notes

#69

Post by josephg »

throwaway894345 wrote: post #48
throw149102 wrote: post #30

I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a garbage collector in Rust.

I really like Rust, but in my mind it's still relegated to the periphery of tasks that must be super fast (like C/C++, to your point) and/or low-level. Rust has made impressive strides at reducing the toil involved in compile-time memory management, but there is still a big productivity gap between the borrow checker and GC. Frankly, people are making boatloads of money off of software written in Python and JS--langu…

> In this world, most errors are silly type errors

I can’t speak to python, but typescript has basically fixed this problem overnight in the javascript ecosystem. The typescript compiler finds almost all small bugs like this while I’m coding. And as an added bonus, type hints allow the IDE to be much more helpful - adding to jump to function support, autocomplete, method parameter suggestions (or documentation on hover). And typescript is easier to read than javascript because you don’t have to guess what data type some variable is.

I love javascript’s quick and dirty nature, but I still use typescript instead of javascript now for any code I write that I expect to survive the week. (And as a bonus: you still get IDE type hints when calling typescript functions from raw javascript!)

Typescript’s type system is also more powerful than Go’s. It supports enums, genetics and type unions (eg x: string | number).

Go sits in the awkward place of having a worse type system and no significant advantages over typescript for me. It’s awkward to use go on the web. Go is faster than javascript on the server but that usually doesn’t matter. And when it does I can reach for C or Rust. Both of which work really well with native code, or with JS through wasm.

Rust is much harder to learn than Go - but personally I’ve climbed that hill already. Once you’re over that hill, Rust is much more expressive. On purpose both ways - go isn’t trying to be expressive, and rust is. I love rust’s parametric enums and output types in traits. Which I now sorely miss in other languages.

I can imagine Go shining a lot more brightly when working with a team which has mixed skill levels. Most of my work lately has been solo, so I don’t need gofmt to enforce a consistent code style, or anything like that. I do miss Go’s green threads. Rust’s afterthought scattergun approach with threads and futures feels like a mess. But I can’t see myself ever really using Go. It’s weak in areas I want it to be strong (eg the type system). And strong in areas I just don’t care much about. (Eg consistency).

Re: Go 1.17 Release Notes

#70

Post by benhoyt »

ridiculous_fish wrote: post #58
avl999 wrote: post #26

Go is my favorite language to write code in. I was very skeptical when I first started learning it for a new job with error handling that looked archaic in comparison to exceptions but once I got the hang of it it has quickly become my preferred language of choice for any project. Once generics are finally added the language should basically be a no-brainer for any serious production code.

From a distance it looks difficult to write in. For example, two recommended ways to delete from a slice: a = append(a[:i], a[i+1:]...) // or a = a[:i+copy(a[i:], a[i+1:])] Both seem harder than necessary. Is that code just idiomatic, and Go programmers recognize it instantly? Or maybe they don't deal with slices that often? https://github.com/golang/go/wiki/SliceTricks

With the introduction of generics in Go 1.18 and the accompanying "slices" package (https://github.com/golang/go/issues/45955), we might soon write that as:

  a = slices.Delete(a, i, i+1)
That said, in code I write, I rarely need to do an in-place delete from a slice. I think it's rare enough that recognizing the idiom is okay.
Post reply on HN