Future of Golang - Revision history

Adamcolton: /* Dependency Management Tool */

2017-07-14T18:48:25Z

Dependency Management Tool

← Older revision		Revision as of 18:48, 14 July 2017
Line 173:		Line 173:

	==== However... ====		==== However... ====
	Package maintainers should provide versioned branches of their code. And many do. This allows for the community to experiment with different conventions and different tools but allow Go to remain agnostic.		Package maintainers should provide versioned branches of their code. And many do. This allows for the community to experiment with different conventions and different tools (like [https://github.com/golang/dep dep]) but allow Go to remain agnostic.

	== Notes ==		== Notes ==

Adamcolton: /* What I don't want */

2017-07-14T18:46:56Z

What I don't want

@@ Line 164: / Line 164: @@
    type MapValue {}interface
 Then it becomes trivial to setup a build process that copies that package and replaces those two lines. Yes, it's part of the build process, not part of the compile process and yes, now we have a bunch of generated code. But the code only needs to be generated when it's added or changed so it doesn't slow down compile times. And seeing generated code means you can confirm it looks they way you think it should and you can reason about. Remember that I want code that's easy to read. Code that's generated at compile time is impossible to read.
 == Notes ==

Adamcolton at 18:17, 14 July 2017

2017-07-14T18:17:09Z

← Older revision		Revision as of 18:17, 14 July 2017
Line 1:		Line 1:
	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.		I started working on this shortly after [https://www.reddit.com/r/golang/comments/69smja/what_would_you_most_like_to_see_in_go_20/ this post] went up on reddit. And with the Go2.0 announcement, I thought it was a good time to post. 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.		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.
Line 6:		Line 6:

	== Go 1.X ==		== Go 1.X ==
	These are changes I would like to see that we could have without breaking backwards compatibility.		These are changes I would like to see that we could have without breaking backwards compatibility. They may make more sense in a 2.0 release, but they could feasibly done in the current version.

	=== Packages Fulfill Interfaces ===		=== Packages Fulfill Interfaces ===

Adamcolton: /* Negative Indicies */

2017-07-14T18:14:24Z

Negative Indicies

← Older revision		Revision as of 18:14, 14 July 2017
Line 72:		Line 72:
	==== Negative Indicies ====		==== Negative Indicies ====
	Given a slice s, s[-1] should return the last item in the list.		Given a slice s, s[-1] should return the last item in the list.

			It has been [https://github.com/golang/go/issues/11245 discussed before], but I disagree with the logic. I believe the opportunity for subtle bugs is fairly small. All the cases where you could have those subtle bugs are currently cases that could panic. And I believe it makes code more readable.

	=== Type type ===		=== Type type ===

Adamcolton at 18:04, 14 July 2017

2017-07-14T18:04:24Z

← Older revision		Revision as of 18:04, 14 July 2017
Line 43:		Line 43:
	Here are some others I like, but I have nothing to add to the conversation.		Here are some others I like, but I have nothing to add to the conversation.
	* https://github.com/golang/go/issues/6977		* https://github.com/golang/go/issues/6977
			* https://github.com/golang/go/issues/6815

	== Go 2.0 ==		== Go 2.0 ==
Line 69:		Line 70:
	The only thing that should have a nil value is a pointer. And a pointer should always have a type.		The only thing that should have a nil value is a pointer. And a pointer should always have a type.

	=== ~~Variables per loop with Range~~ ===		==== Negative Indicies ====
	~~https://github.com/golang/go/issues/20733~~		Given a slice s, s[-1] should return the last item in the list.

	~~This can cause some bad headaches if you forget about it.~~

	~~=== Field Attributes~~ ===
	~~I do not like the way field attributes are currently handled. It ends up being~~ a ~~place where tools drop their own little DSLs. 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"~~
	~~Though I don't care about~~ the ~~semantics,~~ the ~~above is just a suggestion~~.

	=== Type type ===		=== Type type ===
Line 109:		Line 92:
	It still wouldn't let you cast to a type because the type isn't know at compile time.		It still wouldn't let you cast to a type because the type isn't know at compile time.

	==== Half-Baked ====		=== Others ===
			I like these but have nothing to add
			* https://github.com/golang/go/issues/20443
			* https://github.com/golang/go/issues/19623
			* https://github.com/golang/go/issues/20165
			* https://github.com/golang/go/issues/8082
			* https://github.com/golang/go/issues/20733

			=== Half-Baked ===
	I'm less sure of the following ideas, but they're worth consideration.		I'm less sure of the following ideas, but they're worth consideration.

	=== Range with functions, maybe? ===		==== Range with functions, maybe? ====
	Given a function		Given a function
	func(...) (..., bool)		func(...) (..., bool)
Line 133:		Line 124:
	And because the first and last portion of the loop must match, there's room for error.		And because the first and last portion of the loop must match, there's room for error.

	=== mutex.Lock returns unlock func ===		==== mutex.Lock returns unlock func ====
	It would be safer		It would be safer
	lock := mux.Lock()		lock := mux.Lock()
Line 144:		Line 135:
	}		}

	=== Allow fulfilled types on Interface definitions ===		==== Allow fulfilled types on Interface definitions ====
	This comes up when building object graphs. Often you will have something like		This comes up when building object graphs. Often you will have something like
	type Node interface {		type Node interface {
Line 156:		Line 147:

	That doesn't fulfill. If Foo.parent can fullfil Node, than f.Parent() should return Foo and Node(f).Parent() should return Node.		That doesn't fulfill. If Foo.parent can fullfil Node, than f.Parent() should return Foo and Node(f).Parent() should return Node.

	~~=== Negative Indicies ===~~
	~~Given a slice s, s[-1] should return the last item in the list.~~

	== What I don't want ==		== What I don't want ==
Line 177:		Line 165:
	== Notes ==		== Notes ==
	=== Go1 ===		=== Go1 ===

	*
	* https://github.com/golang/go/issues/6815

	=== Go2 ===		=== Go2 ===
	[https://github.com/golang/go/labels/Go2]		[https://github.com/golang/go/labels/Go2]
	* https://github.com/golang/go/issues/20443
	* https://github.com/golang/go/issues/19623
	* https://github.com/golang/go/issues/20165
	* https://github.com/golang/go/issues/8082
	*

Adamcolton at 17:58, 14 July 2017

2017-07-14T17:58:02Z

← Older revision		Revision as of 17:58, 14 July 2017
Line 27:		Line 27:
	}		}
	All fields and methods on Foo would be exposed, but myFoo.Foo is not.		All fields and methods on Foo would be exposed, but myFoo.Foo is not.

			=== Append buffered Channels ===
			A common problem when using buffered channels is determining what the capacity should be. There are few cases where if you exceed the capacity of a channel, you risk deadlock. There are a number of solutions to the problem, but all require at least one additional go routine to baby-sit the channel.

			I would suggest extending append to work on buffered channels
			ch = make(chan int, 10)
			ch = append(ch, 1,2,3,4,5)
			fmt.Println(len(ch), cap(ch)) // 5,10
			ch = append(ch, 6,7,8,9, 10)
			fmt.Println(len(ch), cap(ch)) // 10,10
			ch = append(ch, 11,12,13) // at this point, the channel is overflows the buffer, so the capacity is doubled
			fmt.Println(len(ch), cap(ch)) // 13,20

	=== Others ===		=== Others ===
	Here are some others I like, but I have nothing to add to the conversation.		Here are some others I like, but I have nothing to add to the conversation.
			* https://github.com/golang/go/issues/6977

	== Go 2.0 ==		== Go 2.0 ==
Line 164:		Line 177:
	== Notes ==		== Notes ==
	=== Go1 ===		=== Go1 ===
	* https://github.com/golang/go/issues/6977
	* ~~https://github.com/golang/go/issues/20352~~		*
	* https://github.com/golang/go/issues/6815		* https://github.com/golang/go/issues/6815

Adamcolton: /* Go 1.X */

2017-07-14T17:44:48Z

Go 1.X

← Older revision		Revision as of 17:44, 14 July 2017
Line 27:		Line 27:
	}		}
	All fields and methods on Foo would be exposed, but myFoo.Foo is not.		All fields and methods on Foo would be exposed, but myFoo.Foo is not.

			=== Others ===
			Here are some others I like, but I have nothing to add to the conversation.

	== Go 2.0 ==		== Go 2.0 ==

Adamcolton: /* Go 2.0 */

2017-07-14T17:43:09Z

Go 2.0

← Older revision		Revision as of 17:43, 14 July 2017
Line 45:		Line 45:
	foo := new(Foo)		foo := new(Foo)
	so just get rid of it.		so just get rid of it.

			=== Better nil ===
			Most of the rough edges around Go have to do with nil handling. There are a few things that I think would help with this.

			No built in types should be nil. What is currently an nil slice would be a slice with length 0 and capacity 0. Same thing for a map. Under the hood it could still be represented as nil. As an extension of this, the zero value of a map would not fail when the first value is assigned.

			The only thing that should have a nil value is a pointer. And a pointer should always have a type.

			=== Variables per loop with Range ===
			https://github.com/golang/go/issues/20733

			This can cause some bad headaches if you forget about it.

	=== Field Attributes ===		=== 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		I do not like the way field attributes are currently handled. It ends up being a place where tools drop their own little DSLs. I would suggest they be replaced with key value pairs where the values can be any builtin type

	type Foo struct {		type Foo struct {
Line 60:		Line 72:
	jsonName, hasField := foo.Name(:json)		jsonName, hasField := foo.Name(:json)
	fmt.Println(jsonName, hasField) // "name"		fmt.Println(jsonName, hasField) // "name"
			Though I don't care about the semantics, the above is just a suggestion.
	~~=== Better nil ===~~
	~~Most of the rough edges around Go have to do with nil handling. There are a few things that~~ I ~~think would help with this.~~

	~~No built in types should be nil. What is currently an nil slice would be a slice with length 0 and capacity 0. Same thing for a map. Under~~ the ~~hood it could still be represented as nil. As an extension of this~~, the ~~zero value of a map would not fail when the first value~~ is ~~assigned.~~

	~~The only thing that should have a nil value is a pointer. And a pointer should always have~~ a ~~type~~.

	=== Type type ===		=== Type type ===
	In a switch statement, we have foo.(type). I would propose extending that. This gets some of the functionality the community feels is missing from the lack of generics while keeping the language mostly static.		I have to admit, I'm less sure of this one. It's more a vague idea than a full suggestion, but I think it has merit. In a switch statement, we have foo.(type). I would propose extending that. This gets some of the functionality the community feels is missing from the lack of generics while keeping the language mostly static.

	We could do type comparisons		We could do type comparisons
	var someBool = foo.(type) == bar.(type)		var someBool = foo.(type) == bar.(type)
			or
			func RestrictType(t Type) func(interface{}){
			return func(i interface{}){
			if i.(type) != t {
			panic("Type Mismatch")
			}
			// continue
			}
			}

	And often when using data-structures (like [https://github.com/google/btree btrees]) we want them to hold a consistent type. Having a Type type would let us write packages that enforced that, but with the same semantic rigor that interfaces give us.		And often when using data-structures (like [https://github.com/google/btree btrees]) we want them to hold a consistent type. Having a Type type would let us write packages that enforced that, but with the same semantic rigor that interfaces give us.

	~~=== Variables per loop with Range ===~~		It still wouldn't let you cast to a type because the type isn't know at compile time.
	~~https://github~~.~~com/golang/go/issues/20733~~

	~~This can cause some bad headaches if you forget about it~~.		==== Half-Baked ====
			I'm less sure of the following ideas, but they're worth consideration.

	=== Range with functions, maybe? ===		=== Range with functions, maybe? ===
	Given a function		Given a function
	func(...) (..., bool)		func(...) (..., bool)
	It can be used in a range loop, and the loop will exit when the bool is false.		It can be used in a range loop, and the loop will exit when the bool is false. As it stands, there are four ways to get this behavior but they all have significant drawbacks.

			You can have a function return a slice and use range. But if the slice is long, that can waste memory. And if it is likely that you'll only consume part of the list, it wastes compute power as well. It also fails completely if the upper bound isn't know.

			You can have a channel with a go routine on the other end. But if the loop wants to break it needs to send a signal to the go routine. Doing this correctly is just a bit bulky and doing it wrong causes leaks.

			You can do it with some sort of iterator, but that's also a bit bulky and there are many variations on this so the reader has to decipher how a particular iterator works.

			And finally, the one that mostly closely matches the original suggestion, you can do it with a for loop, but that can get really bulky
			for a, b, keepGoing := someFunc(); keepGoing; a, b, keepGoing := someFunc(){
			// do something with a and b
			}
			not too bad there, but this gets worse
			for a, b, c, d, keepGoing := someFunc(x, y, z); keepGoing; a, b, c, d, keepGoing := someFunc(x, y, z){
			// do something with a and b
			}
			And because the first and last portion of the loop must match, there's room for error.

	=== mutex.Lock returns unlock func ===		=== mutex.Lock returns unlock func ===

Adamcolton: /* Generics */

2017-07-14T17:12:57Z

Generics

← Older revision		Revision as of 17:12, 14 July 2017
Line 117:		Line 117:
	=== Generics ===		=== Generics ===
	These are not necessary and they will not make code more readable. There are already lots of alternatives to generics and there's a good trade off that higher level abstractions require more work from the author to keep the code in a state that it can be reasoned about.		These are not necessary and they will not make code more readable. There are already lots of alternatives to generics and there's a good trade off that higher level abstractions require more work from the author to keep the code in a state that it can be reasoned about.

			Generics are more helpful when writing code than when reading code. As I stated at the beginning, I'm far more concerned with the later.

			While there is a lot of support for the idea of adding generics, that is only true in the abstract. If you ask the community why they need them, what problems it will solve and how they should be implemented, they seemingly large block breaks down into disagreement. I don't think generics should be added until a significant portion of the community (~70%) can reach an agreement on what problems they will solve and how they will be implemented.

	==== However... ====		==== However... ====

Adamcolton at 15:56, 13 July 2017

2017-07-13T15:56:06Z

← Older revision		Revision as of 15:56, 13 July 2017
Line 2:		Line 2:

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

			I would also prefer to keep the language spec small. There are features that could be added that would be consistent with Go, but provide little functionality.

	== Go 1.X ==		== Go 1.X ==