Future of Golang

From Adam Colton
Revision as of 14:45, 13 July 2017 by Adamcolton (talk | contribs) (Created page with "This is what I would like to see in the future of Golang. I am not a developer of the language, so take this with a very large grain of salt. Before I tell you what I want (a...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This is what I would like to see in the future of Golang. I am not a developer of the language, so take this with a very large grain of salt.

Before I tell you what I want (and do not want) I will give you the lens through which I view these arguments. I do not care how easy or hard it is to write Go code. I do care how easy it is to read and reason about Go code. I care very much that it remains difficult to be mislead by Go code. I acknowledge that Go is not perfect in this regard, but it is better than any other language I've seen to date.

Go 1.X

These are changes I would like to see that we could have without breaking backwards compatibility.

Packages Fulfill Interfaces

Packages already behave a lot like structs. They have methods and fields. The methods and fields are accessed with the dot operator. It would not be a stretch to be able to use a package to fulfill an interface. This would be fantastic for managing dependencies and greater decoupling.

Go 2.0

These are things that would break backwards compatibility.

Field Attributes

I do not like the way field attributes are currently handled. It's one of the very free-form aspects of an otherwise static language. I would suggest they be replaced with key value pairs where the values can be any builtin type

 type Foo struct {
   Name string `json:"name"` 
 }

becomes

 type Foo struct {
   Name string {json: "name"}
 }

And I would make these values available outside of reflect:

 jsonName, hasField := foo.Name(:json)
 fmt.Println(jsonName, hasField) // "name"