[AMA] We are the Go contributors: ask us anything!

Russ (<a href="/u/rsc">/u/rsc</a>) and I thought that a fun way to celebrate the <a href="https://blog.golang.org/go1.6">1.6 release</a> would be to have the Go contributors answer questions from the community. You can identify contributors by the little gopher beside their name. <del>A bunch of us will be here answering questions for the next 24 hours.</del> Update: Thanks everyone for asking so many great questions! We're still working on answering them all (all of them asked before <a href="https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d05bqot">this post</a>), but we will get there. We have to stop taking new questions now, sorry! :-) Thanks again! <hr/>**评论：** dlsniper: <pre>Hi all, Congrats on the 1.6 release. I have two questions to ask: <ul> <li>when will the Go team focus a bit more on the debugging side of things and help the current debugging efforts lead by Delve to get the information it needs in order to produce a better experience. Could this be addressed in 1.7?</li> <li>would you be open to changes in the Go vendoring with regards to the various issues which are yet to be addressed in 1.6 (as an example the whole go test ./... which should exclude vendors, or include it if a flag is sent)</li> </ul> Looking forward for your answers. Thank you!</pre>ianlancetaylor: <pre>The debugging issues on the compiler side will be affected by the new SSA compiler that may become part of 1.7. I don't know that anything will be noticeably better in 1.7, but I think we will be in a better position for improvements in 1.8. As you know this has not been a priority of the core Go team. We are very much aware of the issue, but the fast compilation time in Go means that we have mostly gotten accustomed to a build/log/run cycle while working, rather than a build/debug/run cycle. So while I would certainly like to see this get better, and I'd be happy to support anybody doing the work via code reviews and the like, I can't promise that it will get better.</pre>elazarl: <pre>I really think that you do not address the real need for a debugger. No one needs debugger during development cycle. Nice thing to have, but as you said, if you don't have insane compilation speed you should be OK. Everyone needs debug desperately for production apps that fail in unusual ways, and one want to take a look a the coredump, grab a critical piece of data from a process that can't be restarted, etc. Have a look at Joyent's blog for their usage of mdb in production. I'm not having an opinion of what the Go roadmap should be, but I personally don't mind this for my Go hobby usage, but if I'll use that in production I'd better have debugger at the hand.</pre>rsc: <pre>Re Delve, our plan is to <a href="https://groups.google.com/d/msg/golang-dev/TerfinvPffw/2gUIkUg3AAAJ">work with Derek Parker</a> this cycle to fix these issues. In addition to that public message I've exchanged emails with him off-list. We should be able to make this happen. Re vendoring and wildcards, that's a contentious issue, and there are reasonable arguments on both sides. I'll explain my view below; please see <a href="https://golang.org/issue/11659">issue 11659</a> for additional discussion. One of the important early criteria for Go was that features be orthogonal; what that means to us is that if you use independent features A and B you get the effect A+B, not something with unexpected interactions or special cases. In this case, I personally believe that package wildcard pattern matching and vendor trees are independent features, and therefore one should not affect the other. The wildcard syntax is about traversing the file system to find packages matching that wildcard. The pattern <code>./...</code> matches <code>./foo/x</code> and <code>./bar/x</code>. Why should <code>./vendor/x</code> be a special case? That is, why should wildcard pattern matching have an unexpected interaction with vendor trees? The most compelling answer given is "because I don't want to run those tests every time," but that's still pretty difficult to accept as a reason for introducing such a non-orthogonality. An alternative way to address the "I don't want to run those tests every time" question would be for the go command to do a better job caching test results, so that if you haven't modified any code that might affect the tests, a second "go test ./..." will not re-test them. Done right, test caching would benefit nearly all use of Go, not just the single case of vendor directories. But it's a tough problem on its own, because you have to identify every possible "input" to a test, including things like test data files and maybe even environment variables. I took a stab at this in <a href="https://godoc.org/rsc.io/gt">rsc.io/gt</a> but it's a large topic, and I haven't returned to it. Until test caching is done right, a simple workaround if you want to exclude vendor (or any other) directories is to replace <code>go test ./...</code> with <code>go test $(go list ./... | grep -v /vendor/)</code>.</pre>yeoldgo: <pre>Looks like delve recently added Windows support! <a href="https://github.com/derekparker/delve/wiki/Building#windows" rel="nofollow">https://github.com/derekparker/delve/wiki/Building#windows</a> Sorry if I shouldn't have distracted from the discussion, but this is good news for people using windows!</pre>nyoungman: <pre>What is the benefit of the SSA compiler that golang-dev is always talking about for a future release?</pre>ianlancetaylor: <pre>Better run-time performance.</pre>broady: <pre>It will enable some future compiler optimizations, resulting in smaller binary sizes and better performance. khr says, in his <a href="https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0/edit">design doc</a>: <blockquote> Total guesstimate, I think it would be fairly easy to make the generated programs 20% smaller and 10% faster. </blockquote> I'm not sure if that estimate still stands :)</pre>4ad: <pre>I think that estimate is extremely conservative.</pre>4ad: <pre>One benefit would be that SSA is much easier to optimize in theory.</pre>cahooon: <pre>I have loved reading the sleuthing & design analyses written in emails and CL summaries by rsc, khr, dvyukov, bradfitz, et al, over the years. It's been a real education. I remember the "simpler, faster GC" cycle was a particularly interesting and intense session. Any especially interesting design/debugging stories, recent or old, you might share? I figure some never made it to the mailing lists but perhaps circulated in smaller groups. </pre>rsc: <pre>When I first joined the Go team (in mid-2008), one of the warnings I was given was never to copy a built Go tree from a Linux server onto my Mac desktop. At the time, builds were by hand or barely automated with make, so it was easy to forget to rebuild something. And if you accidentally made an OS X system call with a Linux system call number, the OS X kernel would die and your machine would gray screen and reboot. The fact that Go object files now all have os+arch+version in their headers and that the linker insists they all match when creating an executable is a direct result of this kind of problem. I don't know if the OS X kernel is still that brittle. I hope not.</pre>4ad: <pre><a href="https://github.com/golang/go/issues/13854">Go can find CPU bugs</a> (ok, this bug was know by the manufacturer, so it wasn't discovered by Go, but still, it can find them!).</pre>bradfitz: <pre>Before the migration to Github, I used to actually have a label on the issue tracker for cases where Go exposed OS bugs. There were a number of them, which surprised me for a while.</pre>enneff: <pre>Turns out a lot of kernel maintainers were not expecting anyone but libc to make system calls (I'm looking at you Darwin!).</pre>mdempsky: <pre>To be fair, most OSes develop their kernel and userland in tandem, so that's not an unreasonable expectation. The Linux kernel is rather unique for being developed independently and having a stable kernel ABI.</pre>bradfitz: <pre>You still shouldn't be able to panic the kernel from userspace, stable ABI or not. :)</pre>hegbork: <pre>Apple have based their kernel on ancient BSD code and aren't very good at keeping up with the trends. Want two kernel crashes for Darwin? I have one that I tested that it worked two versions ago and I have one that I haven't tested yet, but I'm pretty sure I can exploit. I've never managed to figure out how to contact Apple, so they remain unfixed. Both of them were fixed in the kernel I used to work in 10-15 years ago. The dirty secret of kernel development is that user triggerable crashes are fixed unannounced every few months. Kernel is a beast and it's hard to get all the edge cases right. But it doesn't help that Apple doesn't seem to care.</pre>ianlancetaylor: <pre>In the 1.6 release cycle I was quite surprised to discover that on NetBSD and DragonFly a newly created thread inherits the signal stack of the creating thread. That took a while to figure out.</pre>bketelsen: <pre>Gophers! Are there any plans to make context a first class citizen in net/http? Would be awesome to have stdlib mux be context friendly. PS. Thanks for the AMA!</pre>dsymonds: <pre>It is planned for context to be in its own package, net/context, in Go 1.7. The net/http package should mesh with it well in a few places (e.g. request cancellation), but won't be able to integrate with it fully due to backward compatibility.</pre>Akkifokkusu: <pre>Could that include adding an exposed <code>Context</code> field to <code>http.Request</code>? Or would that be considered backwards-incompatible?</pre>dsymonds: <pre>Adding fields to an existing struct is backward compatible, so it's a possibility.</pre>seufert: <pre>Some suggestions/wishes from my side: <ul> <li>Is see the subrepos under golang (for example golang.org/x/tools) growing and from time i find some really cool stuff there - but mostly by accident. Any chance that there will be better documentation/communication/overview on them?</li> <li>Still i find the database/sql one of the weak points of Go, but there does not seem to be much activity around. Any chance for improvements? For example more sql.Null... types? Often it's not clear that DB-Type should/could be scanned into what. It differs much from driver to driver. I think a stronger core would help. Any plans there?</li> </ul></pre>enneff: <pre><blockquote> Any chance that there will be better documentation/communication/overview on them? </blockquote> Yes, certainly. <a href="/u/broady">/u/broady</a> and I are hoping to improve the doc situation in the next few months.</pre>rsc: <pre><a href="/u/bradfitz">/u/bradfitz</a> may have more to say about database/sql. I know the driver story in particular is a bit of a weakness. It would be nice if it was clearer what the standard set is and if they were more clearly consistent.</pre>hipone: <pre>Hey Go Team, Gophers Congrats on the 1.6 release! One of Go developers said sometime ago on Twitter [0] you're developing some tooling for context.Context - is this still the case? Will it be publicly available? [0] <a href="https://twitter.com/Sajma/status/494161985219465217">https://twitter.com/Sajma/status/494161985219465217</a></pre>dsymonds: <pre>Yes, it's still in development. It's built on Alan Donovan's go/types work, which has only relatively recently stabilised.</pre>ianlancetaylor: <pre>I'm just going to comment that go/types itself is mainly Robert Griesemer's work, though Alan has written many tools around it, notably guru (formerly called Oracle).</pre>dsymonds: <pre>Yes, sorry, I really meant the work around go/types (e.g. go/ssa and friends).</pre>cahooon: <pre>I have gathered that code review is a huge amount of the job at Google. So, since you have to translate your gut feelings about how to write good Go into text in code reviews, I imagine that a lot of implicit/intuitive knowledge ends up having to be being communicated fairly frequently, and in clear enough terms to be useful. How has your intuition for good Go design changed over the years? What kinds of habits do you try to train into new Go users whose code you are reviewing? (The stuff that hasn't made it into docs like Effective Go and the Tour). Stuff like package boundaries, use of channels for coordination, patterns you've noticed around handling errors well (and throughly). That sort of thing.</pre>ianlancetaylor: <pre>This is a good question and I don't have a short answer. Programmers new to Go often use channels way too much or way too little. Some misunderstand slices--<a href="https://golang.org/blog/slices">https://golang.org/blog/slices</a> is a great resource. It takes a while for people to understand how and when goroutines terminate. People often don't realize that close on a channel is not necessary, and that it is purely a send operation.</pre>crawshaw: <pre>Here is a set of common code review comments that have come up inside Google over the years: <a href="http://golang.org/wiki/CodeReviewComments">http://golang.org/wiki/CodeReviewComments</a></pre>dsymonds: <pre>Yes, our intuition has certainly developed over the last 8 years or so. We publish a bunch of things on the Go blog (e.g. <a href="http://blog.golang.org/package-names">http://blog.golang.org/package-names</a>, <a href="http://blog.golang.org/errors-are-values">http://blog.golang.org/errors-are-values</a>, <a href="http://blog.golang.org/constants">http://blog.golang.org/constants</a>), as well as places such as <a href="https://golang.org/s/style">https://golang.org/s/style</a>.</pre>Dieter_be: <pre><a href="http://blog.golang.org/profiling-go-programs">http://blog.golang.org/profiling-go-programs</a> said "The goroutine blocking profile will be explained in a future post. Stay tuned." any news on this? every time i try to use the blocking profiler I get stuck. The original profiling article was great and I'ld love a followup. is the blocking profiler ready for widespread use?</pre>rsc: <pre>I guess that's the problem with trying to predict the future. We clearly haven't written that post yet. What do you mean by "I get stuck" regarding the blocking profiler? We do believe that the blocking profiler does what it is advertised to do, because there are tests for it. That said, I have never found the profiles particularly useful, and maybe that's what you meant by "I get stuck". To me, the fundamental issue is that what you really want is to distinguish good blocking (like a goroutine waiting for the next network request; that time is not the application's fault) from bad blocking (like excessive delay due to mutex contention). It's difficult to do that without some knowledge of the application, although perhaps we could do better by having just a mutex contention profile; that would be most useful if all the other kinds of blocking are "good" for your program. </pre>Dieter_be: <pre>with get stuck i mean i can't get it to work and people trying to help me are not sure what the problem could be. I've also received inconsistent advice on which frontends to use to analyze/view the results. recently i tried it again and the block profile just contained two lines: <code>--- contention: cycles/second=2300001382 </code> any recommendations for a good howto/documentation? last time i'm pretty sure i followed the docs and still couldn't get it to work, admittedly that was a while ago, hopefully i'll have more luck this time. thanks. BTW agreed on "good" blocking vs "bad blocking" but even for channels it seems useful, i can usually find out quickly which channel blocks are okay and which are bad. thanks!</pre>nosmileface: <pre>Hello. I'm using Go for web development and that's may day to day job, I'm happy about it. But my hobby projects usually have something to do with graphics (games) and this is one of the areas I have hard time even trying to use Go and these are the reasons why. But before I describe the reasons I want to mention that I use C++ and C# (via mono) instead. My question is what do you think about the problems I mention, maybe I'm even wrong about them and if there is anything that can be changed in Go to make it easier to do what I'm trying to do. <ol> <li>First problem is that games are slightly different from any other applications. If you take a web server for example you just make it so that it handles as much requests as possible and if it cannot handle more or the response time becomes too low, you scale hardware. With games you cannot do that, gamer has always a fixed set of hardware and you have to design your program in such a way that it is able to select which things to do. And this is where Go becomes problematic to use as there are no goroutine priorities and you cannot really schedule goroutines on your own. Well, you can do something, invent some protocol and talk to a scheduler via channels or something like that, but it's not free performance wise. So, that's problem number one. Goroutines is a nice abstraction, unless you want slightly more control. For example I would like to be able to execute all I/O goroutines on a single dedicated thread with specific OS priority. It becomes even more important on OSes with bad schedulers (such as ms windows). I mentioend I use C#, there I just make my own coroutine system with generators (i.e. yield). Stackless coroutines become rather popular in many languages these days. Python added async/await in 3.5, C++ will get stackless coroutines very soon it seems. One of the advantages of stackless coroutines over goroutines is that they are first class citizens and you can do whatever you want with them. Is there a change we get stackless coroutines in addition to goroutines in Go? I understand it's a weird question though.</li> <li>And second problem is interaction with C APIs. We all know that overhead of a C API call in Go is rather large, but graphics APIs due to their proprietary nature will always be in a form of shared libs. OpenGL is already known and khronos recently released the new Vulkan API. Yes, vulkan shifts everything slightly towards more structured approach (you manage more state on your own), but still a plenty of cgo function calls are expected. Is there a change that we'll see some improvements in that area? For example escape analysis annotations when it comes to cgo functions. I know you guys think it's evil and all, but what other practical solution can we do? Also gaming is traditionally heavily middleware-based, same problem. Lots of C API calls. The problem gets worse when you combine it with problem number one. I can't really call C functions from goroutines right now as this action spawns threads like crazy. Scheduler is smart, but it thinks every cgo call potentially blocks. And what's worse, that's exactly my use case right now. Because C compilers are the best when it comes to optimizations, I use a high level language (C#) to do coroutines and work scheduling, but the actual work is done in C/C++ code. As a result the way Go scheduler works is just not acceptable for me and I use mono (not the most lightweight platform, but it works sort of).</li> </ol> So there. Sorry for a bit vague description, but these are my problems with Go and I would like to know what Go contributors think about these problems. Given Go's amazing garbage collection and a much better SSA-based compiler optimizations (not completely there yet) it all makes Go an attractive language for games, but...</pre>kunos: <pre>sadly no answer to this, I came to ask the same. It would be nice to have a way to call C without incurring in thread creations, we'll still paying for the stack reconfiguration but it could get much better than now and open the gates to a different use of Go (games).</pre>Hencq: <pre>Congrats on the release! The move to rewrite the compiler in Go itself initially led to an increase in compile times in Go 1.5. The expectation was that this would be gradually reclaimed as the Go codebase would be optimized. Can you comment on how far along this reclaiming effort is as of 1.6 and are there any big wins on the horizon for the 1.7 roadmap?</pre>ianlancetaylor: <pre>My understanding is that compile speed in 1.6 is pretty much the same as 1.5. For 1.7 we hope to get the SSA compiler in, but the plan is to only do that if compile speed does not increase. There are also some plans for a new parser and a new representation of export data and of the object file format, all of which should improve compile times. I don't know that 1.7 will back to the 1.4 compile speed, but that is certainly the goal.</pre>breakingcups: <pre>How involved are the original creators of Go today? If absent, do you feel the original philosophy is still being well-guarded in practice?</pre>ianlancetaylor: <pre>Ken is doing very little Go related work these days. Rob is working in Go but has been doing less work on the standard tools and libraries--he is still contributing, but less. Robert is still working on Go full time. Personally I think the original philosophy is still well supported.</pre>enneff: <pre>Robert and Rob are still actively working on the project. Ken is pretty much retired, but still gets pulled in to the odd design discussion. I'll let them say how they feel about the original philosophy. My take on it is that Go is still very true to its design goals.</pre>djhworld: <pre>What editors do the Go team use when writing Go? I used to be staunchly anti-IDE, but I've come around to the idea nowadays as I've gotten older, haven't seemed to be able to find a decent Go IDE though. </pre>dsymonds: <pre>Most people use Vim, Emacs, or an editor they wrote themselves. A few use Sublime Text these days too.</pre>bketelsen: <pre><blockquote> or an editor they wrote themselves </blockquote> <3</pre>rsc: <pre>For the past fifteen years or so I have used Rob Pike's editor acme. Rob wrote a <a href="http://9p.io/sys/doc/acme/acme.pdf">paper about it</a> (PDF; or <a href="http://9p.io/sys/doc/acme/acme.html">html</a> but the reformatting is not perfect). Acme is very difficult to understand without seeing it in action. It's an integrated environment but not the usual kind. A few years ago I recorded a <a href="http://research.swtch.com/acme">screencast of what it's like</a>. Acme originally required Plan 9 but now it runs on <a href="https://swtch.com/plan9port">basically all Unix systems</a>. Rob and I run it mainly on Linux and OS X these days. While I still use acme every day for nearly all my work, I'm starting to believe strongly that the answer to text editor or IDE is neither. Those are fundamentally single-user systems. What we really need is a work environment that understands that people work together. A group of people can work interactively on a Google Doc in real time but not on a program. That seems wrong. And when you're done there's no guarantee of a clear log of what you did so that someone else can follow along or reproduce your work. That also seems wrong. Those are the kinds of improvements I'd like to see in whatever I use for the next fifteen years.</pre>enneff: <pre>I use Vim with <a href="https://github.com/fatih/vim-go">vim-go</a>.</pre>broady: <pre>I think most people on the Go team use pretty no-frills editors. I use vim, and you can see my <a href="https://github.com/broady/dotfiles/blob/master/vimrc">vimrc here</a>. For work in the Google codebase, we have excellent tools available for code search, which is a large part of why IDEs are useful.</pre>tdewolff: <pre>Great work on the 1.6 release, congrats! There have been some really good improvements to the GC in Go 1.5 AND in Go 1.6, especially for large memory usage. Garbage collection times have been significantly reduced. What has lead to those big improvements? What design decisions make the GC for Go so much faster? How different is this from Java's GC? And most interesting, what ideas and improvements are taken into consideration for future releases?</pre>aclements: <pre>The fundamental change in Go 1.5 was that we replaced the stop-the-world garbage collector with a collector that does almost all of its work concurrently while the program runs. Rick's talks give a great overview of how that works. Go 1.6 is still using the same basic algorithm; the wins come from lots of smaller improvements. The garbage collector still pauses the program briefly at the beginning and end of each GC cycle for "sweep termination" and "mark termination," but we improved the behavior of these pauses. We improved the pause times for large heaps by fixing some tasks during these phases that were O(n) in the heap size (~5ms/GB). Some we eliminated entirely, while others we figured out how to do during the concurrent phase, so now there's nothing really proportional to the heap size happening during the pauses. We moved a few other less common sources of latency out of the pauses as well, and we're aware of a few others that we're planning to address in Go 1.7 (I got concurrent stack shrinking working just today :). We also "decentralized" the GC algorithm in Go 1.6. In 1.5, GC was coordinated by a single (internal) goroutine, though most of the work was done on worker goroutines. As a result, phase changes had to go through that coordinator, which meant they had to wait for the goroutine to get scheduled, which introduced delays. In Go 1.6, we've eliminated this coordinator; instead, any goroutine can perform a phase change the moment it detects that it's necessary. There were lots of other improvements, too. Take a look at my <a href="https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/edit?usp=sharing">Go 1.6 GC plan</a> if you want more details. A lot of these algorithmic choices are possible because Go has a non-moving garbage collector. This is quite different from Java, which uses a moving collector. The trouble with a moving collector is that it's really hard to move objects while the program is running (though not impossible, see <a href="http://dl.acm.org/citation.cfm?id=376810">Sapphire</a> and Azul). Since Go doesn't move objects, it can do much less during the stop-the-world phases (and doesn't need read barriers). For the next few releases, we're planning to focus on GC throughput to reduce the total CPU time spent in the garbage collector. We're attacking this on both the "microoptimization" level, by improving how quickly the garbage collector can scan memory, and the "macrooptimization" level, by reducing the amount of memory the garbage collector has to scan by focusing on areas of the heap that are more likely to be fruitful.</pre>joetsai: <pre><a href="https://www.youtube.com/watch?v=aiv1JOfMjm0">Rick Hudson gave a talk at GopherCon</a> with details of how the GC works. At a high-level, Go's GC tries to do as much of the mark-and-sweep work concurrently while the Go program is running and only needs to stop-the-world at the end of the mark phase. Of course, there is no free lunch, so while Go 1.5+ has lower GC latency, it does so by trading a little of throughput. I highly recommend watching the video; it's a interesting talk.</pre>hippmr: <pre>Do you know of anything upcoming that would enable us to develop desktop GUI apps in go?</pre>enneff: <pre>The shiny stuff looks promising, as do some of the other GUI libraries (I hope other people will point them out, as I can't vouch for them since I haven't used any of them). On a different tack, I recently started using <a href="https://github.com/gopherjs/gopherjs">gopherjs</a> to write a JavaScript front end and it is glorious. I have both the front- and back-ends written in Go, and the communicate using <code>net/rpc</code> over websockets. It all feels very natural and fun. Go's concurrency model works really nicely when combined with the DOM. For instance, here's some code that uses jQuery to bind a click handler to a button, and then block until the button is clicked: <pre><code> ch := make(chan bool) jq("button").On("click", func() { ch <- true }) <-ch </code></pre> There are some details here I've painted over for the sake of illustration—like preventing event propagation—but in practice I have written helper functions to deal with those edge cases. The result is very comprehensible UI code for an environment I'm familiar with (the browser). I like it a lot.</pre>sbinet: <pre>I have only dabbled a bit with gopherjs, but I believe it would gain tremendous traction if this kind of work would be integrated or at least on the roadmap: <a href="https://github.com/gophergala2016/cmd-go-js">https://github.com/gophergala2016/cmd-go-js</a> ie: have <code>GOARCH=js</code> be a regular target like the other <code>amd,386</code> and whatnot :)</pre>Klathmon: <pre>holy shit that would be incredible, and would rocket the ability to write front-end code in go into the mainstream.</pre>kingfishr: <pre>Is the source of your project public?</pre>ianlancetaylor: <pre>The exp/shiny package (<a href="https://github.com/golang/exp/tree/master/shiny">https://github.com/golang/exp/tree/master/shiny</a>) is headed in that direction. There's a long way to go, though.</pre>kl0nos: <pre>I really wait for this for a while now. I would replace Qt with that and write even more Go. I think a lot of people are waiting for a proper cross-platform GUI solution.</pre>Kamoi: <pre>Did <a href="/u/bradfitz">/u/bradfitz</a> ever get his smoke alarms working properly?</pre>bradfitz: <pre>After months without smoke detectors (too lazy to put up the old ones, some of which I'd already gotten rid of), I bought the 2nd Gen models (<a href="https://nest.com/support/article/How-can-I-tell-which-Nest-Protect-I-have">https://nest.com/support/article/How-can-I-tell-which-Nest-Protect-I-have</a>) because I'm ... an optimist? So far so good. It has a new sensor(s) apparently. This has nothing to do with Go, but we did say it was an AMAnything I guess. :)</pre>mwholt: <pre>I don't use cgo very often (if ever), although I can see why it's useful/necessary. Still, is there a reason CGO_ENABLED=0 isn't the default value? Or, in other words, what are the disadvantages of a truly static Go binary?</pre>ianlancetaylor: <pre>As of Go 1.5 and 1.6, the main disadvantage of CGO_ENABLED=0 is that the os/user package will not work. Because there is so much variety in how user information is represented, that package calls out to libc to get its information. With CGO_ENABLED=0, it will always return an error "Lookup not implemented". Also, specifically on Darwin, the crypto/x509 package won't be able to access the root certificates on the system. Before Go 1.5, the net package called into libc to do DNS lookups. However, in Go 1.5 the default DNS resolver is pure Go code, and it only calls into libc in unusual situations. Except on Darwin--on Darwin it again has to call into libc in all cases. So if you don't care about os/user, and you aren't running on Darwin, and you don't actually use cgo yourself, then by all means set CGO_ENABLED=0 for all your builds. But for most people it's probably not the best default, at least not yet.</pre>4ad: <pre>Complex name resolution environments like nis or ldap won't work. No os/user. Pretty minor things in my book.</pre>Twirrim: <pre>What's the plan around improving crypto/ssl performance in Go? There was the <a href="https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/">interesting blog post from Cloudflare</a> in May last year, and a bunch of discussion about the conflicting licenses involved in the code. I fully understand why you can't import it as is. From the email thread associated with that blog post it looks like some improvements have been added, is there a specific plan or resources around adding further improvements? The performance bottlenecks as-is, even on 1.6rc2, are certainly something I keep running in to, in ways that are non-trivial to use, say <a href="https://godoc.org/github.com/spacemonkeygo/openssl">SpaceMonkey's openssl wrapper</a>.</pre>robpike: <pre>A major missing piece here is good assembly language support for math/big and other crypto components on architectures other than x86. The ARM ecosystem on Go doesn't have enough assembly love, and significant performance improvements are possible. With the growing list of supported architectures (POWER, IBM z Systems, MIPS, etc.) this is ever more important. Legally unencumbered contributions welcome. And thanks to Cloudflare for their contributions so far.</pre>rsc: <pre>The Go team is working with engineers at both Cloudflare and Intel to improve the performance of any of Go's tight loops that could benefit from more careful coding (often in assembly), including but not limited to the crypto packages. In fact on one microbenchmark recently we found that Go's <pre><code>for i := range x { x[i] = 0 } </code></pre> ran faster on at least one modern x86-64 Linux workstation than a C program calling glibc's memset. The Go compiler recognizes that pattern and calls its own memset, so really it's just a comparison of Go's memset assembly vs glibc's. And in this specific setup, Go's was faster, I suspect because machines change, and Intel engineers had tuned Go's more recently than they'd tuned glibc's. The point isn't that Go is always faster than glibc, which is certainly untrue, but rather that Go is moving toward the kind of optimization coverage you'd expect from a mature standard library. I'm not as confident as <a href="/u/dgryski">/u/dgryski</a> that all Cloudflares optimization work is in, but we'll get there.</pre>nyoungman: <pre>Several of CloudFlare's crypto optimizations have landed for Go 1.6, but based on this issue, there is one that still has an outstanding licensing issue. <a href="https://github.com/cloudflare/go/issues/8">https://github.com/cloudflare/go/issues/8</a></pre>dgryski: <pre>I think both the RSA and the EC code landed for 1.6; both CLs were cherry-picked.</pre>rsc: <pre>Thanks everyone for all the great questions. The response has been overwhelming, in a very good way. I'm going to unsticky this post since it's been well over 24 hours at this point. I'm also going to make sure that all the questions older than this comment do get answered in the next few days. I know I personally have a bunch that I intend to reply to but haven't had time yet today. Thanks again!</pre>breakingcups: <pre>What is something you'd love to see in Go, but know is impossible until Go 2?</pre>robpike: <pre>I would like the opportunity to rewrite the lower-level, earliest-written libraries to be more Go-like. There are a number of early decisions I regret. One easy one to explain is that os.Stdin and os.Stdout are concrete types, *os.File. It would be much nicer if they were io.Reader and io.Writer. Similarly, I would like the File type itself to be more abstract so it can be implemented by other packages transparently. So much power cut off by those early mistakes. We live and learn.</pre>4ad: <pre>I have always wondered why os.Stdin and os.Stdout are concrete types. Now I know!</pre>gertcuykens: <pre>Can you make a GO Experimental playground please where all this ideas get actually a proof of concept we can test? Currently only people like you understand the big picture, users like me get locked out in the thinking process because our vision is to narrow to understand the benefits. I would like to read more blog post how GO language developers think and what they are drawing on their blackboard. I see many issues on github that feel like that idea was already tested a year ago because of the detailed description :) I want to see more issue failures that can be referenced as somebody tried that already and this is why idea xyz failed. I learn more about the mistakes you people make then the abstract solutions that result from it.</pre>4ad: <pre>Too many ways to declare a variable. I don't like the shadowing rules, too subtle.</pre>earthboundkid: <pre>My wish list: <ul> <li>No bare <code>return</code>s</li> <li>No <code>new</code></li> <li><code>error</code> with <code>Source() error</code> method added for chaining</li> <li>Various library clean ups: more consistency between archive and compress packages and their methods, various io.Reader/Writer helpers in one easy to find place instead of ioutil plus bufio plus bytes, various depreciations removed </li> </ul></pre>kurin: <pre>I really like Source(). I haven't seen that before.</pre>mdempsky: <pre>I wish that in <pre><code>for x := range v { wg.Add(1) go func() { defer wg.Done() foo(x) }() } </code></pre> <code>x</code> would be scoped to the block, rather than to the whole <code>for</code> statement, so it would Just Work. This is the most common mistake I still regularly make in quick one-off programs.</pre>nyoungman: <pre>The current scoping is consistent with scoping elsewhere. <pre><code>if x, err := func(); err != nil { // do something with err } else { // do something with x } </code></pre> But maybe range could behave differently in Go 2?</pre>enneff: <pre>I was going to make the same comment.</pre>dgryski: <pre>Also, the Go2 label on the issue tracker: <a href="https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2">https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2</a></pre>scubatube69: <pre>Congrats on the 1.6 release! Are there any plans for reducing binary sizes produced by gc? I've read this can be accomplished by compiling without the debugging information, but I couldn't find information about this on the "go build" docs.</pre>4ad: <pre>This is issue 6853: <a href="https://github.com/golang/go/issues/6853">https://github.com/golang/go/issues/6853</a></pre>mdempsky: <pre>On POSIX systems, you can use the <code>strip</code> utility to remove non-essential debugging information from compiled binaries. There's other debugging information still included in Go programs (e.g., the <a href="https://golang.org/s/go12symtab">symbol tables</a>) that contribute substantially to binary size, but they'd be more difficult to remove because they're used for things like precise garbage collection (need to know which values on the stack are pointers) and <a href="https://golang.org/pkg/runtime/#FuncForPC">runtime.FuncForPC</a>.</pre>sleepydog: <pre>In the release notes, it says <blockquote> Internally, the most significant change is that the parser is now hand-written instead of generated from yacc. </blockquote> Could you share the reasoning behind moving to a hand-written parser from yacc? Was it for better error messages? Performance? I have a soft spot for yacc :)</pre>robpike: <pre>Yacc is a great tool, but it complicates the build process, requires maintenance, and means people who wish to work on the compiler must understand another tool and its input language. Translating the compiler to Go from C meant programmers didn't have to know C to contribute to the compiler; now they don't have to know yacc either. There is also strong anecdotal evidence that error messages are easier to make high quality in a recursive descent parser than in a LALR(1) grammar. And yes, it is a little faster. Yacc's output isn't especially well handled in Go because of all the indexing operations, although I suppose as compiler technology improves that might help. Overall, it's nice to have one less tool to maintain and a cleaner, all-Go compiler.</pre>aclements: <pre>The main advantage of the hand-written parser is that it can be analyzed and manipulated by the standard Go tools, so refactoring the compiler is far easier. My understanding is that the performance is about the same; while it's algorithmically somewhat less efficient, it's "better" Go code than what yacc generates.</pre>very-little-gravitas: <pre>Thanks for all the work on Go 1.6. What do you think are the most helpful areas external contributors could help with on upcoming versions of Go, for different levels of contributor (beginner, intermediate, advanced)? Are there any areas which are neglected at present and would benefit from external help?</pre>ianlancetaylor: <pre>There are a lot of open issues at <a href="https://golang.org/issue">https://golang.org/issue</a>. Fixing those, or determining that they can be closed, would be very helpful. The documentation is good and steadily improving, but where you see problems please send fixes or open issues. At the more advanced level, there is plenty of room for improvement in the compiler, and this is an area where many people can usefully contribute. For example, somebody asked about debug info above--this is mostly a compiler and linker issue.</pre>enneff: <pre>The <a href="https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Ahelpwanted">HelpWanted label</a> lists a bunch of issues that we need help with. Some of them are relatively straightforward and some are hard. New issues are filed all the time and help with triaging and verifying those issues (getting more info from the reporter, etc) is always welcome. In general, though, the best way to help Go is to improve the greater Go ecosystem by writing libraries, tools, articles, and so on. </pre>nyoungman: <pre>One way to help triage Go issues is to sign up for the third-party tool CodeTriage. You can get one issue via email each day to take a look at. <a href="http://www.codetriage.com/golang/go">http://www.codetriage.com/golang/go</a></pre>jnj1: <pre>This is cool, thanks.</pre>JDazzleGM: <pre>Hi! I've been playing around with Go but I haven't found a good learning resource. Are there any places you'd recommend for those want to learn Go, along with good exercises? Thanks!</pre>enneff: <pre>The Tour is the canonical learning resource: <a href="https://tour.golang.org/">https://tour.golang.org/</a> The codewalks are fun, and underutilized I feel: <a href="https://golang.org/doc/codewalk/">https://golang.org/doc/codewalk/</a> <a href="http://exercism.io/">exercism.io</a> is a fun site for practicing programming and getting feedback on your style. They have a strong Go track you can participate in.</pre>tiffanyfj: <pre>Dave Cheney put together a lot of good resources: <a href="http://dave.cheney.net/resources-for-new-go-programmers" rel="nofollow">http://dave.cheney.net/resources-for-new-go-programmers</a></pre>Keblic: <pre>Congrats on the release! In your <a href="http://blog.golang.org/6years" rel="nofollow">6 years post</a> you mentioned: <blockquote> Early next year we will release more improvements in Go 1.6, including ... an official package vendoring mechanism ... </blockquote> I was hoping that this went beyond the <code>GO15VENDOREXPERIMENT</code> and actually included an official package management tool. Are there any future plans to work towards this?</pre>enneff: <pre>I think the next step is to nail down the <a href="https://github.com/kardianos/vendor-spec">vendor spec</a>, a file format for describing dependencies. I'm personally thinking about tools that can help with the greater vendoring story, but I don't have anything specific to discuss about it at this time.</pre>shazow: <pre><ul> <li>What is the roadmap for <a href="https://golang.org/x/mobile">golang.org/x/mobile</a>?</li> </ul> There are a lot of great things in that package, and I have several experiments I've prototyped against it but I'm reluctant to commit until there is some clear future for the module. Will it ever be an officially supported module with some stability guarantees any time soon, or is it going to remain a testbed for experimental ideas for the foreseeable future? Any guidance on timeline and its intended future? <ul> <li>Any plans to go beyond just GL ES, when support is available?</li> <li>Any plans to add windowing control when available (size, full screen, etc)? Possibly through some composition with x/exp/shiny?</li> <li>Any plans for Vulkan? :D (<a href="https://github.com/golang/go/issues/11818#issuecomment-123697333">Some mentions here</a>, but I wonder if further planning materialized yet)</li> </ul></pre>crawshaw: <pre>We don't have a roadmap right now. I personally intend to focus on x/exp/shiny for a while, part of which is maintaining the GL driver and the input event model. I don't expect to invest much beyond GL ES just yet, as while Vulkan is interesting, it will be a quite a while before it is generally usable across mobile operating systems. ES 3 is a possibility, but I won't build it myself until there is a need for it in shiny.</pre>mibk: <pre>I just want to thank all Go contributors, especially the people who designed the language. The only downside of Go, as I see it, is that now I hate every other language.</pre>gorpherder: <pre>Any chance someone will fix <a href="https://github.com/golang/go/issues/9869" rel="nofollow">https://github.com/golang/go/issues/9869</a> ? the resulting heap fragmentation is an issue when you have a model similar to the golang http server which forks a goroutine per request. if you subsequently create a bunch of goroutines eventually the heap can become quite fragmented. There are other ways to model the code but this seems like an obvious candidate for fixing in 1.7 (or at least mitigating - prevent fragmentation by using a dedicated allocator for the structures). btw, thank you for Go. if you're in mountain view there are a number of people who would be happy to buy you guys a beer.</pre>ianlancetaylor: <pre>It's a known problem (obviously) but it hasn't seemed high priority, at least not to me. it's only a problem for a long-running program that has a one-time spike in the number of goroutines. If you regularly spike the number of goroutines, that memory is being used. I mean, I'd be happy to see it fixed, but is it really causing you trouble?</pre>weitzj: <pre>What do you think of Gomobile? Will there be some focus on it? It feels like Hannah and David are most of the time on their own. Thank you for Go</pre>vruin: <pre>If hypothetically you could only program in 2 languages, which other language do you think would complement Go better and why?</pre>bradfitz: <pre>Let me modify the question a bit: <blockquote> If hypothetically you could only use programs written in 2 languages, which other language do you think would complement Go better and why? </blockquote> I would pick Rust and Go. Rust can replace all the buggy C code out there (looking at you, CVE-2015-7547, and so many similar ones) and I can then only write in Go, and stop worrying about buggy C code on my computers.</pre>joetsai: <pre>That's interesting. I've heard people compare and contrast Go and Rust as if they're competitors, but you seem to be treat them as complimentary. I've never worked with Rust before, what would you find Rust to good at that Go wasn't suitable for?</pre>bradfitz: <pre>While Go is much safer than C, Rust is even more safe than Go. Unlike Go, Rust doesn't permit data races. That safety comes with a fun-to-hack-with penalty though (IMO). Usually I can just be careful or use tools to find bugs via static analysis or runtime checks (e.g. Go's race detector), but it's nice to know a safer option like Rust exists.</pre>ianlancetaylor: <pre>I don't see Go and Rust as significant competitors. I think that in practice they will be used for different kinds of programs.</pre>4ad: <pre>Shell script, because it's easy to compose things out of smaller things.</pre>enneff: <pre>Seconded. Go and shell are what I use most these days.</pre>847203413: <pre>Hi, thanks for the 1.6 release. A few questions: <ol> <li>Are the any updates on generating Go code with Go (<a href="https://www.reddit.com/r/golang/comments/3680i6/generating_code_from_scratch/crcf98r" rel="nofollow">https://www.reddit.com/r/golang/comments/3680i6/generating_code_from_scratch/crcf98r</a>)?</li> <li>What was the decision behind not adding syntactic sugar around maps and slices. For example a "in" keyword to check if an element is in a slice, or a convenient way to get the keys of a map as a slice?</li> <li>I think I read somewhere that the garbage collector will be reworked for Go 1.8? How, why and where can I find out more?</li> </ol></pre>broady: <pre>I wasn't there for the original decision, but sugar like an <code>in</code> keyword would disguise the fact that presence test in a slice is an O(n) operation. That's not good.</pre>TheMerovius: <pre>As anecdotal evidence: I was tutoring an introductory algorithm class which was held in python. People using <code>in</code> on lists and accidentally making a linear algorithm quadratic (or similar) easily made up 80% of the mistakes I had to correct.</pre>dsymonds: <pre>I was there for some of the discussions, and can confirm that that was exactly the concern. Go tries to be reasonably transparent to read. This is also a reason why Go doesn't have operator overloading: it hides the expense of something that might otherwise be expected to be cheap.</pre>aclements: <pre>I wouldn't say we're planning to "rework" the garbage collector in the next few releases, but we are planning to keep improving it. In particular, we're focusing on GC throughput for the new few releases. We have an algorithm for efficiently garbage collecting objects that are never shared between goroutines, which we think will make the garbage collector much more efficient for HTTP and RPC-style servers. We're prototyping this now and plan to send a document about it to golang-dev in the near future once we've hashed it out more.</pre>Entropy: <pre>Ooh! Are you going to have goroutines start picking up after themselves? Then they'll be convenient AND conscientious.</pre>aclements: <pre>Pretty much. :) The idea is related to the existing idea of "thread-local heaps" (goroutine-local heaps in this case). Objects are initially allocated in a local heap and if they ever become reachable from another goroutine you reassign them to the global heap (which in some systems requires moving them, but doesn't in our design). Since pointers in the global heap can never point to objects in a local heap, you can collect a local heap without even thinking about the rest of the heap and---even better in a goroutine-per-request server---you can simply discard the local heap in bulk when a goroutine exits.</pre>rsc: <pre>Re 1, no, I don't believe so. I've spent a while using go/ast to refactor code (for example rsc.io/grind) and I found that just printing the code I wanted was much easier than trying to generate AST structures. It's fairly easy to print the code directly, since Go doesn't have many structural gotchas, and you can pass the result through gofmt easily enough, so I don't see significant benefit to using the AST form in a generator. In a code rewriter starting with the AST form, it would be nice if modifying the AST worked better than it does today. Our focus is on other things, so the situation probably won't change soon. For <a href="https://godoc.org/rsc.io/grind">rsc.io/grind</a>, I used the position information in the AST to generate a list of textual edits I wanted to make and then applied them to the original source code bytes. That worked much better for me than AST manipulation, for what that's worth.</pre>Entropy: <pre>Any updates on <a href="https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit?pli=1#">plugin support</a>? Specifically, the "Go code as a shared library plugin with a Go style API" and the "Go code that uses a shared library plugin" portions.</pre>ianlancetaylor: <pre>I would like to see this but I'm not aware of anybody actively working on it. We have all the pieces but it's a bit tricky in that it requires some careful thought to make sure that everything works if the same package appears in both the main executable and the plugin.</pre>magikos: <pre>How and when did you start programming? What was your first programming language?</pre>bradfitz: <pre>My dad taught me to program when I was 5 or 6 (so 1985/1986). I'd always watched him program and was curious. He sat me down with a piece of paper at the dining room table and wrote a program on paper: <pre><code>10 PRINT "HELLO" 20 GOTO 10 </code></pre> "What do you think that does?", he asked. "Print hello to the printer, forever?" "Well, no, it prints to the screen, not the printer. That would be LPRINT." "Why?" etc The computer was a homemade, bootleg Apple ][, with the ROM burned onto faulty memory chips with bits stuck high or low that my dad had got from a company's trash. If you have enough faulty chips, eventually you'll find one where the faulty bits are stuck high or low in the right places. Still amuses me. We later got a 386 and a family friend & neighbor gave me Turbo C a few years later and I enjoyed being able to control the mouse and do better graphics than I could in BASIC.</pre>enneff: <pre>My grandfather taught me to code when I was a little kid, starting with BASIC on a TRS-80. In primary school, one of my friends gave me a copy of Turbo Pascal and showed me how to use it, which is how I learned to code properly. That friend now works a few desks away from me at Google. :-)</pre>aclements: <pre>I got a chemistry book for my seventh birthday (1991) that had a BASIC program in the back for classifying chemicals. It was my first window in to how a computer worked. I asked my dad to type it in for me, then I started asking lots of questions about how it worked (luckily he's a software engineer, so he could answer them), then I started writing my own little programs in BASIC, and then I was hooked. :) In fifth grade I read "Moving From QBasic To C." My teacher thought that was a very strange book report.</pre>ianlancetaylor: <pre>My first program was written with a friend, entirely on paper, based on a description of BASIC that we read somewhere. My first actual program was written in BASIC on a DECsystem-20 in 1977. Edited to add: my first experience with computers was when I was younger, when my mother would bring home stacks of punch cards from programs she wrote while getting her Ph.D. (in nutrition--why she had to write programs for that I don't know). She did not like to program, but I liked playing with the punch cards.</pre>robpike: <pre>Early in high school took a worthless course using mark-sense cards programming BASIC on an HP minicomputer. Turnaround for jobs was three days*. I got fed up and taught myself FORTRAN using WATFOR on the UofT IBM/360; there was a public access room where you could run anything that fit on less than 2000 cards (one box) and consumed less than 3 seconds of total compile, link, run, and I/O spool CPU time. (It was about a 1MHz machine; work out what that means in terms of today's computer environment and understand why I bitch how slow everything is today.) I took a single year of a PL/I course in university, then discovered Unix (it was a heavily hacked v5) and learned everything that mattered from the guys in that room (The Dynamic Graphics Project): Tom Duff, Bill Reeves, Mike Tilson, and so on. I owe it all to Ron Baecker seeing something in my enthusiasm and letting me in the door. We got to use the PDP-11/45 starting at 5PM every day. It had 2.2 megabytes of disk space for all of us to share. <ul> <li>Bob Dewar once told me that he and Ken Belcher wrote SPITBOL with the same kind of turnaround to a remote batch machine, but of course in 360 assembly language. He is a much better programmer than me and did it in some remarkably few round trips. I wish I could remember the details.</li> </ul></pre>mwhudsondoyle: <pre>I think my first language was logo on the amstrad pcw. it might have been mallard basic, but I think logo was first. I'd have been about 7 I guess? Just another geeky kid lucky enough to have parents who bought a computer!</pre>4ad: <pre>When I was a child, I loved reading old FORTRAN manuals for Eastern Europe clones of western mainframe computers. I think they were System/360 clones, or maybe stolen designs, but with ferrite memory. The first language that I wrote a program that actually ran on a computer was Pascal. However, I quickly came to my senses and learned C and assembly. My first real program was an operating system like thing that let me run multiple DOS programs at the same time. In fact I started doing programming to solve this practical problem that I had. This continues to this day, when I have a problem, I try to solve it, rather than find an awful library that "solves" it for me. I am a programmer, I can program.</pre>rsc: <pre>My father worked on <a href="https://en.wikipedia.org/wiki/Speech_coding">speech coding</a> and had a Commodore 64 at home, I suspect because it had a really great sound chip for the time. One of my earliest memories is being allowed to press the <a href="https://en.wikipedia.org/wiki/Commodore_64_peripherals#/media/File:Commodore_Matrixdrucker_MPS-802_%28wei%C3%9Fen_hintergrund%29.jpg">paper advance button</a> on the printer after he printed something. I don't know how old I was, but clearly the fact that I could make the machine do something made an impression. Eventually I started drawing on the C64 by moving the cursor all around the screen and typing using different foreground and background characters, and then I moved on to typing in BASIC programs from <a href="https://en.wikipedia.org/wiki/Run_%28magazine%29">Run magazine</a>, and then at some point I started changing them and figuring out how they worked. A few of my clearest learning-to-program memories, though, are from trying to learn C. By then we had a PC with MS-DOS and Turbo C, and my father had a copy of the original K&R. I typed in hello world from that book, something like: <pre><code>int main() { printf("hello, world\n"); return 0; } </code></pre> Turbo C refused to run that program. It had some mysterious complaint about printf not having a prototype. I don't think my father understood the message either, and I had no one else to ask, so I gave up on learning C for a while. The problem was that Turbo C implemented the then-recent ANSI C standard and insisted on <code>#include <stdio.h></code>, but the K&R book predated that. Another memory from a bit later: once I had gotten the hang of #include and other parts of C, I understood that if you wrote: <pre><code>char buf[20]; gets(buf); </code></pre> then you had to worry about what happened if the user typed more than 20 bytes into gets. But I made a great discovery! If instead you wrote: <pre><code>char *buf; gets(buf); </code></pre> then the compiler (apparently) automatically arranged for buf to accept any number of bytes without problem. I had no idea how it worked, but it worked. What was really happening, of course, is that the uninitialized buf pointer reused whatever pointer or non-pointer bits might have been there on the stack from a previous call and scribbled over other memory. This was MS-DOS, though, and that technique had surprisingly few adverse consequences.</pre>1107d7: <pre>Howdy Golang team! Thanks for 1.6. When I was debugging the http2 library back when it was homed on github, it was hard to test because the httptest.NewRecorder() was unable to record http2. Has this changed? What is the canonical way to record http2 for play back in tests? edit: <a href="https://github.com/golang/net/blob/master/http2/server_test.go">https://github.com/golang/net/blob/master/http2/server_test.go</a> Thanks again!</pre>bradfitz: <pre>What exactly do you want to do? httptest.NewRecorder() records what http.Handler code does to its provided ResponseWriter. Because Go's http1 and http2 share the same http.ResponseWriter/http.Handler interfaces, http.NewRecorder will work fine for writing Handler tests for a Handler that will speak either http1 or http2. But I think you must mean something more specific?</pre>Martinjnh: <pre>Congrats on the release. Is there any chance to create AndroidGo without Java? Thank you all.</pre>enneff: <pre>The <a href="https://godoc.org/golang.org/x/mobile/app">/x/mobile/app</a> package is the entry point for a framework for developing native Go apps on Android. You might find Hana Kim's <a href="https://www.youtube.com/watch?v=sQ6-HyPxHKg">talk from GopherCon</a> interesting.</pre>RalphCorderoy: <pre>Why does package log format the date with slashes rather than hyphens? Seems such an odd choice for a modern design. And makes it tedious when searching, e.g. in less(1) with /2016\/02\/18.</pre>ianlancetaylor: <pre>I'm not sure but I think it just copied a Google-internal logging library written in C++. In retrospect it probably was not the best choice.</pre>SportingSnow21: <pre>Congratulations on the 1.6 release and thank you for all the work you've put into it. Are there any plans to add higher-level vectorization instructions/optimizations into the compiler/assembler? I understand that this wouldn't be default (cross-compiler guarantees and the like) but more likely a compiler flag.</pre>joetsai: <pre>There was <a href="https://groups.google.com/forum/#!searchin/golang-nuts/intrinsics/golang-nuts/yVOfeHYCIT4/7L_mffslT84J">work on a proposal</a> by <a href="/u/klauspost">/u/klauspost</a> for intrinsics support. As far as I know, I haven't seen a full proposal sent out yet. I would love to see some easy way to use vector instructions (without dealing with assembly myself), but yet also done in a way that it doesn't dirty up the language. As in the proposal, separating access to intrinsics by package seems promising.</pre>Dieter_be: <pre>Hi! Thank you so much for your continued investment in Go and its community. I was wondering how improvements in escape analysis may fit into the roadmap? Is this something that will be part of the SSA effort? I can imagine (and would understand) escape analysis improvements may not be very high prio, but i'm still curious. Thanks.</pre>ianlancetaylor: <pre>There are some improvements in escape analysis in the 1.6 compiler, mostly by David Chase, and there will most likely be more in 1.7. This is currently pretty much independent of the SSA compiler, although perhaps in the future it will be to take advantage of SSA information. If you have any specific suggestions for additional forms of escape analysis, please open an issue. I'm sure there are things we haven't thought of.</pre>: <pre>[deleted]</pre>ianlancetaylor: <pre>These are fair questions, and we don't have good answers for them. Most people working in Go seem to only encounter these problems in a very small form (e.g., the sort.Sort interface) where the code copying, while slightly annoying, is no big deal. That is, the copied code is small, trivial to write, and clearly correct. A few people do encounter issues where code copying is larger scale and is not clearly correct, meaning that bugs may have to be fixed in multiple places. We don't have a good solution for these cases. it's a complicated space. If we can figure it out, we will. Many people have proposed solutions, but none have been wholly satisfactory. There is an official code generation tool: <code>go generate</code>. There are code generation tools that do what you suggest, but I don't know how widely they are used. At this point we aren't planning to bring any into the official repository, though it's possible that will change in the future.</pre>: <pre>[deleted]</pre>nyoungman: <pre>Go is an imperative language. Yes, it has first-class functions, but many imperative languages do (Objective-C blocks, Java 8 lambdas). That doesn't make them functional languages. The style of code is quite different, and I don't expect Go will ever appeal to someone who prefers Haskell's style. Here is an example of implementing an algorithm in Go and Elixir. They are very different languages that work best for very different styles of programming: <a href="https://gist.github.com/nathany/723e6057e5c7c70e5772">https://gist.github.com/nathany/723e6057e5c7c70e5772</a></pre>enneff: <pre>In addition to what Ian said, I just wanted to point to this one part of your post: <blockquote> This problem is made even more difficult by the fact that every 'type' declaration creates a new type incompatible with the type it derived from in function calls without explicit casting. </blockquote> If your functions take interfaces then there's no explicit casting necessary. That is the usual way to accept many implementations in Go.</pre>kune13: <pre>If you have repeatedly to write the same algorithm against different types check whether the commonality of the types can be expressed in an interface and then write your algorithm against this interface. Work hard to reduce the number of functions in the interface. The smaller the interface the more types can support it.</pre>mustafaakin: <pre>Although I am used to write <code>printf</code> debugged code and unit tests for most functions, a proper debugger and some first class IDE love would attract more people. In my work, the people who wants to play safe avoids using Go even if it suits the job better than most other viable alternatives. Are there any plans for "official" debugging tools and IDEs? I know neither Java/C/Python has official IDEs, but even when we transition in to go1.5->go1.6, you have to manually configure the gocode to include vendored packages for better code completion etc, so there becomes a delay. </pre>enneff: <pre>You should check out <a href="https://github.com/derekparker/delve">Delve</a>.</pre>robpike: <pre>I second the mention for <a href="https://github.com/derekparker/delve">Delve</a>. It's great work and is not widely enough known.</pre>dlsniper: <pre>There's a Go plugin for IntelliJ Platform (every IDE from JetBrains) which is getting better and better each day. Just try it out. <a href="https://github.com/go-lang-plugin-org/go-lang-idea-plugin">https://github.com/go-lang-plugin-org/go-lang-idea-plugin</a> It has everything you are looking for in terms of debugging and IDE (even if it's not official from the Go team, which I don't think it should be anyway)</pre>kalekold: <pre>Rob Pike said (during a talk) that he and the team were going to be working on a debugger for Go but not to get hopes too high as "it may fail". Is there any more information on this?</pre>robpike: <pre>The Go support in Google's Cloud Debugger project (<a href="https://cloud.google.com/debugger/">https://cloud.google.com/debugger/</a>) builds on that work and is in active development.</pre>dsymonds: <pre>You might be interested in poking around inside <a href="https://go.googlesource.com/debug/">https://go.googlesource.com/debug/</a>.</pre>spedru: <pre>When a release is allowed to break compatibility promises, what are going to be the first things to go out the window?</pre>enneff: <pre>It is likely that many different things will change simultaneously, and all those things will need to be considered in relation to each other. The <a href="https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2">Go2 label</a> on the issue tracker lists some of the things we will consider when the time comes.</pre>iends: <pre>Is pause-less GC a long term plan?</pre>aclements: <pre>It is not. We think that for the vast majority of systems (though certainly not all), pauses in the millisecond range are quite acceptable, while pause-less GC would likely harm the throughput of the systems that don't need it and would certainly dramatically increase the complexity of the runtime.</pre>horsebees: <pre>Internally, how do you advertise Go? I've heard Dart is gaining traction; and I'm sure some groups still reach for Java as a first choice. Do you go give talks? Is it completely organic? Are there standard internal wiki pages "Why you should choose Go."?</pre>enneff: <pre>It's a combination of things. We give talks, run workshops, write internal articles, and consult with teams that are starting new projects to discuss how Go might work for them. We have an internal page of testimonials from groups who have used Go. Google's a big place, and we're always trying to find more ways to teach people about Go. But I don't think awareness is really the main barrier to adoption. While Go is seeing widespread use inside Google, there are a lot of Googlers who want to use Go but are blocked for some technical reason (usually interoperability with an existing system). We (the Go team) spend a lot of time working on unblocking these people.</pre>mobiledevguy5554: <pre>Are there any plans to support multiple result sets in the SQL package? I regularly build stored procedures that return multiple result sets and I cannot use them from Go</pre>bestform: <pre>Hey! Is there any chance we will see another episode of "Hacking with Andrew and Brad" anytime soon? I really enjoyed the two episodes that you've published so far.</pre>srnull: <pre>I know this is a predictable and tired topic, but I think I have a somewhat unusual question on the generics front. I totally understand the <a href="https://golang.org/doc/faq#generics">current stance on generic</a>, but there has been significant confusion in the wider community (those paying some attention to Go, but perhaps not yet using) about whether the investigation into having some form of generics in the future is at all serious. Lots of people claim they're never happening. Plenty of us point to the more subtle reasoning shown in the FAQ - that they'll possibly be implemented if an agreeable design is found. So which is it? Is there any serious attention being paid to designs for generics in Go N.x, N > 1? That is, what does "...we continue to think about it..." as stated in the FAQ mean? Thanks</pre>dsymonds: <pre>Some people on the Go team have sunk considerable time in producing generics proposals, but they've all had serious drawbacks. I'm hoping those proposals will be published at some point so people can see the depth of complexity that generics bring; it's almost always underestimated.</pre>srnull: <pre>Thanks for the reply. Would be awesome to read those proposals. I'm sure there are a lot of people like me who have an interest in programming language design but don't have the opportunity to get our hands dirty with it very often or in much depth.</pre>joetsai: <pre>The <a href="https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#">Summary of Go Generics</a> document contains many helpful insights into why Generics are not in Go. Russ' comment: "The Go team is not against generics per se, only against doing things that are not well understood and/or don't work well with Go." pretty much summarizes the current situation. I, for one, would love to see generics be in Go, but personally I'm not terribly bothered by the lack of generics. I would much rather see a potentially far better implementation in the future, than one today that has many of the problems with C++ or Java generics (they make for great difficult exam questions, but terrible developer experience).</pre>Jhsto: <pre>Would you rather fight one horse sized gopher or 100 gopher sized horses?</pre>rsc: <pre>It depends: are the 100 gopher-sized horses communicating?</pre>DeedleFake: <pre>Yes, but they're doing so by sharing memory.</pre>dsymonds: <pre>I'd prefer 100 gopher sized horses. They'll get in each other's way, so you'd really only be facing around 10-20 at a time.</pre>enneff: <pre>Just speaking for myself, but definitely one horse-sized gopher. Horses bite.</pre>ianlancetaylor: <pre>I would have to go for the 100 gopher sized horses. A horse can easily weigh 1000 pounds or more, but a gopher only weighs half a pound or so (source: the Internet). So given a choice of facing 50 pounds or 1000 pounds, well, I'm going to go for the 50 pounds.</pre>snuggles166: <pre>Congrats on the release! Repost from <a href="https://news.ycombinator.com/item?id=11122023" rel="nofollow">here</a> I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away. Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.) Semver and pinning versions has always just made sense to me. I can easily adopt new features and fixes automatically without worrying about things breaking. How does the community feel this far along?</pre>broady: <pre>Thankfully, there are many good solutions (Godep, gb, govendor, etc). The community has not settled on just one. Support for vendored paths/packages ("new" in Go 1.6) in the <code>go</code> tool is a big step forward already. In a future release, perhaps the <code>go</code> tool will include a way to download packages into a <code>vendor</code> directory and pin them to a version. If you'd like to contribute, please check these proposals first: <ul> <li><a href="https://github.com/golang/go/issues/13700">https://github.com/golang/go/issues/13700</a></li> <li><a href="https://github.com/golang/go/issues/13517">https://github.com/golang/go/issues/13517</a></li> <li><a href="https://github.com/golang/go/issues/13483">https://github.com/golang/go/issues/13483</a></li> </ul></pre>_yageek: <pre>Congrats for the 1.6 :) One question regarding net/http: Is a new version of ServeMux planned or will the golang team provide a new performant router package ?</pre>broady: <pre>In addition to what Ian said (if there are problems, including with performance, file a bug)... If you need a high performance router, take a look at <a href="https://github.com/julienschmidt/httprouter"><code>httprouter</code></a>.</pre>bradfitz: <pre>There are no plans to add new features or a new router type to net/http. The standard library is increasingly frozen at this point. But if there are performance problems, we're happy to fix or review fixes for ServeMux. If you want fancy features, there are plenty of muxes to choose from elsewhere. Not everything needs to live in the standard library.</pre>ianlancetaylor: <pre>I'm not aware of any current plans for a new version of ServeMux, nor am I aware of any need for one. If there are problems with the current ServeMux, please open issues about them at <a href="https://golang.org/issue">https://golang.org/issue</a>.</pre>nyoungman: <pre>Are you referring to alternative routers such as <a href="https://github.com/julienschmidt/httprouter">https://github.com/julienschmidt/httprouter</a>?</pre>exacube: <pre>when will reduced binary size be a priority? can the team set an explicit goal for sample programs and try to work towards it? this prevents Go from being used in smaller ARM-based systems</pre>enneff: <pre>It would be great to know the specific limitations you're working with.</pre>bradfitz: <pre>I have the same question as 4ad and enneff. As one counter point, PayPal launched ARM-based hardware running Go: <a href="http://techcrunch.com/2013/09/09/paypal-debuts-its-newest-hardware-beacon-a-bluetooth-le-enabled-device-for-hands-free-check-ins-and-payments/">http://techcrunch.com/2013/09/09/paypal-debuts-its-newest-hardware-beacon-a-bluetooth-le-enabled-device-for-hands-free-check-ins-and-payments/</a> Maybe you're working with something smaller, but how small? If you have many binaries, you can combine them into one, busybox-style.</pre>4ad: <pre>How small?</pre>nyoungman: <pre>One of the potential benefits of the SSA compiler planned for Go 1.7 is reducing the size of binaries (see the SSA question in this thread).</pre>giovannibajo: <pre>Congrats on the 1.6 release! <ul> <li>Even without generics, I feel like Go could use a few builtin "generic functions", that is general basic function algorithms operating on builtin generics (slices and maps). Common examples that I happen to rewrite often are: sum(), min(), max(), any(), all(), index() (aka search()), plus keys() and values() for maps. Many of these would actually make code significantly more easy to read and reason about (even for people watching Go code for the first time). Without necessarily discussing any of my examples, what is the stance of the Go maintainers on adding builtin functions like these to the language? It doesn't sound like they would make the language itself bigger (they don't affect the syntax), nor they can be said to hide complexity (I don't think people will assume that a function call is expected to necessarily be O(1)).</li> <li>Has there ever been any significant discuss on adding operator overloading to Go, even just for math operations and just between instances of the same struct? The Go FAQ basically says "they're syntactic sugar so we can go without them". While this is true, they're a basic need for any kind of serious scientific work. Just a few days I had to write this monstrosity: <code>mirror.SubFixed(vtx.cy.AddFixed(vtx.cw)).MulFixed(dy).AddFixed(vy0)</code> which would be <code>(mirror - (vtx.cy + vtx.cw)) * dy + vy0</code> with operator overloading.</li> </ul></pre>enneff: <pre><blockquote> Without necessarily discussing any of my examples, what is the stance of the Go maintainers on adding builtin functions like these to the language? </blockquote> I don't object on principle, except that I worry that it is a slippery slope. It's hard to know where to draw the line with such helpers. If the line were clear I'd be more comfortable with the idea. The helpers I would want personally are <code>keys</code> and <code>values</code> for maps, but I don't find writing the loops particularly onerous either.</pre>ianlancetaylor: <pre>I more or less object on principle. I think that the only functions that should be builtin are those that can take special advantage of the runtime. That is true of all the current functions except, arguably, copy. (The append function uses its knowledge of the memory allocation routines to decide how large the make the slice when it needs to grow.)</pre>giovannibajo: <pre>What is the rationale for your position? A programming language, however minimal, isn't about providing a minimal turing-complete-like set of functionalities to build upon, but also provide good fundamentals. I would agree those functions don't need to be builtins, they would be perfectly fine as part of a standard library package, but unfortunately it is not possible to write those functions in normal Go (which is exactly the reason why the only solution is that the language should provide them). It looks like you're post-projecting a rationale into the current builtin set, that wasn't decided in advance. </pre>ianlancetaylor: <pre>I'm not post-projecting, I've been arguing this position from the beginning. I used it against copy and append, but the consensus went against me. My rationale is that once you start adding builtin functions for things that can be easily written in the language, there is nowhere to draw the line. What should we look at to decide whether a function should go into the language or not? What stops us from implementing the entire C++ STL, only in the language itself rather than as a library? I think that before starting down any such path, there needs to be a clear basis for deciding what goes in and what doesn't. I've outlined one such position: only add functions that can take special advantage of the runtime. Do you have a different proposal?</pre>egonelbre: <pre><blockquote> Has there ever been any significant discuss on adding operator overloading to Go. </blockquote> Note: currently you can work around using code generation. A <a href="https://github.com/egonelbre/exp/tree/master/overload">proof of concept</a> using eg for one operator. Of course a proper tool could be much easier to use; you input a list of rules in format <code>a:Vector * b:Matrix4 => a.MultiplyMatrix4(b)</code> which then can be invoked via go generate.</pre>foresmac: <pre>Any tips for increasing code coverage with unit tests? And/or, considered adding a mock pkg to the standard libs?</pre>ianlancetaylor: <pre>There is a mock package over at <a href="http://github.com/golang/mock">http://github.com/golang/mock</a>. it's not in the official standard library, but it's supported and it works. (Edited to say that it is not in the official standard library--I managed to omit the word "not"--sorry!).</pre>nyoungman: <pre>Have you already discovered the <a href="https://blog.golang.org/cover">coverage</a> tool for checking your code coverage? If you use interfaces or first-class functions assigned to a global var, it's pretty easy to mock things out in your tests. There are also dedicated testing tools like httptest in the standard library, which runs a test server useful for testing an HTTP client.</pre>bananaboatshoes: <pre>I'm interested in networking and networking stacks as a whole. I like to look at how various languages implement things to develop a holistic understanding for what it takes to make a massive endeavor like building a networking stack turn into usable and efficient code. I've enjoyed looking over a lot of the source in net/http, and it's been a real pleasure to see the approach taken here. I have to ask ... what's the rationale for <a href="https://github.com/golang/go/blob/master/src/net/http/client.go#L427" rel="nofollow">this</a> function? I gotta say, it's pretty unintuitive that <a href="https://github.com/golang/go/blob/master/src/net/http/client.go#L475" rel="nofollow">the line of code that actually does the request</a> is in the middle of a <code>for redirect := 0; ; redirect++</code> loop. Is it related to efficiency?</pre>bradfitz: <pre>Yeah, what Ian said. Unfortunately the http.Client gets less love relative to the http.Transport and Server code. Feel free to send a change to clean it up for Go 1.7, though!</pre>ianlancetaylor: <pre>That redirect loop has been there since the first version of the net/http client in <a href="https://github.com/golang/go/commit/f315fb3d56746ddd14dbfeeea106564349bb5ce9">https://github.com/golang/go/commit/f315fb3d56746ddd14dbfeeea106564349bb5ce9</a> . I think it's just developed from there as features have been added.</pre>saturn_vk: <pre>Hi I have another question for you guys, something which I have wondered for a while. How come built in types such as strings don't have methods, but instead there are functions for them in specialized packages such as 'strings'? Is this related to the 'type foo string' feature, and if so, how come the new types don't get these methods automatically, like an embedding type would?</pre>enneff: <pre><blockquote> How come built in types such as strings don't have methods, but instead there are functions for them in specialized packages such as 'strings'? </blockquote> If strings had built-in methods then those methods would need to be specified by the language spec. I think this was a smart move to keep the language spec small. It seems unnecessary to conflate built-in types with functionality that operates on those types. Programs can use the the <code>string</code> type without depending on the <code>strings</code> package. <blockquote> Is this related to the 'type foo string' feature, and if so, how come the new types don't get these methods automatically, like an embedding type would? </blockquote> I think you're saying that <code>S</code> in <code>type S T</code> doesn't get the methods of <code>T</code>, while the <code>Q</code> in <code>type Q struct { T }</code> does get <code>T</code>'s methods. One reason for this is that the <code>T</code> in <code>type S T</code> is really just an alias for the underlying concrete type of <code>T</code>, while in <code>type Q struct { T }</code> the <code>T</code> is actually part of the struct <code>Q</code>. The methods of <code>T</code> in the latter case are still operating on a type <code>T</code>, not some alias of that type.</pre>iends: <pre>In another thread Andrew said that Go 2 wouldn't happen in the next two years. Does Google have some kind of internal roadmap of what it wants to see in the language? What are some other larger nice to have things that are being considered (other than the big ones: GC performance, binary size, compile speed)?</pre>bradfitz: <pre>There is no internal roadmap. We're still planning Go 1.7 (on the public mailing list). Nobody's thinking seriously about a Go 2. One guess as to what <a href="/u/adg">/u/adg</a> meant by "in the next two years", is Go 2 would be so big and time-consuming, it would take over two years to build. :) About the only interesting internal discussion that happens is the garbage collector and runtime folk who are sitting next to each other in Cambridge. But they're pretty good about publishing docs regularly after their in-person discussions. Most of the Go core work at this point is on the runtime (GC, scheduler) and compiler (SSA, generating better and smaller code). But most interesting things are happening outside of the Go core these days in the community and external packages. <blockquote> What are some other larger nice to have things that are being considered (other than the big ones: GC performance, binary size, compile speed)? </blockquote> <ul> <li>better generated code (less CPU at runtime), via SSA</li> <li>various debugging stuff (debugger, improved memory profiling, trace viewing, ...)</li> </ul></pre>

用户登录

今日阅读排行

一周阅读排行

最新主题