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

51–60 of 222 posts

Re: Go 1.17 Release Notes

#51

Post by throwaway894345 »

omginternets wrote: post #44
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.

It hits the mark because it targets the niche that was once occupied by interpreted languages.

But it wasn't just "interpreted languages". Really the only interpreted languages in "the niche" were Python and a little bit of Ruby, but there was also a whole bunch of Java, C#, and C++.

Re: Go 1.17 Release Notes

#52

Post by pxue »

rowanG077 wrote: post #43
pxue wrote: post #35

The go code I wrote in 2015 looks and works exactly the same way new Go code I'm writing today. Even with all the upgrades. You have no idea how amazing that feels.

Isn't that the case for the vast majority of languages though? The python,c,Haskell,js,language x code from 2015 works the same now as it did 5 years ago.

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

Re: Go 1.17 Release Notes

#53

Post by 37ef_ced3 »

DenseComet wrote: post #36
asadawadia wrote: post #31

Earlier quoted context omitted.

why though? some perf gains?

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.

Re: Go 1.17 Release Notes

#54

Post by cpeterso »

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.

Re: Go 1.17 Release Notes

#55

Post by atombender »

dilyevsky wrote: post #39
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++.

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 language. Systems people want something like Rust instead.

Re: Go 1.17 Release Notes

#56

Post by rowanG077 »

pxue wrote: post #52
rowanG077 wrote: post #43

Earlier quoted context omitted.

Isn't that the case for the vast majority of languages though? The python,c,Haskell,js,language x code from 2015 works the same now as it did 5 years ago.

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

Of course changes but afaik it's backwards compatible.

Re: Go 1.17 Release Notes

#57

Post by kubb »

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 change so long after the language has been established. At least a plan for it should have been integrated into the language from the start.

It feels like a missed opportunity - an effort with similar funding but a more sound theoretical foundation than being Newsqueak 3.0 could have become an industry game changer. Instead it fills a niche, which is a success, albeit smaller.

Re: Go 1.17 Release Notes

#58

Post by ridiculous_fish »

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

Re: Go 1.17 Release Notes

#59

Post by barsonme »

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…

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

Re: Go 1.17 Release Notes

#60

Post by yobert »

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

I use slices all the time, but very rarely need to delete out of the middle of them. So it seems like a bit of an edge case to me.
Post reply on HN