<pre><code>We need your help. Please tell us how Go is working for you, and more
importantly not working for you
</code></pre>
<p>So it seems that they wanna hear the community, let's make it! Starting from now, let's put here what features would you like for the new version of Go. I want every Gopher that reads this to post below a list of improvements with their personal preferences. This way they'll know what people prefer and what should be changed.</p>
<p><strong>The most common changes will be pinned here!!</strong></p>
<p>EDIT: RSC's post should be takken in consideration.</p>
<p><strong>Pinned posts:</strong></p>
<p><a href="https://www.reddit.com/r/golang/comments/6n4rqj/changes_you_want_for_go_20/dk7yn8t/">https://www.reddit.com/r/golang/comments/6n4rqj/changes_you_want_for_go_20/dk7yn8t/</a></p>
<hr/>**评论：**<br/><br/>rsc: <pre><p>I'm very sorry, but it seems you missed the main point of my talk / <a href="https://blog.golang.org/toward-go2">blog post</a>. We can't start with a feature list. We need to start with the problems Go 2 needs to solve. See the blog post for more details.</p></pre>slowratatoskr: <pre><p>obviously generics</p>
<p>edit:</p>
<p>lol why the downvotes? i mean, whats the point of Go2 if generics will not be included. </p></pre>gempir: <pre><p>Generics is an answer you need to bring the question </p></pre>to_be_deleted_soon: <pre><p>How can I write code that is easily applicable to many types?</p></pre>to_be_deleted_soon: <pre><p>How can we increase type safety?</p></pre>to_be_deleted_soon: <pre><p>How do I remove the vector of error where I have to manually change 10 methods when I want to make a change to all my type-specific implementations, that I copy-pasted to begin with but are beginning to become cumbersome to edit?</p></pre>to_be_deleted_soon: <pre><p>Why does the language contain generics to begin with (map)? Should we remove map?</p></pre>skztr: <pre><p>That's what I don't like: internals being treated specially. Internals get to be treated genetically, internals get to iterate. I don't even care about these issues as "I should get to do that, too!”, I just want consistent syntax, so that I don't need to ask, separately: ”how do I do this with a built-in type?" Or "how do I do this when I don't have a built-in type?"</p></pre>saturn_vk: <pre><p>How do I create a set as a library, so that arbitrary people can use it?</p></pre>4ad: <pre><p>You are not bringing any question to a table, you are proposing a solution to an unknown problem.</p></pre>Tyler11223344: <pre><p>I think you replied to the wrong comment?</p></pre>4ad: <pre><p>No, I did not.</p></pre>Tyler11223344: <pre><p>In what way was his comment not a question/problem?</p></pre>to_be_deleted_soon: <pre><p>Why has other modern languages had this feature for almost a decade? Perhaps this is a pointer as to the fact that it could be an appreciated feature? </p></pre>to_be_deleted_soon: <pre><p>How can we reduce code duplication and increase robustness and ease of testing? </p></pre>chuck7000: <pre><p>Nope</p></pre>kardianos: <pre><p>I think Russ was asking for:</p>
<p><code>2. Identify and explain a problem.</code></p>
<p>As in, "I was building a large system for running economic simulations and I found that the various and I found it difficult to share code between X and Y models. Here are some examples of what I was trying to do and why it was time consuming or error prone."</p></pre>Starz0r: <pre><p>Writing Dynamic Libraries (DLL/dylib) and Shared Objects (so), should be a first class feature in Go 2. Would allow me to drop C almost entirely.</p></pre>Kochie_94: <pre><p>Is there absolutely no way of doing this right now with go?</p></pre>Starz0r: <pre><p>There is the Plugin build mode, but it only works on Linux, and you can only load it in other Go code.</p>
<p>There is also a c-shared buildmode, but it's very hacky, and requires Clang or GCC, and also doesn't work on Windows.</p>
<p>So no, there is no real easy or native way to do it with Go right now.</p></pre>Kochie_94: <pre><p>Okay interesting, I've just started my golang journey. Looks like I'm in for some adventurous times.</p></pre>allowthere: <pre><p>One thing I want to point out to everyone (whether here or on HN) is that Go isn't C, it's not Rust, and it's not C++,Java,C#,Haskell, OCaml, or Javascript.</p>
<p>Go is <em>Go</em>. It has it's own culture and it's own way of doing things. By adding enums, Genrics, Functional paradigms, mandatory nil checking, and other features of Rust, you won't get a better Go. You get a worse Rust.</p>
<p>Yes, each could be nice on their own. Each could serve a purpose. I wouldn't mind generics, but, at the end of the day, if I wanted to program Rust, I'd use Rust[1].</p>
<p>[1]. And I do, for some hobby projects. It's not a bad language, and not that hard to learn if you just allocate on heap everywhere (no lifetimes - Yay!). And Rusts safety does have its uses (Yes, I'd be quite angry if my browser panicked because of a nil pointer). But many uses don't require that crazy level of stability (if my web-app goes down, log it and have systemd restart it), and <em>that's</em> where Go shines.</p></pre>sin2pifx: <pre><blockquote>
<p>You get a worse Rust.</p>
</blockquote>
<p>Why? They aren't features of Rust. Enums, generics and nil checking exist in e.g. TypeScript and Kotlin, and the first two in C++ and Java. And in those languages, you can program without using them.</p>
<p>I know many people don't like to have multiple ways to write the same. For generics, that's not an issue. And interface{} stays useful for cases where you want different types. Nil checking idem.</p></pre>allowthere: <pre><p>I'm not picking on Rust personally, it just happens to be seen right now as an "anti-Go" - compiled (unlike Java/C#), with a decent dependency system (unlike C++), came out around the same time, and (due to misunderstandings) is viewed as a "competitor". </p>
<p>But in reality, every language has its culture, and just as one wouldn't demand OOP from Rust, one shouldn't demand non-Go idioms in Go. It's not that they're <em>bad</em>, they just don't fit the language.</p>
<p>PS. (Not addressed to you personally, but more to the "let's ban Go" crowd on HN)</p>
<p>What I don't understand is the frequent "why can't Go be more modern" complaints. Go happens to be one of the more insular communities I found, which practices practically no evangelism. The culture seems to be one of "You like the language, use it. You don't, fine, use something else". </p>
<p>It's not a "corporate language" like Java or C# (where the more people use the language, the more money/visibility mother-ship makes). It seems right now that Dart is much more of "Google's language" than Go. </p>
<p>What happened was that a few engineers in Google made a language which would fit their needs, and open sourced it. They never <em>promised</em> generics, they never <em>promised</em> enums, they explicitly said that the language was meant for <em>their</em> use-cases. Don't like it? Doesn't fit your use-case? Can't accept their compromises? No one is forcing the language on anyone. </p>
<p>But guess what, people like it and use it. </p></pre>sin2pifx: <pre><p>Fine, but these features can make life easier. I like go's simplicity. It a sort of anti-C++. But I just don't think adding two or three features will make Go a worse Rust.</p></pre>dobegor: <pre><p>More low-level stuff in runtime and unsafe. I.e. bit backing.</p>
<p>The problem it would solve: it would allow creation of more low-level libraries for Go easily. I.e. implementing some old network protocol requires messing with bits. Bit backing would ease the process.</p>
<p>Generics. Problem: various places - containers, linked lists, more accurate type (de-)serialization.</p>
<p>DLLs (plugins). Seriously, c-shared build mode only works on Linux and Mac. Problem to solve: get rid of C/C++ for more use cases. Easier to create graphics applications.</p>
<p>Better error handling.
I don't think that Go needs and std GUI library, at least now.</p></pre>ops-man: <pre><p>A GUI library would be great. </p></pre>sin2pifx: <pre><p>A GUI library is an answer you need to bring the question</p>
<p>/s</p></pre>ops-man: <pre><p>Can Go bring its own GUI library to 2.0 without breaking existing code? </p></pre>hooluupog: <pre><p>Having a modern GUI framework to write cross-platform apps for android and ios(web and desktop,etc). I can do this in JavaScript nowadays but I prefer to do that in Go if possible.IMO,AOT compiled, GC optimized for latency and lower memory footprint make Go a good language for writing apps and even games.</p></pre>sin2pifx: <pre><p>Sure. I was paraphrasing criticism on the request for generics.</p></pre>Undreren: <pre><p>I sorely miss this. I don't want to use Qt or Gtk or whatnot to make desktop UI's. It's not very "batteries included", IMO.</p></pre>yami_odymel: <pre><p>Agree with this. It's really hard to see a GUI Application which is written in Go</p></pre>pinpinbo: <pre><p>Per RSC requests, here are most of real problems that my team had/have:</p>
<ol>
<li><p>There is a need for thread-safe collection data structure. <code>sync.Map</code> is a step in the right direction, what about <code>sync.Slice</code>?</p></li>
<li><p>There is a need for generic collection types. Just the other day we needed a generic typed Bloom Filter and Deque. I care less about true generics, but not having generic containers is a real problem.</p></li>
<li><p>Panic on close channel trips a lot of people. We are currently resorting in closing channel and assigning it to nil to avoid panics. But that's a hack. Maybe Go 2 can do away with this panic behavior.</p></li>
<li><p>The other day, <code>github.com/Sirupsen/logrus</code> library changed its name to <code>github.com/sirupsen/logrus</code>. That caused a lot of chaos in the community. It would be nice to have import alias to avoid this problem in the future.</p></li>
<li><p>How can we resolve vendor dependencies of our vendored libraries? Example: We vendored <code>github.com/aaa/bbb</code>. That thing vendored <code>github.com/zzz/yyy</code>. But we also use older version of <code>github.com/zzz/yyy</code>. Which <code>zzz/yyy</code> does Go pick? Perhaps vendoring can support tags/branches so we can pin-point the exact dependency. Example: <code>github.com/zzz/yyy:v1.3.1</code></p></li>
<li><p>We are copy and pasting same functions for <code>int</code>, <code>int64</code>, <code>float32</code>, <code>float64</code>. If generics is never going to happen, can we get a <code>Numeric</code> interface?</p></li>
</ol></pre>shark1337: <pre><p>Gonna pin it!</p></pre>metamatic: <pre><p>Re: 4, it'd also be nice to have an adequate core logging library so that people didn't all have to import their own logging libraries.</p>
<p>I wouldn't mind not getting full generics as long as we got parametric polymorphism. At least then we could write collection classes that worked with multiple types with the same methods.</p></pre>elagergren: <pre><blockquote>
<p>generic typed Bloom Filter</p>
</blockquote>
<p>Curious about this one? What types would need to go in it other than string/[]byte? Integers?</p></pre>mit53: <pre><p>integers or simple structs, basically any type that can be a map key</p></pre>Kraigius: <pre><p>Go needs a good dependency manager to be part of the standard toolset.</p>
<p><em>cross fingers for dep</em></p></pre>myselfNobody: <pre><p>+1</p></pre>whistlin3: <pre><p>Generics :)</p></pre>NOLAnuffsaid: <pre><p>Yes!!!!!!!!!!!!!!!!! omg Yeeeesssss</p></pre>slowratatoskr: <pre><p>yup, so that we dont have to use <code>interface{}</code></p></pre>shark1337: <pre><p>I'll start with the following:</p>
<ol>
<li>Better vendoring system. No more rules, just let me import my package like a node module.</li>
<li>Mobile support, one great thing that Go is missing..</li>
<li>More lower level features that doesn't require c binding.</li>
<li>Faster JSON parser.</li>
<li>GUI Standard Lib!</li>
<li>Performance much closer to c/c++</li>
</ol></pre>ask: <pre><p>Which of those require language changes?</p></pre>skztr: <pre><p>A better vendoring system would probably "look like" the current language, but definitely wouldn't be "the same thing". Ideally, the GOPATH variable shouldn't be a thing (except as an override for a sane, project-specific, default), for example. That's a different that, while it would arguably not be a "language change", would definitely involve a major version bump.</p>
<p>I current do all my go builds within docker containers. That's fine, I suppose. But it's stupid. It's a work-around. I shouldn't need to mock an entire Linux environment just for a modest amount of build sanity. I know that system-wide libraries are a cruft inherited from go being "c, but, you know, not as stupid", but they obviously hated that aspect of c when they decided to make it use static linking by default. The idea that libraries aren't entirely project-specific without jumping through hoops is just absurd. If you want a system-wide (or user-wide) cache, that's fine. That's what literally every other modern vendoring system already does.</p></pre>mixedCase_: <pre><ul>
<li><p>Generics.</p></li>
<li><p>Union types (with pattern matching). Also called algebraic data types and what Rust calls "enums".</p></li>
</ul></pre>diegobernardes: <pre><p>This are my dream, would make Go just, perfect.
Some kind of immutable would be nice too, it can help eliminate data races and help constructors (referential integrity). </p></pre>elagergren: <pre><p>Among many other things, one thing not mentioned here that I'd like is better constants (a la constexpr) or the ability to mark types as read only, even if they have to be instantiated at runtime.</p></pre>metamatic: <pre><p>Honestly, I'd like to see all variables and method arguments be immutable by default, with some sort of annotation to make them mutable.</p>
<p>But I know that'll never fly with the Go dev team, so I'm not even gonna propose it.</p></pre>dlsniper: <pre><p>This is a terrible, out of context, thread. </p>
<p>Russ was very clear in his talk, the community has a voice, but the voice has to be coherent, it has to show why those changes are needed, what are the use cases, pain points they currently present. </p>
<p>Some of the changes will be accepted, others won't. Some will have to wait a while until a clear case made for the request.</p>
<p>Some of the changes will be language changes, some will be tooling (either existing or new tooling). </p>
<p>Go 2.0 will not happen any time soon. It will be a gradual process, with the desire to keep the compatibility with the current code as much as possible. When that won't be possible anymore or when those changes will bw in a stable state, maybe a Go 2.0 release will be cut.</p>
<p>The changes won't also be too many, just a few of them, important ones, for which clear cases are made. </p>
<p>Currently this thread and the replies to it are so far off it shows the disconnect between simple users and those that actually can present a case for a problem and have the Go team recognize it as an issue. </p>
<p>Please wait for rhe video of the talk before you jumping in head first, without putting any thoughts into your requests and why you need them. The more details, clearly described, the better.</p></pre>DeedleFake: <pre><p>Generics. Duh. I am certainly worried about the complexity that badly done generics could add, but they are absolutely necessary for any kind of decent abstraction that's tied more to functionality than data format. Interfaces do this to some extent, but they're too limited for a lot of uses, and a lot of their functionality is implemented at runtime, which has some, minor though they may be most of the time, performance implications. Personally, I'd kind of like something that's used similarly to Haskell's type classes, where you could essentially declare limitations of accepted types based on functionality. So, for example:</p>
<pre><code>generic Addable(a) {
oper +(a) a | func Add(a) a
}
func sum(a ...Addable) {
// Do something. I'm not quite sure how you'd be able to pick if it's using + or
// Add(). Might need some kind of function overloading.
}
</code></pre>
<p>Also, I'd really like a revamp of channels. A lot of the things I want, such as infinite buffers and broadcast channels, could also be done through generics potentially, but, either way, I'd also like a cleaner way of doing M:N channel systems, instead of just the 1:1 systems that channels are primarily designed for now. In particular, I'd like a cleaner way to signal multiple producers to stop sending, although that was partially fixed by the addition of the <code>context</code> package.</p></pre>skztr: <pre><p>Just to throw a wild one out there (that I don't really think is a good idea):</p>
<p>The ability to mark return values as "important", ie: can never be discarded without being assigned to a variable (and based on other go semantics, implicitly the requirement that the variable be used for something). The ability to easily discard the error status of a function without checking it is a bug, not a feature, of the language. I, personally, think "exceptions" are the only sane way of handling errors: ie, do something which says you either need to deal with it, or give it to somebody else who will deal with it, and if that doesn't happen your program dies because the state of it can no-longer be trusted. But mixing "code that uses exceptions" with "code that doesn't use exceptions" is always lethal. "important" parameters would give us a path towards sanity.</p>
<p>(if you want to allow people to "ignore" errors, make a <code>Must*()</code> variant, that panics in the event of an error)</p>
<p>To be less exception-centric: some things require cleanup code (eg, <code>.Close()</code>) to be called on them to prevent, for example, dangling channels. These are also important, and should never be discarded, but it's currently perfectly legal to do so.</p></pre>ksion: <pre><p>If you're looking for existing examples of the "important" return value, the <code>#[must_use]</code> annotation on the <code>Result</code> type in Rust is basically this.</p></pre>skztr: <pre><p>Thanks! I didn't know about this</p></pre>Saethgokk: <pre><ul>
<li>Standard official debugger. (not delve or gdb);</li>
<li>More low level features;</li>
</ul>
<p>I'm sick of this :</p>
<pre><code>*(*type)(unsafe.Pointer(uintptr(ptr) + uintptr(offset))) madness.
</code></pre>
<ul>
<li>Good well written standard documentation for the Go assembly;</li>
<li>Generics;</li>
</ul></pre>fakeNAcsgoPlayer: <pre><p>How about eliminating empty interface penalty. Reflection costs to almost none. </p>
<p>Maybe improve the C FFI a lot faster. Not everything is go out there when it comes to performance. </p></pre>tmornini: <pre><blockquote>
<p>We need to start with the problems Go 2 needs to solve</p>
</blockquote>
<p>I'd like to avoid the need to create getters and setters, avoiding a <strong>ton</strong> of boilerplate.</p>
<p>Of course, without getters and setters, I cannot define an interface to create polymorphic functions.</p>
<p>A solution would be a type that allows the definition of exported fields and types that would allow any structure with said exported fields to be received and/or returned by a function.</p></pre>metamatic: <pre><p>Getters and setters are also where I find the lack of parametric polymorphism <em>really</em> annoying. I end up with <code>SetFromInt</code>, <code>SetFromString</code> etc.</p></pre>forfunc: <pre><p>I'm writing distributed systems in Go and often find the need for immutable data structures. That is all I really need.</p></pre>edsonmedina: <pre><p>Stop the $GOPATH nonsense.</p></pre>jfurmankiewicz: <pre><p>Difficult to adopt Go in a locked down corporate environment, due to its insistence on pulling dependencies directly from git, instead of artifacts.</p>
<p>This is unlike dep mgmt in all other modern languages (Java = Maven/Gradle, Rust = Cargo, Ruby = Bundler, Python = pip).</p>
<p>Makes SOC2 compliance really hard.</p>
<p>Recommendation I got from Go experts was to check in dependency source code directly into our project. That generated laughter from my existing Java devs. </p></pre>_mattlondon: <pre><p>Code duplication to work around the type system is the biggest pain for me, e.g. when handling database queries to get entities from a database (i.e. classic web backend stuff) we have to repeat the same function that is 99% identical to all the others functions in the package, but just use a different type from each other.</p>
<p>This was highlighted perfectly by this twitter post: <a href="https://twitter.com/yogthos/status/883058510275149826" rel="nofollow">https://twitter.com/yogthos/status/883058510275149826</a></p>
<p>The "solutions" of reflection and writing self-generating code just don't really work for the teams I am working in (i.e. loosely-coupled, distributed teams working semi-independently on the same codebase). These approaches require too much coordination & maintenance and are too brittle and easy to break. There are some third party libraries that abstract away the database stuff sure, but a) the database example is an example (i.e. this occurs with non-database code too), and b) not all databases can use the common third party libraries for various reasons.</p>
<p>Right now the copy-paste approach that appears to be the de facto "work around" has its own problems by people just blindly copying chunks around without double-checking what they are copying which can lead to subtle bugs if the logic is not checked.</p>
<p>I dont really care what name is used ("generics" or otherwise), but <strong>some way of allowing a method to operate on objects of various types while providing compile-time type safety</strong> would make my life in Go a lot nicer.</p>
<p>In my experience of working with people who are coming to Go but are used to other languages, the lack of a way to operate on objects of various types whole providing compile-time type safety is a <em>major</em> stumbling block to them getting up to speed. As mentioned in the blog post, it is hard to "unlearn" the more sophisticated type systems from other common, widely used languages so people struggle getting their head around Go.</p></pre>adelowo: <pre><p>removal of named return values.</p></pre>saturn_vk: <pre><ol>
<li>Some kind of generic support. Even the stdlib needs this. </li>
</ol>
<blockquote>
<p>func (s *set) Put(value T) where T is io.Reader, io.Writer</p>
<p>type Node struct { value T } where T</p>
</blockquote>
<ol>
<li>Sum types would be quite useful, especially in certain places of the stdlib, like the ast.</li>
</ol>
<blockquote>
<p>type Type sum { Array ArrayType, Map MapType, ... }</p>
<p>switch v:= typ { case Array: ... }</p>
</blockquote>
<ol>
<li>I've wanted for quite some time for "extension" methods to exist. Packages like "strings" or "bytes" can be reimplemented, so that once imported</li>
</ol>
<blockquote>
<p>"Foo".HasSuffix("oo")</p>
</blockquote>
<p>Would be valid</p></pre>Kraigius: <pre><p>I got to say, expvar is kind of cool.</p>
<p>However, I'm a bit annoyed that not only it automatically register both memstats and cmdline but there's no way can unregister any metrics. If you don't want to expose those metrics there's nothing you can do.</p>
<p><em>edited grammar</em></p></pre>metakeule: <pre><p>Why not taking something out of the language? What are the problems "goto" was supposed to solve?</p></pre>YEPHENAS: <pre><p>They are useful for code generation.</p></pre>muehsam: <pre><p>One thing that has always bugged me was <code>uint32</code> and <code>rune</code>, as well as <code>uint8</code> and <code>byte</code>, being identical. Until recently, there was no other way that two differently named types could be identical, and I still think alias types should be used sparingly, if at all.</p>
<p>They're also semantically different: <code>uint32</code> and <code>uint8</code> are just numbers of a specific size, there is no reason why it should be possible to cast a slice of them into a string, or the other way around, or even weirder, why you can cast single one of them into a string but get the respective Unicode code point. However, for <code>byte</code> and <code>rune</code>, those results are what you'd expect. Similarly, one would expect <code>fmt.Print('A')</code> to output an <code>A</code>, when it in fact prints <code>65</code>.</p>
<p>They should of course still be castable, and you should still be able to do arithmetic with <code>byte</code> and <code>rune</code>. But I think there is little gained from treating the types as aliases, as most programmers probably know if they want to use their variable as an unsigned number, a Unicode code point, or a raw byte.</p></pre>hbonly: <pre><p>not work on no fpu arm
need standard gui
can not build bundle work as iphone lib</p></pre>gopher1717: <pre><p>Final variables. Useful for types that aren't allowed as const</p>
<pre><code>var final ErrNoRows = errors.New("sql: no rows")
</code></pre>
<p>Of course, this would be allowed in any context, not just in global variables.</p></pre>myringotomy: <pre><p>It's remarkable to me that most of the things people want added are already in Crystal.</p></pre>slowratatoskr: <pre><p>you have a good point but as far i know Crystal has no real parallelism</p></pre>myringotomy: <pre><p>It has go style channels but true multithreading is still in the pipeline.</p></pre>slowratatoskr: <pre><p>i hope it succeeds. its a nice language</p></pre>shovelpost: <pre><p>I am pretty sure the millions of Crystal developers will be delighted.</p></pre>shark1337: <pre><p>Yeah, but Crystal is still a new language. I'm loving it as well :)</p></pre>kaeshiwaza: <pre><p>What make the simplicity of Go, what we have or what we don't have ?</p></pre>opiniondevnull: <pre><p>On the generics front, Typescript really does this so well and seems to make sense in the overall Go view of simplicity. Interfaces can be used both for data and for functions. Most of the time when using it for data you greatly remove the overhead of converting and just say "I need a struct with an string named A and a array of ints named B". Any struct that has that matches and greatly simplifies readability.</p></pre>funny_falcon: <pre><p>I want "slice with sliced capacity" to become default, ie <code>a=b[x:y]</code> to be equivalent to <code>a=b[x:y:y]</code></p></pre>edsonmedina: <pre><p>Exceptions.</p></pre>allowthere: <pre><p>I'll answer in a classical "Go"-like answer[1]:</p>
<p>Can we remove closures?</p>
<p>Closures are nice when order of execution doesn't matter. For example, if</p>
<pre><code>A()
B()
C()
</code></pre>
<p>isn't guaranteed to happen in any particular order (or happen at all - by lazy), closures are great (because you don't look at order anyways). But in Go, it gets confusing. For example:</p>
<pre><code>MyStruct.Prepare(func(){fmt.Println("B")})
fmt.Println("A");
MyStruct.Do()
</code></pre>
<p>would print A and then B, opposite of what the simple reading would show. This seems like a strangely "functional" feature in imperative-land.</p>
<p>[1]. Yes. I know it ain't happening for many reasons. But let's put the idea out there</p></pre>qaisjp: <pre><p>Why? Just don't use closures if you can't understand them</p></pre>allowthere: <pre><p>I "understand" closures. It just doesn't "read" well</p></pre>qaisjp: <pre><p>It works fine in languages like Lua and JavaScript, and Go isn't that different in syntax.</p></pre>nevyn: <pre><p>Your example has nothing to do with closures, Eg.</p>
<pre><code>MyStruct.Prepare(fmt.Println, "B")
fmt.Println("A");
MyStruct.Do()
</code></pre></pre>shark1337: <pre><p>Haha, I was thinking the same from the first time</p></pre>
