Go 1.17 Release Notes

by aofeisheng • 5 years ago

197 218 5 years ago

It looks like the language is really maturing. The changes are all fairly minor optimizations and improvements to the stdlib. Impressed with the Go team’s discipline for simplicity and stability.

est31• 5 years ago

Between the 1 release in 2012 and the 1.13 release in 2019, this has been the development model of the language. So it's nothing new in Go's evolution.

kplex• 5 years ago

Worth it if only for the go.mod tidy-up, how that made it into a release in the first place baffles me.

Techasura• 5 years ago

Never tried to write Go before, maybe it’s time that I stop by.

itake• 5 years ago

what about this release makes you want to try it?

nwmcsween• 5 years ago

It's meh for a language, it's simple which is what they are trying to achieve but it all comes with trade offs like all programming languages. I would say a large portion of a language is how you mesh with the syntax and tooling around it.

theshrike797• 5 years ago

Go being "meh" is one of its best parts.

It doesn't encourage you to do fancy language tricks, it kindly directs you to get your shit done, compiled and delivered.

tech_dreamer• 5 years ago

Golang release no longer excites me in a good way - I know my old aws hosted apps continue to work, as do my pet projects

colesantiago• 5 years ago

are release notes supposed to be exciting?

staticassertion• 5 years ago

I think they mean "no longer excites me, in a good way"

xwdv2• 5 years ago

Usually they fill me with dread.

umvi• 5 years ago

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++ - the tooling was just too disparate and fragile.

My biggest complaint with Go is lack of generics. I mean technically you can achieve generics with an unholy empty interface/reflection incantation but it's a huge pain compared to C++.

candiddevmike• 5 years ago

Generics are hopefully coming February 2022 with 1.18.

xwdv2• 5 years ago

This will be when I finally use Go for something then.

nappy-doo2• 5 years ago

Important note: it's the preview release. Not everything will be done, there will be gaps. But the first parts of the work have already merged to master, and it's coming.

The_rationalist• 5 years ago

If your reference point is C/C++ then sure.. Go is a progress, but give more modern languages a try, like Kotlin, they sure are a major ergonomic and featureful evolution over go

nestorD• 5 years ago

That's the sad truth. Go is not leap and bound better on that front, it is C/C++ that has not catched up.

klodolph• 5 years ago

Yes, I've been using F12 a lot too, just to dive into random projects. It's amazing how much this little feature means.

ggregoire• 5 years ago

Have you tried "F2" (rename symbol)? It's amazing, it's like a "safe" find & replace all.

initplus• 5 years ago

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 need to worry that I am using build system X, but I want to use a library using build system Y.

yakubin2• 5 years ago

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

jchw• 5 years ago

I think people claiming modern C/C++ tools are close to as good as Go’s are wrong, in my opinion. With that having been said, IMO if you want the C++ experience to be better, use Clangd and generate a compile_commands.json file. For many projects you can use wrappers like compiledb, or Bear, and some build systems like CMake can output it natively. Either way, once you have found a way to do this, and get it outputting into the project root, add a local ignore for it (in .git/info/exclude) and install the VSCode clangd extension.

Truly, it is night and day. I can get Real code intelligence on almost anything, including large C projects with custom Makefiles that compile cross-arch like Wine. It only ever has trouble with unusual translation unit patterns. (You can see this in Higan for example, which has .cpp files including other .cpp files; clangd seemingly fails to put them in the context of the intended translation unit.)

It’s not as good as Go, but it is life-changing for me.

eweise• 5 years ago

"you can press "F12" to jump to the location of a function definition" Seems like standard IDE functionality for at least 20 years.

flohofwoe• 5 years ago

Cross-platform Intellisense support in VSCode with the Microsoft C/C++ extension has improved a lot lately, especially in combination with the CMake Tool extension to automatically discover header search paths and other compilation settings (it used to be very brittle in the beginning on Linux and Mac).

But if you're coding C/C++ in a "proper" IDE like Visual Studio, CLion or Xcode, such features are expected to work out of the box. IME, Intellisense-like features are usually only a pain to setup in "non-integated" development environments like Vim or other text editors.

int_19h7• 5 years ago

This is more a limitation of VSCode than C++. Go to Definition for C++ works just fine in Visual Studio proper for many years now.

skybrian• 5 years ago

Apparently type parameter compiler work was supposed to get merged just after 1.17. [1] Does anyone know if it’s still on?

[1] https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0t...

nappy-doo2• 5 years ago

The merge has already happened. The generic preview is going to be in 1.18 (early 2022).

4ad• 5 years ago

It's already in, it has to be requested by the user with `-gcflags='-G=3'`. Of course, the feature is in heavy development and not ready for production use, YMMV.

37ef_ced32• 5 years ago

My appreciation for Go has been monotonically increasing for years.

The more Go code I write, the more I like the language, the tools, and the standard library.

Low-friction, high-quality software development.

If only I could use it professionally, instead of C++.

theshrike797• 5 years ago

Go is the choice of professionals IMO.

When you have a team of varying skill levels who need to deliver shit that works on a schedule and still have some kind of performance, you use Go.

Even more so if you need to hand off the maintenance to a team of randoms from god knows where and THEY need to be able to keep it running and add new features.

It doesn't have the fanciest new EXPRESSIVE operators or anything exciting really. It just does the job, albeit verbosely.

You can do fancy shit on your own time.

int_19h7• 5 years ago

I would argue that e.g. decent error handling is not "fancy shit".

harikb2• 5 years ago

Module authors may deprecate a module by adding a // Deprecated: comment to go.mod, then tagging a new version. go get now prints a warning if a module needed to build packages named on the command line is deprecated.

Very good for the ecosystem. Nudge folks to upgrade from broken/insecure versions

zz8652• 5 years ago

Anyone seen jobs for business applications? Go seems to have a sweet spot for systems. I'd like to replace Java at my work but no one else is doing it.

debarshri• 5 years ago

When I used to work for traffic enforcement company, their whole backend was written in golang.

jdavis703• 5 years ago

While we’re not building a “business” application we are building a large web application on Go. It’s definitely not just for systems work.

pgwhalen2• 5 years ago

I use (and enjoy using) both Go and Java at work, and Go is in my opinion very much a Java replacement more than it is, say, a Python or C++ replacement. It is absolutely suitable for business logic, and I've never been quite sure what its designers mean when they say it's a systems language. Yes, you can squeeze great performance out of it, but you can with Java as well.

The way I see it, both Go and Java are crawling towards the same ideal: a compiled, statically typed, garbage collected, modern enough program language targeted for a majority of back-end concerns. Go has to close the gap mostly just with generics; and Java with memory layout (Valhalla), concurrency (Loom), and ergonomics (Amber); but they will both be there in 3-5 years.

Take this with a grain of salt if you like, but while I probably find it more fun to program in Go, I don't think there's a compelling reason to switch a large codebase from Java to Go. It often feels like my company is needlessly divided by programming languages even though they solve fairly similar problems. It's one thing to move off of a dying language, but Java is certainly not that.

zz8652• 5 years ago

Thanks, that sounds about right. Throw Rust in there too, its an interesting time.

leo_bloom• 5 years ago

We’ve also introduced pruned module graphs in this release. Modules that specify go 1.17 or higher in their go.mod file will have their module graphs include only the immediate dependencies of other Go 1.17 modules, not their full transitive dependencies.

This is a very welcome change and make the go.mod much more obvious to understand. Hooray!

avl9992• 5 years ago

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.

ridiculous_fish3• 5 years ago

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

yobert• 5 years ago

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.

barsonme2• 5 years ago

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.

benhoyt7• 5 years ago

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.

jdsleppy• 5 years ago

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?

kjksf2• 5 years ago

You can find things to complain in any language, including the languages that YOU use.

For every complain like that in Go I'll find a hundred in C++, ten in Java / JavaScript / Python.

As to your question, as a full-time Go programmer: this doesn't come up often.

When it does, I google "slice tricks" and copy & paste the formula.

It'll be fixed by next release because generics will enable writing a function that does that and that function will be in standard library.

Why wasn't this fixed before generics? Because the only way to do it would be via a compiler built-in function and Go team is rightfully reluctant to bloat the language / compiler for minor functionality like that.

woodruffw3• 5 years ago

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, all with ridiculous O(n^2) or buggy (or both) answers.

jrockway4• 5 years ago

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)

avl9992• 5 years ago

Dealing with any kind of collections will often require you to write more code than you are used to, see the other post in this thread about someone complaining about a lack of Set type. Most of these problems are due to the fact that the language doesn't have generics yet, however generics are coming soon and once they do arrive we will have a robust collection and concurrent collection library to alleviate for most of these problems.

For now you just have to accept these quirks as part of the tradeoff of working with the language. I don't find it that big of a deal esp with the solution on the horizon.

bilinguliar• 5 years ago

It is not only hard for you, but it is also hard for a computer. And Go expresses this perfectly. Once you hide this behind a convenient `slice.Delete(x)`, you may end up with a codebase that bleeds performance.

_ph_2• 5 years ago

This is an interesting point. On the first glance, it looks like a very obvious missing piece and having to hand-write such expressions feels like unnecessary painful.

On the second glance, one can see why probably it was left out: there are two fundamental different ways to implement the deletion. You can copy the last element into the slot of the deleted element, or you can move all elements after the deleted one place to the left. The latter is what you implemented and preserves the ordering, which often is desirable. The former is way more efficient, if you don't need to preserve the order. A default implementation would probably choose to preserve the order and thus introduce a systematic inefficiency which is easy to be avoided.

Fortunately, with the introduction of generics and especially the new slice package, this discussion becomes moot.

dang2• 5 years ago

Two recent related threads:

Go 1.17 Beta - https://news.ycombinator.com/item?id=27462884 - June 2021 (118 comments)

Go 1.17 is deprecating the traditional use of 'go get' - https://news.ycombinator.com/item?id=27630625 - June 2021 (215 comments)

benhoyt7• 5 years ago

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 typical reduction in binary size of about 2%. This is currently enabled for Linux, macOS, and Windows on the 64-bit x86 architecture (the linux/amd64, darwin/amd64, and windows/amd64 ports).

I love how they're doing it in such an iterative fashion: even assembly functions don't have to be rewritten. Then again, I guess doing it progressively like this is the only feasible way to avoid reworking all the low-level assembly routines in one fell swoop.

benhoyt7• 5 years ago

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<100000000; i++) s += i; print(s) }'
  4999999950000000
  real    0m10.158s ...
  $ time goawk_go1.17 'BEGIN { for (i=0; i<100000000; i++) s += i; print(s) }'
  4999999950000000
  real    0m6.268s ...

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 like everything's a bunch faster.

barsonme2• 5 years ago

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

prattmic• 5 years ago

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.

drchase• 5 years ago

Hi, I'm one of the people who worked on it, and the guy who did the initial estimate back in early 2017. 5% is the geomean of a lot of benchmarks; a whole lot fall in the the 4-8% range, a few do worse because the new ABI creates new patterns of register use that don't fit well with the current register allocator, and the fix was larger than we wanted to risk. (See https://github.com/golang/go/issues/46216 )

benhoyt7• 5 years ago

Overall for GoAWK I get an 18% speed increase on my micro-benchmarks between Go 1.16 and 1.17 (see https://github.com/benhoyt/goawk/commit/1f314f421273b3dc164f...) and I measured an 8% speed increase on my "slightly more real-world" benchmarks (these ones: https://github.com/benhoyt/goawk/blob/master/benchmark_awks....).

Scaevolus• 5 years ago

Look at the disassembly and observe how your function calls have far fewer push/pop operations going on, and how the function prologues/epilogues are smaller.

_ph_2• 5 years ago

The speed gained depends a lot on the structure of the code benchmarked. Natively written Go code has more computation happening in local loops without many function calls, the optimization brings less effect. An interpreter often calls a function for every single directive executed. This means, you have a lot of function calls inside loops, sometimes for every single operation executed. This of course profits massively from this optimization.

jen20• 5 years ago

This also likely improves compatibility with observability tooling which assumes the standard calling convention, which is welcome.

benhoyt7• 5 years ago

Note that this switches to a register-based calling convention, but it's not the platform "standard" one. The Go authors describe the rationale for this here: https://go.googlesource.com/proposal/+/master/design/40724-r...

throw149102• 5 years ago

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.

asadawadia4• 5 years ago

why though? some perf gains?

DenseComet• 5 years ago

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++.

rowanG0773• 5 years ago

No. More because Rust offers modern language features and it's much easier to get code working then in Go.

ithkuil6• 5 years ago

I hate to be "that guy" too, but coming from somebody who really likes Rust and is using it more and more (also at $dayjob now) we must admit that Go tooling is one step ahead. CPU profiler, allocation and heap profiler, lock contention profiler. It all comes out of the box.

Yes you have cargo flamegraph for profiling locally and you now have pprof-rs to mimick Go's embedded pprof support. But allocation heap profiling is still something I struggle with.

I saw there was a pprof-rs PR with a heap profiler but there was some doubt as to whether it worked correctly; to get a feeling of how that approach would work but without having to fork pprof-rs I implemented the https://github.com/mkmik/heappy crate which I can use to produce memory allocation flamegraphs (using the same "go tool pprof" tooling!) in real code I run and figure out if it works in practice before pushing it upstream.

But stuff you give for granted like figuring out which structure accounts for most used memory, is very hard to achieve. The servo project uses an internal macro that help you trace the object sizes but it's hard to use outside the servo project.

The GC makes some things very easy, and it's not just about programmers not having to care about memory; it's also that the same reference tracing mechanism used to implement GC can be used to cheaply get profiling information.

the84722• 5 years ago

But allocation heap profiling is still something I struggle with.

Switch to a dumb allocator and then profile mmap calls or page faults? That should get you large allocations at least. It's a pretty crude proxy. The other allocation profilers I'm aware of cause significant slowdowns.

bombela2• 5 years ago

What about valgrind? https://valgrind.org/

kouteiheika2• 5 years ago

But allocation heap profiling is still something I struggle with.

Have you tried this one? https://github.com/koute/memory-profiler

throwaway8943458• 5 years ago

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--languages which are both far less safe than Go and far slower and yet Go is on par with those languages with respect to productivity (I argue it's more productive due to its static typing features, but others argue it's less productive presumably because of the learning curve). Most software doesn't need to be so fast or correct.

Also, I work in distributed systems and SaaS (software as a service). In this world, most errors are silly type errors ("undefined is not a function", forgetting to `await` some async function, etc) that would be caught with a flat-footed type system like Go's. Beyond that, the next largest bucket are issues that even a sophisticated type system like Rust's wouldn't help with, such as infrastructure issues (missing/misconfiguration of some cloud permission, networking rule, etc), misconfiguration of the service, race condition with many processes accessing the same networked resource, deployment error, etc. This means that Rust's stated advantages aren't really as nice as they initially sound.

As a programmer, I can appreciate a super fast language with a strict type system; however, as an engineer or a technologist, Rust is rarely a good fit for me. Go seems to be a lot closer to the sweet spot, which makes sense because it was developed expressly with distributed systems in mind.

josephg3• 5 years ago

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).

tialaramex4• 5 years ago

but there is still a big productivity gap between the borrow checker and GC.

The borrow checker and GC aren't really doing the same thing though. One very important distinction in some fields (but unimportant in others) is that GC only really cares about memory resources. So you are (or should be) doing explicit manual cleanup for all non-memory resources in a GC language. Rust isn't, in Rust we don't write explicit resource cleanup for a programmable interrupt controller, or a file, or a database connection -- the resource knows how to manage itself, and Rust promises to tell it immediately when it falls out of use, whereas a GC can't promise to ever clean up which is why Go doesn't even bother providing a means to do this automatically for your non-memory resources when they're garbage collected (Java does, but again, no promises it ever fires, so, don't rely on this).

Blikkentrekker3• 5 years ago

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.

Even if it weren't for the performance I would use Rust over Go due to the lack of generics alone, as well as the associated general philosophy of Go that boilerplate is good and one should repeat oneself as much as possible.

Zababa• 5 years ago

I have the opposite view on the type systems: Rust's type system is really great for business logic because it's really expressive (based on algebraic data types), but the language being made for low level stuff makes some things a pain. If you do something like DDD, ADTs really shine, especially when combined with pattern matching. I do agree that when you can afford a GC, Rust can be annoying.

_008_jb_2• 5 years ago

Ah, the desperate Rust promoter crew enters the Go thread ...

Rust is great for language enthusiats doing hobby projects or for learning. The Rust book is great. Rust has great language features.

Having that said, Rust is the right tool for the job for a very small niche. Basically, if you would have used C++ before and don't need much developer reach or mature libraries. And only for the rare cases you really cannot affort a GC (even though Go's GC is highly optimized).

Go on the other hand, is an industrial strength proven and mature general purpose language. It is the best fit for various kind of networking application. Especially APIs, but also infrastructure where you can live with an GC. CLIs are great with Go as well.

If you're working on a professional grade project (where the GC is acceptable), Go is much superior than Rust in all regards.

Rust is advertised for years and years and didn't have it's breakthrough yet. This empirical fact cannot be ignored. There're reasons for this, of course. Some are:

- Writing Rust consumes so much more mental power with so little gain. That mental energy should be directed to solving the problem.

- Go makes everything besides your problem at hand easy. You can focus on solving your problem, not fighting the Borrow Checker

- Rust's ecosystem is not reliable. Many essential libs are one-man-shows. Version 0.1 everywhere.

- Rust is for and by language enthusiats. If you need to rely on libs for longer than a couple of years it is a hight risk for your project

- In terms of real world performance: Go is so close to Rust that there're very very very few use cases that really need that marginal gain

dang2• 5 years ago

We detached this subthread from https://news.ycombinator.com/item?id=28203422.

matthewmacleod• 5 years ago

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 like "this can never be nil and if it's is then it's an error" to the compiler. I resent having to write three lines of boilerplate every time I want to reverse a flipping 10-item slice, and the design decisions leading to the existence of `time.IsZero()` are bordering on criminal.

I don't know if I'm the odd one out for feeling like that – parts of the language and ecosystem are just absolutely wonderful to work with, but the unergonomic sharp edges bother me so much that I end up finding it really _annoying_ to write a lot of it.

cpeterso• 5 years ago

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.

kjksf2• 5 years ago

.IsZero() is a pragmatic solution given the constraints of the system (i.e. Go language).

Go has a notion of "zero value". When you don't assign a value explicitly it'll be set by the compiler to "zero value" of that type.

This is much better than C/C++ of "random value".

For primitive types, the compiler decides what "zero value" is. For structs, each component is set to its zero value.

For good reasons (language simplicity) Go doesn't allow the user to declare what the zero value is (something that you can do in e.g. C++ via a constructor).

Time is a struct. Its zero value is the same as for any other struct and not meaningful time value.

It's a pragmatic necessity to be able to query "is this time value an unset time value?". A pragmatic solution for this need is to provide IsZero() method on Time struct.

jrockway4• 5 years ago

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
    }

jrockway4• 5 years ago

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

pxue2• 5 years ago

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.

rowanG0773• 5 years ago

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.

slownews453• 5 years ago

python 2 -> 3 was not easy (aka a total nightmare).

By 3.6 it was pretty good though and even migrations and dual code bases were easier because they went back and allowed things like u"" for unicode strings to continue to mean unicode strings in python 3 - before that they'd actually blocked unicode in 3 that was working well in 2.x code bases! It was a total in your face move to break the ecosystem even though supporting u"" would have been almost no cost in terms of improving compatibility with existing code. ASCII handling (important for things like web tech stacks header handling etc) also improved thankfully. 3.x made things a lot harder initially (and slower too).

Also a lot of code doesn't look the same over time - the conventions (formatting) are either very poorly defined or change. Go seems to have pretty much one format from fmt

etc

pxue2• 5 years ago

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

Strum355• 5 years ago

Ive had a number of python libraries (and Im not talking small, lesser known ones) that would depend on (and break in the absence of) specific quirks in Python versions that made upgrading python an unnecessary hassle.

pjmlp12• 5 years ago

My C and C++ code for Windows 3.1 written in 1995 would compile just fine today on Windows 10.

systemvoltage3• 5 years ago

As a person that gets anxiety from JS projects and how fast things move, I love this aspect of C. It puts the soul to ease.

ithkuil6• 5 years ago

I heard this a lot but I wonder if it's still really true. I mean, can I literally open the latest visual studio and open an old project, hit build and it will just work?

maccard2• 5 years ago

The C++ I wrote in 2013 still looks and works the same as it did 8 years ago, and I can write code in the same way, or opt in to newer features in C++14/17 too. The C++ code that I wrote in 2007 (when I started writing C++) also still works.

kubb• 5 years ago

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.

vp89895• 5 years ago

"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.

erik_seaberg5• 5 years ago

feels late to make such a big change

This is recoverable. The Java world was also saddled with a decade of awful pre-generic code, but we burned almost all of it to the ground and started over.

int_19h7• 5 years ago

The need to tackle generics later resulted in design decisions such as type erasure, which even today are still limiting the evolution of Java.

zozbot2342• 5 years ago

an effort with similar funding but a more sound theoretical foundation than being Newsqueak 3.0 could have become an industry game changer.

That's a pretty good description of Rust 0.x. Might ring a bell.

hakube• 5 years ago

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

galleywest• 5 years ago

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.

jizzlepizzle• 5 years ago

the vscode extension automatically formats your go file and removes any packages that aren't used in the code.

https://code.visualstudio.com/docs/languages/go#_formatting

peterohler• 5 years ago

Just tried [OjG](https://github.com/ohler55/ojg) and saw anywhere from zero to 20% faster on the various benchmarks. Nice improvement overall. Hats off to the golang maintainers.

_008_jb_2• 5 years ago

When I started using Go I was more than sceptical. I had to mirgrate a CLI tool written in Kotlin (still my favorite language) because the memory consumption was to high.

After a while I actually understood why Go is such a successful language / ecosystem:

Go's priority is to make projects easier. It is doing so by all it's smaller and larger features respectivly skipped features. But one soon understands the big picture of the Go team. Go is designed by very experienced devs who knew what is important and what not.

In my Go projects, I don't have to worry about:

- Memory safety

- Tooling

- Performance

- Structure (once I understood the package desgin philosophie)

- Difficult syntax

- Concurrency

- Libraries, as we can do most with the standard lib

- Maturenes and stability

Instead I focus on the things that count:

- Solve the problem at hand

- Create correct, stable and maintable software

And as this was not enough, the Go team comes around the corner with an 5 % average performace gift.

Awesome.

systemvoltage3• 5 years ago

Not a GO dev, has the debugging experience improved?

theshrike797• 5 years ago

Dunno, 20 years in the business and I still debug with print statements.

It's enough in 95% of cases and it works every time in every environment. In the time it takes me to get a debugger running and attached to a process, I've print-debugged it and fixed it already =)

harikb2• 5 years ago

VsCode or IntelliJ with delv works beautifully for most common tasks. But don’t compare to JVM/Java. It does get trickier if you have many concurrent/goroutines but that is not unique to Go.

denysvitali• 5 years ago

Go 1.17 adds support of 64-bit ARM architecture on Windows (the windows/arm64 port). This port supports cgo.

Yay!

rawoke083600• 5 years ago

Lol Good Little Go ! :) Still one of my favourite languages whenever "heavy lifting" or concurrency is required (really they make it stupidly easy).

Now add pattern matching please ! Well done to everyone that worked on Go ! It's still a pleasure to use.

Go 1.17 Release Notes

Related Stories