What I'd like to see in Go 2.0

I&#x27;d add one more to this list: proper enum types.<p>We use enums heavily to force devs who use our code into good choices, but the options are currently:<p>1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update it every time a new enum value is added).<p>2) Use string-type enums: human-readable error values, but same problems with no compile-time guards, exhaustive switch, or validation at runtime.<p>3) Use struct-based enums per <a href="https:&#x2F;&#x2F;threedots.tech&#x2F;post&#x2F;safer-enums-in-go&#x2F;" rel="nofollow">https:&#x2F;&#x2F;threedots.tech&#x2F;post&#x2F;safer-enums-in-go&#x2F;</a> : human-readable error values and an okay compile-time check (only the all-default-values struct or the values we define), but it still doesn&#x27;t have exhaustive switch, is a complex pattern so most people don&#x27;t know to use it, and suffers from the mutable `var` issues the post author detailed.<p>To my naive eye, it seems like a built-in, compile time-checked enum type with a FromString() function would help the community tremendously.

From Rob Pike on reddit regarding this post[0]:<p>The and and or functions in the template packages do short-circuit, so he&#x27;s got one thing already. It was a relatively recent change, but it&#x27;s there.<p>Non-deterministic select is a critical detail of its design. If you depend on a deterministic order of completion of tasks, you&#x27;re going to have problems. Now there are cases where determinism might be what you want, but they are peculiar. And given Go&#x27;s general approach to doing things only one way, you get non-determinism.<p>A shorthand syntax for trial communication existed. We took it out long ago. Again, you only need one way to do things, and again, it&#x27;s a rare thing to need. Not worth special syntax.<p>Some of the other things mentioned may be worth thinking about, and some of them have already (a logging interface for instance), and some we just got wrong (range). But overall this seems like a list of things driven by a particular way of working that is not universal and discounts the cost of creating consensus around the right solutions to some of these problems.<p>Which is not to discount the author&#x27;s concerns. This is a thoughtful post.<p>0: <a href="https:&#x2F;&#x2F;old.reddit.com&#x2F;r&#x2F;golang&#x2F;comments&#x2F;s58ico&#x2F;what_id_like_to_see_in_go_20&#x2F;hsvv99z&#x2F;" rel="nofollow">https:&#x2F;&#x2F;old.reddit.com&#x2F;r&#x2F;golang&#x2F;comments&#x2F;s58ico&#x2F;what_id_like...</a>

Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they&#x27;re in github and I need to fork them and now change all the code that references them. I don&#x27;t know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot.<p>I would like to remove all the &quot;magic&quot; that&#x27;s built-in for specific SCMS&#x2F;repository hosting services and have something that operates in a simple and predictable manner like C includes and include paths (although obviously I don&#x27;t like preprocessing so not that).<p>As for the language, I like the range reference idea but my own minor pet peeve is an issue with pre-assignment in if-statements etc which makes a neat feature almost useless:<p><pre><code> &#x2F;&#x2F; This is nice because err only exists within the if so we don&#x27;t have to &#x2F;&#x2F; reuse a variable or invent new names both of which are untidy and have potential &#x2F;&#x2F; to cause errors (esp when copy-pasting): if err := someoperation(); err != nil; { &#x2F;&#x2F; Handle the error } &#x2F;&#x2F; This however won&#x27;t work: func doThing() string { result := &quot;OK&quot; if result, err := somethingelse(); err != nil { &#x2F;&#x2F; result does not need to be created but err does so we cannot do this. return &quot;ERROR&quot; } return result } </code></pre> I don&#x27;t have any good ideas about how to change the syntax unfortunately.

This is a great post, and I agree with much of what he said (range shouldn&#x27;t copy - I would love a range that iterates by const-reference by default, to lift a phrase from C++).<p>Deterministic select I hard disagree with. The code in the blog post is race-y, and needs to be fixed, not select. If anything, making select deterministic will introduce _more_ subtle bugs when developers rely on that behavior only to find out in the real world that things aren&#x27;t necessarily as quick as they are in development.

Proper sum types, if only for proper error handling. The if err != nil dance is extremely verbose and error prone with consecutive checks.

Mine would be a much larger collections library. Having come to go from Java and finding that the standard go library has no trees, no stack, no skip list, etc. was quite a surprise. Possibly the advent of generics will stimulate development of a more robust standard collections library.

&gt; Alternatively, Go 2.0 could implement &quot;frozen&quot; global variables<p>A more general change would be to implement the &quot;var&quot; and &quot;val&quot; distinction that exists in some languages.<p><pre><code> const x = 1 &#x2F;&#x2F; x is a compile time alias for the untyped abstract number 1 var x := 1 &#x2F;&#x2F; define x at runtime to be (int)1, x is mutable val x := 1 &#x2F;&#x2F; define x at runtime to be (int)1, x is immutable </code></pre> Then the globals can be defined with &quot;val&quot;.

I would like to add proper JSON5 support.<p>The template problem is a real problem. I used it once and it was pain and moved away instantly. I would vote for go inside go as a template system. So you can effectively write go code.<p>With the help of yaegi[1] a go templating engine can be build e.g here[2].<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;traefik&#x2F;yaegi" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;traefik&#x2F;yaegi</a><p>[2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;Eun&#x2F;yaegi-template" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Eun&#x2F;yaegi-template</a>

What I would like to see:<p>- Enun Types<p>- A special operator to cut down on `if err != nil { return err }` and just return at that point.<p>- Named arguments, and optional params with defaults<p>- Default values on structs<p>- ...macros? We already have `go generate .&#x2F;...`<p>( edit: Removed unformatted source code )

I would add: an extended standard library for &quot;common stuff&quot;. I don&#x27;t want to import a third-party library nor write my own &quot;utils.go&quot; to do:<p><pre><code> func contains(s []int, e int) bool { for _, a := range s { if a == e { return true } } return false }</code></pre>

Two Go 2 proposals that interested me were:<p>* nillability annotations: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;49202" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;49202</a><p>* Change int from a machine word size (int32 or int64) to arbitrary precision (bigint): <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;19623" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;19623</a><p>Sadly the nillability annotations were rejected because they weren&#x27;t backwards compatible. The bigint change is also unlikely to be accepted because the issue is already five years old and there are concerns about performance.

I would really love to see default parameters and struct values. I jump between Python and Go in my day job and Go is a much better language overall but things like this make it painful

A better template library would be a killer feature. Similar to what PHP has been since forever; the ability to write HTML using all the Go language&#x27;s features.

I&#x27;d like to see ergonomics improvements, particularly to function parameters.<p>The current best practice of &quot;functional options&quot; and long function chains results in far too many function stubs ... its a minimum of 3 extra lines per parameter. Parameter structs require a whole extra struct.<p>Suggestion: Just borrow named &#x2F; optional parameters from Python. It would cut down length and complexity of Go code drastically.

This was a surprisingly good list. Most of these kinds of articles just consist of someone bemoaning the fact that Go isn&#x27;t Haskell or whatever language they like more. But this is a legitimate list of things that could and should (in my opinion) be changed without turning Go into not-Go.

Oddly enough the list doesn&#x27;t resonate much with me.<p>I&#x27;d love to see better mocking support. Doing mock.On(&quot;fun name&quot;, ...) is so backwards, confusing and brittle. It&#x27;s also a great source of confusion for teammates when tests fail.<p>I miss better transaction management. I regularly juggle db, transactions and related interfaces and it&#x27;s a continuous pain.<p>Then there&#x27;s the &quot;workaround&quot; for enforcing interface implementation: _ InterfaceType = &amp;struct . This could be easily part of struct def. rather than having it in var section.<p>As was mentioned by others doing x := 5 only to later do JsonField: &amp;x is just a waste of intellectual firepower. Maybe this can be alleviated by generics but the lang should be able to make this a one liner.

I have much smaller ask struct type elision in function calls

The issue with the order of range seems like using the same name for satisfying a different requirement: in a template, you&#x27;re much more likely to want the value than the index, so it makes sense that a looping construct with a single parameter would be putting the value in that parameter. In a loop in normal code, you&#x27;re more likely to want to do math on the index. So, I&#x27;d say the problem is more about punning the name of these two behaviors than the behavior itself being bad.

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m <i>still</i> maintaining a sizable body of py2 code.)<p>“Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migrating code from go1 to go2 and how painful that’s going to be.

To expand on the logging improvements, I would like to see a `context.WithLogger` context function, to allow cross package passing of a common logger instance.

&gt; Go&#x27;s templating packages should support compile time type checking.<p>Does anyone know of a decent type safe templating package out there (for any language)?

My biggest annoyance so far is the inability (and inconsistency) to have a one-liner to get a pointer to something else than a struct.<p>I can write x = &amp;Foo{...} but somehow x = &amp;42 and x = &amp;foo() are not allowed, which forces me in some cases to declare useless variables that hurts readability.

I think Golang is awesome, but I have two major gripes that I hope can be fixed:<p>Dependency management:<p>Go mods is a dumpster fire. `go get` and `go install` is finicky and inconsistent across systems.<p>It&#x27;s difficult to import local code as a dependency. Using mods with replace feels like a shitty hack, and requires me to maintain a public repo for something I may not want to be public. I end up using ANOTHER hack that replaces mod references to private repos and I have to mess with my git config to properly authenticate.<p>I&#x27;ve never used another language that made it so difficult to import local code. Rust&#x27;s cargo is so much easier to use!<p>Sane dynamic json parsing:<p>Having to create a perfectly specified struct for every single json object I need to touch is terrible UX. Using `map[string]interface{}` is just gross.<p>Again, I think Go should copy the existing rust solution from serde. With serde, I define the struct I need, and when I parse an object, the extra fields just get thrown out.<p>If anyone thinks I&#x27;m misunderstanding something, please enlighten me. I hope reasonable solutions already exist and I just haven&#x27;t found them yet.

Hardly important but I hope that in parts of the std lib where they added support for contexts by adding a `FooContext` func for every `Foo` and latter just calls the former with `context.Background()`.. we can just have `Foo` that takes a context argument.

Can someone explain this one? I couldn&#x27;t see why go gave this result.<p>&gt; What is the value of cp? If you said [A B C], sadly you are incorrect. The value of cp is actually: [C C C]

Most important items in my plate<p><pre><code> 1. a unified improved *error* in stdlib with stack trace support. 2. a unified log interface(mentioned) 3. a STL library like c++ 4. shared library support so we dont have 100 static binaries that among them each have 90% of duplicated content. go shall support shared libraries&#x2F;modules officially.</code></pre>

About the optimization of the regex package: a talk is scheduled tomorrow [0] to FOSDEM 2022.<p>[0] <a href="https:&#x2F;&#x2F;fosdem.org&#x2F;2022&#x2F;schedule&#x2F;event&#x2F;go_finite_automata&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fosdem.org&#x2F;2022&#x2F;schedule&#x2F;event&#x2F;go_finite_automata&#x2F;</a>

I’ve heard Go program’s execution performance is near Java.<p>Is this true because I can’t think of anything more useless than that.

I want golang to stay as minimal as possible. I think of go as 2020s version of C. If you want all the madness of templating, reflection and (arguably) needless features can some privileged PhD student out there please make 2020s C++… go++?

Not go developer, just curious about the language and ecosystem and really like it. For me would be nice to have more functional features. For example - explicitly say that a variable is mutable &#x2F; immutable, preferably have immutability by default. Also native support for map&#x2F;filter&#x2F;reduce&#x2F;etc. Those are good abstraction and it is easier to read than `for loops`, since you don&#x27;t need to look over shoulders all the time. Guess latest would be easier to add since there is support for generics already.

What would you need those for? For checking exhaustive type switches? Seems like an extra keyword on &quot;interface&quot; would do the trick.