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

81–90 of 222 posts

Re: Go 1.17 Release Notes

#81

Post by jrockway »

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

gopls seems to be integrating some of the "tricks" into editor completion. This one isn't there, but other idioms are. (With gopls > 0.7.0, it's enabled by default. Details: https://github.com/golang/tools/releases/tag/gopls%2Fv0.7.0)

Re: Go 1.17 Release Notes

#82

Post by jrockway »

cpeterso wrote: post #54
matthewmacleod wrote: post #32

A couple of nice tweaks that I'm happy to see. I didn't completely expect it, but I now find myself reaching for Go first when writing something like a small script or utility that I'd previously have written in something like Ruby or Python. It all feels much more solid. That said… I really chafe against the anaemic type system when writing anything a larger than that. I hate not being able to communicate things lik…

> the design decisions leading to the existence of `time.IsZero()` are bordering on criminal. What's the rationale for Time.IsZero()? Seems like every use case for Time.IsZero() I think of is a code smell. The 1970 epoch is an implementation detail that should be hidden or configurable. People probably use IsZero() as a sentinel value to indicate "undefined time", even though the 1970 epoch is a valid point in time.

Go's zero time is not at 1970. It's at year 1.

    // IsZero reports whether t represents the zero time instant,
    // January 1, year 1, 00:00:00 UTC.
    func (t Time) IsZero() bool {
            return t.sec() == 0 && t.nsec() == 0
    }

Re: Go 1.17 Release Notes

#83

Post by jrockway »

matthewmacleod wrote: post #32

A couple of nice tweaks that I'm happy to see. I didn't completely expect it, but I now find myself reaching for Go first when writing something like a small script or utility that I'd previously have written in something like Ruby or Python. It all feels much more solid. That said… I really chafe against the anaemic type system when writing anything a larger than that. I hate not being able to communicate things lik…

> I resent having to write three lines of boilerplate every time I want to reverse a slice.

Up above I talk about gopls's postfix completions, and reversing a slice is one: https://github.com/golang/tools/releases/tag/gopls%2Fv0.7.0

Re: Go 1.17 Release Notes

#84

Post by vp8989 »

zarzavat wrote: post #67
37ef_ced3 wrote: post #53

Earlier quoted context omitted.

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.

GC is quite problematic for web servers too. Lots of people "solve" that by giving AWS more money.

Re: Go 1.17 Release Notes

#85

Post by woodruffw »

jrockway wrote: post #80
woodruffw wrote: post #78

Earlier quoted context omitted.

This has been my experience as well: I had to fix a bug in a Go codebase recently, and the fix required me to de-duplicate an unordered collection of elements. It turns out that there's (1) no built-in way to do this, and (2) there isn't even a built-in set structure in Go, so you can't do the obvious solution without explicitly using a map with a chaff value. Stack Overflow has dozens of duplicate questions for this…

map[T]struct{} is the set type in Go. (Note that struct{} is represented with 0 bytes of memory, so it's not chaff.) You might like the slices proposal for utility functions like these: https://github.com/golang/go/issues/45955

Thanks. I wasn't aware that struct{} is zero-sized, so that plugs that hole.

I'll admit freely that I'm not a proficient Go programmer, so it's easier for me to see the things I don't like than the things that Gophers praise. But even this solution leaves me unsatisfied, in contrast to what I'd reach for in Rust or even C++: it requires that I know that struct{} is zero-sized, and I still have to do the manual legwork of writing a CS101 dedupe function.

Re: Go 1.17 Release Notes

#86

Post by vp8989 »

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…

"The Go team originally wanted to replace C++, especially inside Google"

Im glad you said that and I was not just imagining that myself. I remember following the Go language closely in its earlier days and it was often spoken about as a "systems language" but it actually seems to have ended up settling as a language to write servers for people who are sick of OOP but still like their imperative C style code.

Re: Go 1.17 Release Notes

#87

Post by vp8989 »

kubb wrote: post #57

I’ve been using Go at a large software company for 4 years. It does the job, my biggest complaints are the low capacity for abstraction, verbosity and ergonomic pain points. It can do certain things well, but in a large enough project you’ll inevitably find that it doesn’t give you the best tools for certain types of problems. I don’t know what to think about the upcoming generics. It feels late to make such a big ch…

"It feels like a missed opportunity"

I agree with that. I think looking back on it, Go arrived on to the scene at a perfect time where lots of people were rearchitecting so there was lots of natural appetite in the industry for a new language. Go vacuumed up a lot of this opportunity but ultimately hasn't really evolved the practice of software engineering all that much.

Re: Go 1.17 Release Notes

#88

Post by ridiculous_fish »

jdsleppy wrote: post #72
ridiculous_fish wrote: post #58

Earlier quoted context omitted.

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 two years of working in Go at two companies, I have never had to write that. I can't remember writing the equivalent in Python over even more years, either. The 99% case is building a list/slice, not removing from one. Have you ever had to remove elements from a list/slice?

Yes, a sorted vector is a common data structure for frequent queries and infrequent updates.

Re: Go 1.17 Release Notes

#89

Post by yakubin »

initplus wrote: post #47
umvi wrote: post #7

At first I didn't like Go because I thought it was too opinionated. But the more I used it, the more I found the tooling to be just heads and shoulders above similar languages like C/C++. I use VSCode a lot, and in VSCode you can press "F12" to jump to the location of a function definition. In Go I find myself deep diving into github libraries all the time just because F12 takes me there. That never happened with C/C…

If you use C++ tools where your dependencies get pulled in and built from source like Go does, you get the same experience. If you only have prebuilt system libraries obviously this doesn't work. It's not like Go's tooling is that much better than the best modern C++ tools, but the ecosystem is so much more unified by having 1 blessed set of tooling. Rather than 20 different package managers/(meta)build systems. No n…

In C++, preprocessor and template magic in dependencies tends to break such IDE convenience features as "go to definition" or "find all references".

Re: Go 1.17 Release Notes

#90

Post by ricardobeat »

rowanG077 wrote: post #56
pxue wrote: post #52

Earlier quoted context omitted.

For JS, es6/ecma2015 -> ecma2021, lots of language changes.

Of course changes but afaik it's backwards compatible.

I don't think the OP was making a point about backwards compatibility, but how the language itself has remained stable (sign of good design?). That is not the case for the majority of languages, except for maybe Ruby. Javascript in particular looks nothing like code from 6 years ago.
Post reply on HN