15 ms·
Brad Fitzpatrick on the future of Go
- sqs 12y agoHere's an interesting portion of a Q&A panel from the same dotGo 2014 conference (http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-dependency-management-design-philosophy http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-de...) Q: There are several dependency management tools in the wild: godep, gpm, etc. Are there any plans to provide this functionality in the core? Brad Fitzpatrick: We don’t want to dictate a policy, so we hope the community fights it out and a victor emerges. Then maybe we’ll bless that one. Then if everyone likes it and it has been stable for a couple of years, maybe we’ll add it to the core. Brad Fitzpatrick: Part of the reason why we don’t care as much about dependency management inside Google is that we don’t use the go tool inside Google. Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs.
- kator 12y agoAny clue as to what they do use internally?
- sqs 12y agoYeah, check the comments at http://www.reddit.com/r/golang/comments/2j65lb/go_qa_at_dotgo_with_the_go_team_others_dep_mgmt/ http://www.reddit.com/r/golang/comments/2j65lb/go_qa_at_dotg... (specifically the blogspot link and Andrew Gerrand's (enneff's) comment).
- skj 12y agoGoogle has an internal build system that builds everything, and it's language independent. Sort of like a distributed make.
- ithkuil 12y agoSome publicly available information: http://google-engtools.blogspot.ie/2011/08/build-in-cloud-how-build-system-works.html http://google-engtools.blogspot.ie/2011/08/build-in-cloud-ho... (https://news.ycombinator.com/item?id=2899467 https://news.ycombinator.com/item?id=2899467)
- jameskilton 12y agoThey vendor everything.
- spacemanmatt 12y ago"Vendor everything" was my conclusion to solving dependencies as generally as possible, while trying to knit PostgreSQL modules (locally produced schema chunks) and extensions with a base of versioned Rails apps.
- willnorris 12y agoYes, we do vendor everything, in that we have a snapshot of all of our dependencies in our source control system. But we do it across the entire codebase, not per project. That is, we typically only ever have a single version of a library for the entire company (with a few exceptions). If a project needs to update to a later version, they basically update everyone using that library. For widely used packages, this can sometimes be a time consuming process, but we've found it to be preferable to the alternative of having version conflicts all over the place. This is generally true not just for Go, but all languages. So the idea of a project needing to pin to a very specific version of a dependency and never update doesn't really fly.
- Touche 12y agoThat sounds like a wildly unproductive way to work. Discourages ever changing anything.
- wmf 12y agoIt sounds similar to the Linux kernel. If all the providers and consumers of an API are in the same repository, then you can change an API at any time as long as you update all consumers of the API at the same time.
- skybrian 12y agoIt does discourage upgrading until you really need it. On the other hand, if one person decides to do the work then everyone benefits.
- erikb 12y agoThis is quite interesting, because after the Python fiasco in 2012/13 I thought a new language like Go would have learned from that and done that right from the beginning and I always thought Go did it. "We don't care" is even worse than "we just don't know how, yet".
- sqs 12y agoI didn't get the sense they were celebrating their lack of care, or that they chose not to care. (They didn't create Google's build system.) They were simply stating the reality.
- _ak 12y agoDifferent people have different requirements. It makes no sense to declare some tool to be THE STANDARD(TM) if it's of no use for a large proportion of their users. The way $GOPATH works and dependencies are managed is well-documented. Everybody is free to develop their own tooling. Right now, many people flock towards godep, but that might change in the future. Also, since this is only relevant during development and for compilation, getting it right is not as important as if you had to deploy every single one of your dependencies. With Go, you get one binary, and that's what you deploy.
- ansible 12y agoAnd there are people like me who think that the programming language tooling shouldn't have to be tracking dependencies. If, for no other reason, than it is common to use multiple languages for a single project, and then a language-agnostic method should be used. I've leaned towards just having everything it our DVCS (git in our case). External libraries are handled using git subtree.
- erikb 12y agoIt is also using a defined way to handle dependencies. I have no problem with that either.
- erikb 12y ago
- jbooth 12y agoAndrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. Are you kidding me??? So if some invariant behavior on an otherwise stable API changes, I don't know until runtime that a bunch of the code that I shipped, haven't changed, and then recompiled a month later has changed it's behavior?
- wtetzner 12y agoYeah, this seems crazy to me. Also, honestly, while stable APIs can be nice, I would rather have people have the option to change the API in later versions, if it makes things better. But I want to be able to consciously decide to upgrade when I'm ready.
- enneff 12y agoYou do have that option. As I explained at the time (but this was not included in the live blog), the convention is to change the import path when the package API changes.
- enneff 12y agoIf you're shipping serious code you should be vendoring your dependencies.
- munificent 12y agoWhy?
- namsral 12y agoBecause you want to have control over all software you're shipping to production.
- simoncion 12y agoIf "vendoring" precludes one from using a dependency installed on the system, then this practice is static linking all over again. Static linking has its place, but dynamic linking with sane versioning solves many problems.
- munificent 12y ago> Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. It certainly encourages stable APIs, but I don't see how making it very painful to iterate on your API is a strategy for good ones. My experience is that doing anything well requires the ability to gather and respond to feedback. If you can't iterate, then you're doomed to be stuck at 0.0.1 levels of quality.
- supersillyus 12y agoSo, do you consider the Go1 compatibility guarantee to be a mistake? Most suggested stdlib or lang improvements are DOA for the time being as a result, which is annoying, but of course so too would be frequent breakages. I'm curious about your take, since you have some relevant experience.
- munificent 12y ago> So, do you consider the Go1 compatibility guarantee to be a mistake? No, I think a language basically has to declare that level of compatibility for a major version. The important part is to get as much real-world feedback and iteration in as possible before you bang the 1.0 gong.
- deleted 12y ago[deleted]
- jgrahamc 12y agoThis is a summary of a talk from the dotGo conference in Paris last week. Lots of good stuff was presented there. Recommend reading the other posts by sourcegraph on this and watching the videos when they come out. http://dotgo.sourcegraph.com/ http://dotgo.sourcegraph.com/
- hendry 12y agoWill there be a proper debugger I wonder?
- andrewstuart2 12y agoI'll admit I'm no expert at gdb, so I'm not aware if it falls short vs debugging c, c++, but what's wrong with using gdb?
- ganarajpr 12y agoThis is the highest and most important thing I want from go. A proper debugger that is not insanely hard to setup ( on any machine! ). Gives a complete stack trace and such info. I am not sure how people can live without a debugger in 2014. GDB is not the answer to this - for sure. There are soo many things that can be done ( tooling wise! ) and this one is , I personally think, the first things the golang guys need to do .
- cjslep 12y agoHave you tried debugging using LiteIDE? I've had mixed experiences with it, most of the time I end up using fmt anyway.
- LukeShu 12y agoWhy do you say that GDB is not the answer? In my experience, GDB (and DDD) works great with Go!
- ganarajpr 12y agoYou are probably pretty awesome at setting things up. I am not. I tried GDB, golang and windows as a combination and its an exercise in torture.
- LukeShu 12y agoThat's true, I am great at setting things up... but Go+GDB was zero set up. `go build` then `gdb ${executable_file}`, and nothing else. I suspect that it's Windows being in the mix that gave you trouble?
- cies 12y agoReading this I feel Go is boring, and that's an asset. Let me explain. Seeing [what's happening in Haskell (GHC)](https://www.haskell.org/pipermail/ghc-devs/2014-October/006518.html https://www.haskell.org/pipermail/ghc-devs/2014-October/0065...), which is soooo much more exciting; but then I totally understand that "exciting" is what you want to stay away from in some cases. In these cases a Go is a much better choice I guess.
- laumars 12y agoI often describe Go as being boring as a positive asset. For example, when people what makes Go special, I say "it's not better than any specific language at specific things, but generally better than most languages at general things." Which is extremely dull, but most of the time you do just want something straightforward, stable and ordinary when you have normal development projects. So I think Go is an extremely dull language - but personally I think that's what makes it so good.
- pmelendez 12y agoI tend to think like that about C#, the thing is I feel like there are already many dull, private company managed, programming languages out there to make me curious enough to use it in real life.
- melling 12y agoHow about a better optimizing compiler? I've been using Go and everything feels quite snappy. Justifying it use over Java on the server-side, for example, might require a little more supporting data.
- bradfitz 12y agoThat's the plan, after the compiler is converted to Go and there's an internal SSA form, etc. Also, gccgo is a very good optimizing compiler but is held back by lack of escape analysis, which I mentioned is being worked on.
- higherpurpose 12y agoGo 2.0 should be highly optimized for Android (and as a potential main language for Android) and should get even better ARMv8A support.
- king_jester 12y agoWithout generics I don't really see how that's feasible, since the Android framework leverages that feature of Java so heavily.
- codeflo 12y agoIf this is the reason to finally add generics to Go, all the better, and a lot of people puzzled by the community's copy&paste attitude to code reuse might reconsider the language. Also, this would require Google to finally polish up the Android NDK, which would be great even for non-Go users.
- joe_momma 12y agoAndroid and iOS support!
- kingmanaz 12y agoRegarding the article's mention of GopherJS: The Google Dart project should adopt Go as its language and reboot. Dart hasn't gone anywhere. GopherJS is a great low-budget transpiler and its source could be incorporated into a Go-based Dart. It would be great to see what could be accomplished with a big-budget GopherJS.
- lmm 12y agoThe big advantage of Dart over JS is the type system. Switching to Go would mean throwing that away.
- nickik 12y agoPureScript and ClojureScript all have type systems better then the one in Dart. The simplest ways to get a type system is TypeScript. Not sure how I how it compares.
- lmm 12y ago"Better" is subjective (and I certainly wouldn't consider any dynamic system to be better than dart's) - Dart hits a certain sweet spot IMO, being simpler than a typeclass-based approach but far more usable than Go or Java. TypeScript is pretty nice but gradual, which is its own set of tradeoffs. Dart has other selling points than the type system, sure, but degrading it to Go-style types would be a serious loss.
- autechr3 12y agoI wouldn't say Dart hasn't gone anywhere. Its gone from 81st place to 17th on tiobe in just 1 year. To me, that is going somewhere.
- munificent 12y agoWhile I really like Go's approach to concurrency, I don't think the rest of the language would map well to the browser whose core DOM API is designed around objects, inheritance, and exceptions.
- GFK_of_xmaspast 12y ago"at the time there was very little exotic hardware support (such as ARM). " How is ARM "exotic hardware"?
- AnimalMuppet 12y agoRemember that Go is coming out of Google, and therefore was initially run almost exclusively on desktops and servers. For a desktop or server, ARM is in fact exotic hardware.
- niix 12y agoI've been writing Go for the past couple weeks and have really enjoyed it. My day jobs is in JavaScript land all day long, and while I really love JS I was looking for something more. Go has helped me think differently about how I approach my code in JS now and continues to be a great source of knowledge.
- mariusmg 12y agoWith the risk of sounding like a asshole...if you only know JS any other language will make you think differently.
- Argorak 12y agoGiven that the parent wrote that his job is exclusively JS, not that the parent only ever learned JS or never had a job where this was otherwise: I wouldn't have taken that risk.
- alexyes 12y agoHave a look at this compiler from Go to JS. Could be useful https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs
- bigtunacan 12y agoI see he mentions "beginnings of Android support". This is something I would love to see. Does anyone know if there is a product roadmap that provides a timeline on this?
- pjmlp 12y agoThis is a community driven effort to use Go in the NDK. Android team only cares about Java as stated at Google IO 2014.
- enneff 12y agoThat's not true. The Go on Android support is being driven by David Crawshaw who works at Google.
- pjmlp 12y agoThanks for clarifying. Are you allowed to say anything regarding support from the Android team? The way Android team spoke at Google IO, I got the idea Go will only have an unofficial place on the NDK.
- xkarga00 12y agogolang.org/s/go14android
- bigtunacan 12y agoThanks for the link. That's pretty interesting, albeit it also disappointing. I'm focused on enterprise applications rather than games so it looks like I'll have to stick to Java. I understand the complexities since this is being built onto the NDK; I guess I was envisioning it more as an implementation of Go on top of the JVM.
- schmichael 12y ago> GOTRACE: emits Chrome trace viewer and will allow for us to visualize scheduler actions and more in Chrome I'm very excited about this, but I wonder if it will scale to visualize hundreds to thousands of goroutines in a useful way. That's where existing inspection tooling like logging and snapshotting goroutine dumps fall apart.
- SeanDav 12y agoI see anything that ties Go to a specific browser as a bad thing. Surely they should be browser agnostic if they want to encourage universal adoption of their language (or perhaps they don't really care about this)?
- sqs 12y agoIt's just a tool that you can use to visualize Go internals. Nothing is tying Go to any browser.
- groby_b 12y ago1) It doesn't "tie" Go to anything - it uses Chrome for visualization purposes. You can write Go fine without ever touching Chrome. 2) Large parts of the trace viewer are separate from Chrome: https://github.com/google/trace-viewer/wiki https://github.com/google/trace-viewer/wiki 3) The event format is documented, so you're free to write an alternate viewer: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQt...
- Animats 12y agoWell, it's good to have a hard-compiled language that's (almost) memory safe. Three problems with Go: - The Go mantra is "share by communicating, not by sharing". Then look at all the thread examples in "Effective Go". They all share memory, while trying to construct locks using message passing. Multi-threaded Go programs are not memory-safe. That's why Google won't let you use them on their AppEngine. Compare Erlang, which takes message passing seriously. - The lack of exceptions is resulting in hacks using the "panic" mechanism to create an exception mechanism. This is where we were with "longjmp" in C. I know someone at Google who has constructed a language on top of Go mostly to deal with exceptions. - The lack of generics is resulting in hacks using the reflection mechanism to create generics. This is painful and slow. Go has generics for built-in objects; channels and maps are parameterized types, so there's already syntax for instantiating a parameterized type. Extending that to user-defined types would not be too bad. Fear of the C++ template mess seems to have been the problem.
- kyllo 12y agoRust addresses all of these problems. It's memory safe through compile-time reference counting and borrow checking (not garbage collected), and it has exceptions and generics. It also has a more powerful type system with type inference. Having tried out both Go and Rust I don't see any reason to prefer Go, at least once Rust has a 1.0 release, which is supposed to happen the next 2-3 months. Both languages were designed to replace C++, but only Rust has the features to actually succeed at that, IMHO.
- higherpurpose 12y agoI think at this point Go is more of a replacement for Java than C++.
- kyllo 12y agoPerhaps, but the problem is, with no generics or exceptions, it might just be too low-level and not expressive enough to really be a suitable Java replacement.
- trungonnews 12y agoWill Go ever get an interactive debugger that is comparable to Java?
- module0000 12y agoLook at GDB or DDD+GDB, they are more full-featured than JDB, but do not have the IDE integration and GUI-ness that you will find in Eclipse/Netbeans. LiteIde for golang is the closest to the IDE+debugger combination you would expect if you were coming from an Eclipse/Netbeans background.
- robmccoll 12y agoAnybody up for backporting Go's stdlib to C? Doing so in an automated way would be all the better. There are just so many things in Go that feel like 80% solutions - they make great demos but in every day use you have to fight them (looking at you import system and the GOPATH, magical make() function, magical overloaded accessors, lack of expressions or at least ternary if, pre and post increment are hacks not expressions, lack of coercion to more precise types, no templating / generics / preprocessing, needs an equivalent to realloc, having to go through reflect / unsafe to get things done, lack of proper type resolution for complex types). There are many things I do like about Go, but much of the time it feels like a very pretty prison compared to the (admittedly less pretty) freedom of C.
- pjmlp 12y agoI rather use Go's pretty prison, than enjoy the freedom of buffer overruns and dagling pointers.
- azth 12y agoI'd rather port them to Rust :)
- marktangotango 12y agoCheckout the Plan 9 from user space libraries. There is the basis of go, but in a set if c libraries.