My Favorite Go 2 Proposals
Tags: go, opensource
Published: 2018-08-14 13:28:04

---
title: My Favorite Go 2 Proposals
published: true
description: A list of proposals for Go 2 which I believe would make a great addition.
tags: Go, Open Source
cover_image: https://user-images.githubusercontent.com/643503/28179069-b1b8a33c-67b5-11e7-9e13-dc32f24883aa.jpg
---

As some gophers may have heard, [Go 2](https://github.com/golang/go/wiki/Go2) may be coming soon! It's still in the planning phase though, and the Go team is still working on what features should and shouldn't be in the language.

One of my favorite things about Go is its lack of syntactic sugar, it really feels like I'm problem solving, rather than writing tons of gibberish. The Go team doesn't want to have yet another feature-bloated language, which is why I really enjoy it.

Anyway, there's [over 7 pages of Go 2 proposals](https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3AGo2), and I've been searching through them, so I thought I'd list some of my favorites.

## Interface Literals [#25860](https://github.com/golang/go/issues/25860)

This one is a bit hard to understand at first, but once you understand it, it becomes much simpler to read.

So let's say you want to sort a slice of strings... This is now simplified with `sort.Strings` and `sort.Slice`, but for the sake of example, let's pretend `sort.Sort` is all we're able to use. This function takes an interface (called `sort.Interface`) which has 3 methods defined, so in order to use it, you must make sure those 3 methods are defined for your type:
{% gist https://gist.github.com/deanveloper/a9e3dca9123146a7d910eb4a8370a2a8 %}

But with this proposal, we can make it look like this instead!

{% gist https://gist.github.com/deanveloper/8d0f362b2007df11884507e96e320e76 %}

Essentially what we have done is to use an *interface literal* instead of needing to make a new type! This means that the code that you use to sort can now be put where you actually do your sorting.

## Add `collect` statements to the language [#25626](https://github.com/golang/go/issues/25626)

This one is really nice, actually. They want to add a statement called `collect` to the language. It's hard to explain with words (in my opinion), so let's do it with an example!

Here is some valid Go code, with some error handling of course:
{% gist https://gist.github.com/deanveloper/a97579df5de55f7d4c80348a67fe438b %}

And as my Computer Science professor said, if you're repeating code, you're doing it wrong! But in Go, there's no good way to really handle the `err != nil` repetition problem here, so how could we help this? The `collect` statement helps fix this issue!

So let's have the same code, but with the `collect` statement.
{% gist https://gist.github.com/deanveloper/e86a5dbb6e2f5ffb0c39d779dd48a2d7 %}

So what does this do? Well the `collect err` indicates that we are going to collect into a variable `err`. Then, each time we assign to `_!`, it assigns that value to `err`, and checks `if err != nil`. If the assigned value is not nil, it exits the `collect` statement, and then the error handling can be done afterward.

My main issue with the proposal is that the syntax is a bit confusing (I personally don't like the `_!` syntax, I made a suggestion to use `err!` instead, which makes it a bit more clear).


## Fix casing issues [#1187](https://github.com/golang/go/issues/1187)

This one is quite a bit simpler than the last one. The `os` package has a lot of confusing casing, it's not always clear if the correct function call is `os.Chdir` or `os.ChDir`, or if it should be `os.Tempdir` or `os.TempDir`. I'm hoping the proposal to fix these casing issues gets accepted!

-----

There are [TONS of Go 2 proposals](https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3AGo2). Go has some really strong views on what should/shouldn't be in the language, the Go creators definitely don't want to make another C#, JavaScript, or other feature-bloated language. While I really _like_ the idea of a `collect` statement, I'm not sure if the Go creators would like it, as it may be seen as an unnecessary feature (which I understand).

What do you think about the proposals? Do you have any you want to add? Let me know, Go is one of my favorite languages out there, and I'd love to have more insight as to what its future may look like!