16 ms·

Rob Pike: Go at Google

268 points by jbarham 14y ago

tikhonj 14y ago
What annoys me a little bit about Go (and other projects similarly adherent to "worse is better") is the implied dichotomy between "research" and making "programming lives better". Do they think the point of Haskell isn't to make programming easier? That's what most of the research into the language is exactly about! This isn't just about Haskell either: most other PL research is also about making programming lives easier. And Go ignores essentially all of it. Now, there is even nothing strictly wrong about ignoring research like that. It's just annoying how they revel in ignoring all recent progress in the field.
- cgag 14y ago
  You aren't the first person I've seen that mention that goes ignores a lot of programming research. Would you mind expanding on that for someone who doesn't know much about PL research / theory? Are they missing things you think a modern language should have? What are they doing wrong according to research?
  - dill_day 14y ago
    You might like to check out this blog post by Cristina Videira Lopes (though it's not about Go in particular): http://tagide.com/blog/2012/03/research-in-programming-languages http://tagide.com/blog/2012/03/research-in-programming-langu...
    - twelvechairs 14y ago
      Great link. Thanks!
    - comex 14y ago
      The way I like to think of it is that a large component of PL design is making something pleasant for humans to use, which is more of an art than a science: inherently subjective (not everyone likes the same things), holistic (it's not any one feature of Python that makes it Pythonic, it's the whole philosophy), and hard to quantify. So it's no surprise that rigorous design is not the prime factor in popularity of programming languages. I don't think, however, that really explains why research languages these days have very little in common with popular languages - why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted. There are a few reasons why this might be the case (not just "FP is hard and most programmers aren't very good at programming", although that is one factor), but their sum seems to be something fundamental about software design - perhaps changeable, but identifiable as a unit, not simply a consequence of the limitations of rigorous design.
      - pcwalton 14y ago
        I don't think the divide between research and industry languages is as deep as you imply. Take your examples: purity and strict typing. Purity has been adopted wholesale by Clojure and has influenced C++11 (constexpr implies purity in addition to many other things). Go, the subject of the post, is stricter about type conversions than the C family languages are. Java's type-safe implementation of generics was influenced by ML.
        tel 14y ago
        Clojure is far from pure.
        pcwalton 14y ago
        Yeah, that was a bad choice of words; what I was getting at was the emphasis on immutability.
      - azth 14y ago
        > why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted. I am guessing is it mainly due to the inertia of the current popular languages (C, C++, Java, Python, etc.), and that none of them offer such guarantees. There are tons of libraries written in them, and so it is hard to move away from them. I am hoping that Scala and Rust will change things.
  - azth 14y ago
    While I am not an expert at PLs, one thing they definitely missed for a language that claims to be "built for scale/multicore" is immutability. Not only is it not default for variables to be immutable (like many functional/hybrid programming languages), but there is no notion of immutability built in to the language in the first place.
- leothekim 14y ago
  "This isn't just about Haskell either: most other PL research is also about making programming lives easier. And Go ignores essentially all of it." That's a bold statement, and I'm not sure that's what Rob Pike is asserting. I saw his presentation as saying "We knowingly made tradeoffs in the programming language to, in part, make managing large codebases tractable." He's right in saying that dependency management isn't intrinsic in most of programming language theory today, and it's a big productivity sink for development organizations with very large codebases.
  - kenko 14y ago
    Slides eight and nine, to me at least, suggest by the implicit contrast between research and helping programmers that the Go designers just weren't interested in the state of PL research.
    - Evbn 14y ago
      That is because PL research isn't interested in helping programmers write programs under their real world constraints. Pike isn't interested in what geologists have to say about programming languages either.
- cageface 14y ago
  Haskell is an elegant language but Haskell fans will be much more effective advocates of the language if they admit that it's conceptually very difficult for most programmers to grasp. Some of the most experienced and capable programmers I've ever known have struggled to get their head around Haskell, and I don't buy the argument that it's only because their minds have been poisoned by overexposure to other languages. Haskell is important and I'm glad it exists but I think Go has a much better chance of become a plausible alternative to Java and C++ and perhaps Python in most programming shops.
  - dlisboa 14y ago
    > and I don't buy the argument that it's _only_ because their minds have been poisoned by overexposure to other languages. I've not heard that argument. I think most Haskell people would acknowledge theirs is not an easy language to learn and program. The argument is especially non-stick because in practicality every programmer will be "poisoned" by other languages. That means that even if Haskell wasn't a hard language to learn in theory (i.e. if a "virgin" brain could learn it just fine), in practice it will be. It's easier to expand on the solid points of the language, not easiness of understanding. But like I said, I've not seen Haskell being thrown around in that fashion.
    - dbaupp 14y ago
      And to add to that, many Haskell people freely admit that they themselves barely understand all of Haskell, or still have much to learn.
  - Raphael_Amiard 14y ago
    I think Simon Peyton Jones says it best about Haskell : http://www.youtube.com/watch?v=iSmkqocn0oQ http://www.youtube.com/watch?v=iSmkqocn0oQ He says Haskell is useless. Without even debating that (it can certainly be useful for certain classes of programming problems), you can see his point : The goal of Haskell was to start from an ideal view (pure functional programming without side effects) and try and see how to make that eventually practical for everyday programming, without sacrificing the pure core of the language. You have languages, like F# (or even C# !) that takes lessons from Haskell, with at the same time being practical for pretty much every programming task (their platform , .Net, makes them useless for a lot of use cases, but that is another problem) And on the other side (in my opinion), you have languages like Go, being pretty dismissive about pretty much everything learned from languages like Haskell. I respect the point of view of Go's creator, i just disagree with it, and don't see any project i could do in Go that i wouldn't prefer doing in Scala/OCaml/C#. But more power to people who want to do great things in Go ! Go fills a niche (AOT compiled without a VM) that only OCaml fills in the list of languages i have listed, and OCaml is probably much more complicated to learn, even if it is way simpler than Haskell, so even if i don't agree with the design choices, i can see why Go could gain traction (apart from the fact that it is Google powered)
- philwelch 14y ago
  I just think Haskell and Go solve different problems.
- 6ren 14y ago
  Gosling said similar about Java https://docs.google.com/viewer?url=dfjug.org/thefeelofjava.pdf https://docs.google.com/viewer?url=dfjug.org/thefeelofjava.p...
- comex 14y ago
  I'm not sure exactly what exactly you're referring to, but I'd say it's not so much "worse is better" (in the traditional sense that simplicity of implementation is better than simplicity of interface) but "simplicity is better" (than maximum functionality, whether in implementation or interface). Generics, for instance, are not exactly recent PL research, but Go doesn't have them (yet) because they tend to add complexity to both interface and implementation. As for Haskell, well - whether or not it makes programming easier, it adds complexity, and it certainly doesn't have the 'free and light' feeling borrowed from dynamic languages that Go likes to revel in.
- btilly 14y ago
  Different software communities have different opinions on what makes life better for programmers. As far as I can see, programming language researchers are just a subset of those communities with their own sets of beliefs. On average researchers are much smarter and better educated than most programmers. However it is likely that the majority of the smartest and best educated people are NOT in academia. (Before doubting that, remember there is an eternal brain drain of top people from academia to industry for the simple reason that industry pays more.) In the case of the developers of Go, we are talking about people who I believe to be smarter than the vast majority of programming language researchers, and who _definitely_ have more experience around large software systems. They have come to different opinions about what makes that kind of development work. People like Ken Thompson and Rob Pike might not be right, but it would be unwise to assume that they are necessarily wrong simply because they disagree with a bunch of programming language researchers.
  - Raphael_Amiard 14y ago
    > In the case of the developers of Go, we are talking about people who I believe to be smarter than the vast majority of programming language researchers Why would you have such an opinion ? I can turn the problem in my head a thousand times, i still can't see why. Because it is from the makers of Unix ? The only way i could make sense of your statement is by saying people who makes the most used technology are the most clever, intrinsically. But i think this is an incredibly naive point of view. I can see a bunch of things that make Go susceptible to have success : Traction, from the name of it's inventors and main sponsor (Google). Simple philosophy that makes it easy to learn, and pragmatic orientation. It doesn't mean it's a better language in any way. Just that it's aiming for the path of least resistance. It is a respectable goal. Now i don't see the logic in saying that PL researchers are not as smart because they have more idealistic goals.
    - xyproto 14y ago
      That wasn't what he said, though.
    - gbog 14y ago
- brianobush 14y ago
  One of the original goals of Go was to be a practical systems PL; that isn't one of Haskell's goals which focus on higher-order programming.
- Evbn 14y ago
  Haskell's designers believe in the goal of great pegramming, but they refuse to compromise today to help engineers. Haskell Ultimate will be better than Go. But it doesn't exist yet.
- Jare 14y ago
  The slides (and plenty other Go literature) describe the metrics used to decide Go features in quite a lot of detail. If these metrics are applicable in your context, then Go is more likely to "make your life better" than Haskell. Can you point out to specific PL research results that Go has outright ignored, rather than decided against for X reasons?
  - riffraff 14y ago
    this is a very interesting question, but can it be answered? I mean, we can say that design by contract (or linq/multiple dispatch/type state/whatever) offers an interesting solution to common problems and was ignored. But.. just because it's not listed in the FAQs?
  - azth 14y ago
    Immutability.
- grey-area 14y ago
  It is strange the way negative comments float to the top of most HN stories, but I guess it sometimes makes for interesting debates. Do they think the point of Haskell isn't to make programming easier? This comment makes me genuinely curious, why do you feel Haskell has not taken off? Do you feel it is easier than Go to use or to pick up?
  - peteretep 14y ago
    Do you spend most of your time "programming" learning how to program? Or using what you've learned? Haskell has a steep learning curve, for sure, and that's one reason it doesn't have widespread use. Once you've learned it, programming in it is arguably a lot more enjoyable (and thus easier) than other languages...
    - grey-area 14y ago
      It seems a lot of people have trouble ever escaping the steep learning curve stage in Haskell, but it does look interesting and your post has inspired me to go take a look at the Haskell intro docs. However I definitely wouldn't group Go with 'worse is better' languages like PHP, so that seems an inaccurate description to me. I suppose what I was interested to know from those advocating Haskell as intrinsically better than Go was whether the learning curve is the only issue with Haskell, or whether there are also times in daily use where it sacrifices ease of use/comprehension for power, as opposed to Go where there is a great emphasis on making the language itself as simple as possible, even at the cost of some convenience.
    - _feda_ 14y ago
      Ultimately it's not practical to use it, so even if it is easier to use after the great hump of the learning curve, it's still not good for real world applications, principally because of libraries, support and ubiquitousness . Certain languages reach terminal velocity, whereupon their real world usefulness goes up exponentially, and whether they are well designed or not the become practically necessary.
- emmelaich 14y ago
  I think it's about the long game. Go is for now. Haskell is for eventually. Mostly.
- dscrd 14y ago
  >Do they think the point of Haskell isn't to make programming easier? That's what most of the research into the language is exactly about! After a decade of trying to "get" Haskell, I have to say that they are doing an awful job at it.
- fauigerzigerk 14y ago
  I don't think making the lives of a maximum number of today's industrial software engineers simpler is the main concern of academic PL researchers, nor should it be. A PL researcher should be able to spend time working on formal aspects of some thought experiment without thinking about interoperability, compile times, social issues in large corporations, etc. And then programming languages are user interfaces. Hence, researching them is a social science and a cognitive science as much as it is a formal science. I don't hear much about that aspect from PL researchers. Arguably, language designers with an industrial background know a lot more about that than academic PL researchers. It may not be very scientific, but they should have pretty good intuitive access to these things.
  - Evbn 14y ago
    Why should PL researchers care only about languages and lot about language usage? Only about programs and not how to create them? That seems extremely ivory tower to no good.
    - fauigerzigerk 14y ago
      I believe they do care about that, but it shouldn't limit their thinking too much. For instance, there could be a wonderful model of computing that no current machine can efficiently implement. Kind of like Lisp in the 1950s.
- JulianMorrison 14y ago
  For what it's worth, Rust includes a lot of pragmatically useful research stuff that was passed over in Go. In particular, I think Rust's emphasis on immutability is a better decision that will result in faster, lock-free code. (Yes, it counts as locking when you have to pass the one-and-only pointer to a thing over a channel just to read it.) But Rust is a big complicated language. Go is syntactically tiny, and that's an advantage in an number of ways, from speed of compilation to ease of use.
  - pcwalton 14y ago
    Usually when people say "big and complicated", they mean C++, which Rust is much simpler than. We put a lot of effort into keeping Rust as minimalist as possible without sacrificing the language goals. It's certainly a bigger language than Go, of course.
    - deleted 14y ago
      [deleted]
- aufreak3 14y ago
  "Research" is about producing new knowledge about something, which in this case is programming computers. The slide on the problems that the Go system solves points out things the solving of which is unlikely to yield significant new knowledge in the domain. Yet solving those problems does improve the lives of programmers and so is a valuable engineering contribution. For some problems, they do reuse techniques that are at least two decades old. Putting import information in compilation units at the head to speed up compilation was already done in Turbo Pascal and is available in Free Pascal today. They also did take up CSP as a concurrency model. "Do they think the point of Haskell isn't to make programming easier?" The point of Haskell was stated by the community much early on -- that they'd try to "avoid success at all costs". "Making programming easier" isn't even a clearly definable research goal I think. Easier for who? .. for which problems? .. on which kinds of machines and environments? Haskell, as I see it, is a platform for experimenting with new techniques and asking "what if?" questions. A sandbox to play in. If it happens to make certain kinds of programming tasks easy and elegant, that's a by product.
  - kenko 14y ago
    The focus on Haskell as an alternative is unfortunate. What about, say, Racket? There's a language that emerged out of PL research, by researchers that clearly care about getting programming concepts across to people (The Little Schemer, etc.), that's pragmatically oriented and has a lot of research-derived neat features. Is the problem that there are too few Racket boosters? Racket seems pretty swell to me.
    - krutulis 14y ago
      Good point. The focus on evaluating the success or failure of programming languages as a popularity contest is also unfortunate. There is also the matter of influence. In the mid 80's I took Dan Friedman's (author of The Little Schemer) Programming Languages course and simply had a ton of fun learning all about Scheme & the implementation of languages. I had no idea at the time it would be by far the most important class that I took as either an undergraduate or graduate student. Turns out, one of the most important things programming languages do is influence the way we learn and think about computation. I've learned crucial lessons from Scheme and all the languages I've worked in over the years. To this day, I am perplexed by people so vested in one programming language that they fear instead of savor the chance to work in another. As a math major, a key lesson demonstrated so vividly by Prof Friedman & by the philosophy of Scheme resonated with me personally: the importance of clearly understanding "what depends on what?" and of learning which things can and/or should be made fundamental and which derivative. The Golang Team has looked at their problem domain and, through the creation of Go, has built a striking and innovative statement on what they've judged as fundamental. I welcome their emphasis on selectivity over accumulation and believe there is much to be learned from their choices.
jlgreco 14y ago
As a warning, there seems to be no mouse-navigation of these slides. You have to use a keyboard. (or touch, probably)
- cschmidt 14y ago
  I was wondering what system created the slides as well. Anyone know?
  - codewright 14y ago
    Not to be a smart-ass but: http://talks.golang.org/static/slides.js http://talks.golang.org/static/slides.js From that: // Copyright 2012 The Go Authors. So, I'm going to go with, "we wrote this ourselves and reused some code from other places in a couple spots". Btw, holy-hell 2413 lines, they have to be using a generator for this.
    - krakensden 14y ago
      Most of those lines are just linebreaks, and it's a fairly long slidedeck, so it's not impossible. But you're right, it's generated from a simple, markdown-like format: https://code.google.com/p/go/source/browse/present/parse.go?repo=talks https://code.google.com/p/go/source/browse/present/parse.go?...
  - stephen_mcd 14y ago
    It's a tool called Present written by Rob Pike and Andrew Gerrand from the Go team: https://code.google.com/p/go/source/browse/present?repo=talks https://code.google.com/p/go/source/browse/present?repo=talk... They gave a presentation about it a couple of weeks ago at the Sydney golang meetup. It has an interesting feature where it runs a built-in websocket server that can be used to embed code in the presentation, and have it compile and execute output directly back into the presentation itself. I believe it's similar to the tech running behind the play.golang.org site.
    - warmfuzzykitten 14y ago
isbadawi 14y ago
I was a bit confused at slide 35 where he said that Go's declaration syntax is "easier to parse -- no symbol table needed" as I don't typically think of a symbol table being involved in parsing. Here's an interesting comp.compilers thread from 1998 about parsing C++: http://compilers.iecc.com/comparch/article/98-07-199 http://compilers.iecc.com/comparch/article/98-07-199
- pcwalton 14y ago
  I read that as referring to the lexer hack: http://en.wikipedia.org/wiki/The_lexer_hack http://en.wikipedia.org/wiki/The_lexer_hack
- abhayb 14y ago
  Couldn't pass this one up seeing as I should actually be dealing with this for a class instead of commenting on Hacker News. What it means is that certain sets of symbols cannot be parsed unambiguously without information generated during the parse itself (the grammar is not context-free). The link in the sibling comment has the canonical example: foo * bar; can either be parsed a multiplication or a declaration depending on whether "foo" has been typedefed previously. So you need to keep track of typedefs in a symbol table to correctly parse things. The biggest problem with this is that many parser generators (including yacc) are much harder (if not impossible) to use with context sensitive grammars.
  - sytelus 14y ago
    To me it looks like Go is designed to make compiler writer's life easier rather than programmers. Why is it so important to save on symbol table if it does make language less intuitive (at least for people with C background)? We should be moving towards compilers that are capable of dealing with even more closer to natural semantics, not the other way around. I'm suspecting similar mindset was at work when making decisions on error handling which, IMO, is the most appalling part of Go. If you have coded in C most of your life then it's same ugliness as usual but for others it's a huge move backward. Again the designers of Go could have implemented exceptions and let programmers choose what mechanism they prefer. This would be same as in Java or C# where a programmer can choose to return error values instead of raising exceptions. But I guess that would be more work for compiler writers.
simonsarris 14y ago
Sorry to veer off topic, but why is the golang site so ugly? I clicked on the link in the second slide: http://golang.org http://golang.org compare with: http://www.ruby-lang.org/en http://www.ruby-lang.org/en http://git-scm.com/ http://git-scm.com/ http://www.haskell.org/haskellwiki/Haskell http://www.haskell.org/haskellwiki/Haskell Even Dart looks great: http://dartlang.org/ http://dartlang.org/ I feel a little guilty being negative about this, but presentation does matter, and Google ought to be able to afford it.
- geoka9 14y ago
  Not to hijack the thread; please see this: http://news.ycombinator.com/item?id=4551907 http://news.ycombinator.com/item?id=4551907
- beatgammit 14y ago
  I think it's nice. It's super functional and easy to find information. It may not be pretty, but I know exactly where to go to find what I want. I like that the urls are consistent. To find package documentation, I go to golang.org/pkg/<name of import>. For example, for http docs, I go to golang.org/pkg/net/http. For most languages, I resort to a Google search to find package docs. This is true for python, c++, and even Java. I rarely have to google search something in Go. I think the site very much fits in with their goal of simple and orthogonal. I actually wish more language documentation followed suit and made it easier for programmers to search for docs. Sure, everyone wants a pretty site, but it's not like they need to advertise anything. It gets the job done very efficiently.
  - dualogy 14y ago
    Regarding docs, what's also extremely neat is, when you're offline, just run "go doc" and it starts an HTTP server on your local machine to serve the exact same fine documentation experience. So thoughtful, one of many small details just part of the overall package, when you need them you find them easily and are delighted.
- krelian 14y ago
  It's simply and minimalist. Just like the language.
eternalban 14y ago
http://talks.golang.org/2012/splash.slide#48 http://talks.golang.org/2012/splash.slide#48 Time for honesty: What bullshit. - Go codebases by non experts are peppered with magical incantation (sleeps, etc.) to avoid the dreaded "all goroutines are sleep". Of course "they are doing it wrong", but that is the germinal point. - A concurrent Go program will likely behave differently given 2 bits (just 2 lousy bits) of difference in the object binary. (runtime.GOMAXPROCS(1) vs runtime.GOMAXPROCS(2)). Imagine someone touching those 2 bits in a "large codebase". It is practically impossible to do the same thing in a large Java codebase and fundamentally change the programs runtime behavior. (Happens all the time in Go.) - It is very difficult to reason about a Go routine's behavior in a "large codebase" without global view and a mental model of the dynamic system e.g. which go routine is doing what and who is blocking and who is not. Pretty much defeats the entire point of "simple" concurrency, to say nothing of "scaling". Programming in Go's variant of cooperative multithreading is actually more demanding than preemptive multithreading. Cute little concurrency pet tricks aside, Go concurrent programming actually requires expert level experience. "You are doing it wrong". Of course. Point. - There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java. Sure, the cute syntactic go func() needs to be replaced with method calls to the excellent java.util.concurrent constructs, but the benefits -- high performance, explicit-no-magic-code -- outweigh the cute factor in this "programmer's" book. - On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go. - Once we factor in the possibility for bytecode engineering, then Java is simply in another higher league as far as language capabilities are concerned. (Most people who rag on Java are clearly diletantes Java programmers.) If Go actually manages to be as effective as Java for concurrent programming at some point in the future (when they fix the somewhat broken runtime) then the Go authors are permitted to crow about it. Until that day, go fix_the_runtime() and defer bs(). One thing that programming in Go has made me realize is just how awesomely Sun/Gosling, et al. hit that "practical programming" sweet spot. No wonder the modern enterprise runs on Java and JVM. It just works. (But it is "boring" because it's not bling anymore. Oh well, kids will be kids.)
- jpeterson 14y ago
  What in the world are you talking about?
lukehutch 14y ago
Favorite quote: "While that build runs, we have time to think."
- beatgammit 14y ago
  Ah, I remember my first job, where I worked on a huge, legacy C++ project. My first day of work was spent building and fixing linker errors. After that, to test it, I rebuilt everything from scratch, and it took about that long, 30-45 minutes. While waiting for it to build, I wrote my own PHP time tracking system (click when I got in, click again when I went home). Ironically, wasting a day on compiling caused me to save hours worth of work keeping track of hours.
- btilly 14y ago
  That reminds me of a story that I read ages ago. It happened in the 1980s. This group of programmers had taken to exercising while waiting for compiles. They were all buff. Then Turbo Pascal came out and they all turned back into couch potatoes. :-)
  - pjmlp 14y ago
    Then C become widespread and they became fit again! :) I really miss Turbo Pascal compile times.
  - tommorris 14y ago
    Exercise. That's what I'm supposed to be doing while Maven downloads the Internet.
wnoise 14y ago
One of the few nice things about the C include mechanism is that it's pretty easy (and standard practice) to set up separate implementation and interface files. If the implementation of something changes, but not the interface, I don't want to have to recompile all the clients. This is lost in almost all "modern" languages. (This is, of course, horribly broken in C++ which likes to inline everything.)
- Evbn 14y ago
  Java has interfaces.
  - wnoise 14y ago
    Not the same thing. Think public-vs-private portion of a class.
    - pjmlp 14y ago
      The only advantage Go interfaces have over interfaces in other languages, is that you can make third party code comply to a given interface if you're lucky enough to have the same set of methods available. Even then, you might hit the issue that although the interface matches syntactical, the semantic meaning of the method calls differs. For the CS folks, Go interfaces are nothing more than structural typing, available almost any FP language. The only advantage over Java, C#, D is that you are not required to state explicitly which interfaces a given type implements. However this forces you to use tools to discover which interfaces a given type implements.
- agentS 14y ago
  As far as I can tell, there are 2 advantages to the separated header file, implementation file pattern in C. First, you get easy documentation of a library's API, and second, the advantage that you mentioned (implementation changes do not necessitiate a full recompile). I would argue that both of these (or atleast the core of these) is addressed by Go. For documentation, there is a simpler way to get at a library's public API; an automated program that extracts that API and presents it in a web page (or in your console). See http://golang.org/pkg/unicode/utf8/ http://golang.org/pkg/unicode/utf8/ for an example (for completeness, here is the file it is generated from http://golang.org/src/pkg/unicode/utf8/utf8.go http://golang.org/src/pkg/unicode/utf8/utf8.go) For avoiding unnecessary recompiles, Go solves this problem by making compiles really fast, rendering this problem moot.
lnanek2 14y ago
I never liked Go, but I admit I like it a lot more if it means I don't have to deal with Maven and other dependency systems as much like the slides say. I've been doing Android since it came out, but before that I was J2EE, and it could be hell if Hibernate needed a different version of a dep than something else in your code stack, for example. Handling JARs by hand stopped working, and the countless XMLs files listing deps for all parts of the system and library started getting full of overrides and the like. Eventually Oracle rewrote all the class loading for their app server which allowed dependencies to have dependencies which were invisible to apps using them. So something as basic as class loaders had to be completely reworked to deal with this, and it was still damn complex and a pain in the ass.
- codewright 14y ago
  >I never liked Go, but I admit I like it a lot more if it means I don't have to deal with Maven and other dependency systems as much like the slides say. Hrm, yeah, there are alternatives here. (Not in Java-land...other places.) > I've been doing Android since it came out, but before that I was J2EE, and it could be hell if Hibernate needed a different version of a dep than something else in your code stack, for example. You really should look into Clojure.
  - geoka9 14y ago
    Wait, isn't easy access to Java libraries one of the premises of Clojure? In that case Java's dependency issues still apply?
    - codewright 14y ago
      Yeah but then you get to use Leiningen, not Maven. Leiningen is manna from heaven.
ddon 14y ago
slide show didn't work for me in FireFox... haven't tried it in Chrome :) Update: was trying to use a mouse to switch between slides, but later tried, and figured out that it only works with keyboard :)
etrain 14y ago
I'm pretty stoked on Go. I freaking love C. Love it. It's like they took C and went to the best disciples of C's creators and said "look - we've got these problems now nobody envisioned 40 years ago. Can you make C for us again, but better?" And they said "yes!" and it was good. We get some nice concurrency primitives, garbage collection, cleaner syntax, something between structs and objects that fits the right feeling, automatic bounds checking, cute array syntax, and a big-ass, well defined standard library. Oh, and this concept of interfaces that is so well executed it's not even funny. Except. I feel like they are forcing the fanboy mindset. At one point in this slide deck, there is the following bullet: "The designs are nothing like hierarchical, subtype-inherited methods. Much looser, organic, decoupled, independent." I didn't see the talk. But that is the most vapid, meaningless description I've ever seen of a feature of a programming language. Rob might as well have said, "it's hipster better," which would have conveyed exactly as much meaning. So here's my question - and I hope there are real answers - can someone point me to >3 real, big systems that are built using Go? I'll accept Google internal systems on faith.
- Jare 14y ago
  > It's like they took C and went to the best disciples of C's creators I'm confused, didn't they go to the _actual_ C creators? Or am I misunderstanding something?
  - icebraining 14y ago
    Except for Ken Thompson, not really. Neither Dennis Ritchie nor Brian Kernighan (K&R) were involved in Go, as far as I know.
    - _ak 14y ago
      Ken Thompson wasn't actually involved in the development of C. He created B, though.
- danieldk 14y ago
  Oh, and this concept of interfaces that is so well executed it's not even funny. http://golang.org/doc/go_faq.html#nil_error http://golang.org/doc/go_faq.html#nil_error
eta_carinae 14y ago
I was having lunch with a friend of mine who works at Google a few weeks ago and I asked him how popular Go was at Google. He said the only people using it are the Go team. Java and C++ continue to reign supreme at Google.
- enneff 14y ago
  Your friend is out of the loop. I am one of the Go readability reviewers, and I review thousands of lines of Go code each week. The code is written by Googlers from different teams around the world. It is true that Go is in the minority compared to C++ and Java. Change takes time at a company of this size. But the graphs are all up and to the right, and the rate of Go code being written at Google is accelerating.
  - pjmlp 14y ago
    So when do we expected it listed as an official Google language?
    - Symmetry 14y ago
      It already is.
      - pjmlp 14y ago
        I fail to see it like that. It is not listed here: http://google-styleguide.googlecode.com/svn/trunk/ http://google-styleguide.googlecode.com/svn/trunk/ These guides are much more than just what gofmt does. In a Google IO conference talk someone stated that the Google App Engine support was actually made by the Go team. Not all new APIs released by Google tend to offer Go APIs as well from day 1. So I miss the official language support that you say already exists.
        enneff 14y ago
        Google had four canonical languages: C++, Go, Java, and Python. They are defined internally in an engineering handbook. There is no such similar style guide for Go, as a a lot of what the existing guides say is "don't use x." If that were needed for Go we would have failed.
Evbn 14y ago
I don't get the interface stuff. If you had a method on an interface, you have to add it to all implementors, or clients won't compile. How is that different from Java? Java just adds the implements declaration, so Eclispse can help you find those implementations, instead of making you pore over compiler error listings.
- isbadawi 14y ago
  In Java, you can run into situations where two classes share a method, but because they don't implement a common interface, for instance because they're part of two different libraries, you can't e.g. write a method that accepts instances of either. You can't straightforwardly take advantage of polymorphism. In Go this is never an issue; you can declare an interface that captures the methods you're interested in, and the existing code automatically implements it. It's kind of like duck typing in python (e.g. this function will work on any object that has a method <x>), except it's statically typed.
  - pjmlp 14y ago
    Just because the method complies to the interface does not mean it does what you would expect from it. static fulfilment != semantic fulfilment.
    - msbarnett 14y ago
      You could equally say that just because a class declares that it "implements" an interface, it doesn't mean it does what you would expect from it. In practice, there is no language that can save you from people with malicious intent to confuse you. In practice, this is rarely an issue.
      - pjmlp 14y ago
        There is a big difference. When a developer makes a class implement an interface s/he signing a contract thus validating assumptions. When a type in Go matches an interface, it happens by chance.
ek 14y ago
I think all of the keynotes at OOPSLA this year were surprisingly engaging. I've seen a lot of Go talks from various Googlers, and I have to say that this was the best-motivated, most humble, and most honest of them that I have seen. Rob knew he was speaking to an extremely PL-oriented audience, and structured his talk accordingly, and the result was fantastic. Go comes from a very different standpoint than almost all academic PL work, and in that respect, for those of us in academia, it's an interesting breath of fresh air and a reminder of the uniquely fine line between industry and academia in computer science.
nnq 14y ago
Thinks like this have an unnerving "smell": "Dependency hygiene trumps code reuse. Example: The (low-level) net package has own itoa to avoid dependency on the big formatted I/O package." ...now, if this kind of attitude stays in the core dev land I don't really care about it. But when I'll consider Go as an alternative for a large project, I'll start worrying if people adopt the "it's OK to reinvent some wheels" philosophy when they start building higher level frameworks in Go... I mean, how hard can it be to split the "big formatted I/O package" into a "basic formatted I/O" package and an "advanced formatted I/O package" that requires the first one, and have the "net" package only require "basic formatted I/O" (or maybe even make "basic formatted I/O" something like part of the language "built ins" or smth - I don't know Go so I don't know the Go terms for this)?
- agentS 14y ago
  > I'll start worrying if people adopt the "it's OK to reinvent some wheels" philosophy when they start building higher level frameworks in Go... I certainly don't have this philosophy, and I don't know thats its a thing amongst Go programmers. I think its just a standard library thing. > I mean, how hard can it be to split the "big formatted I/O package" into a "basic formatted I/O" package and an "advanced formatted I/O package" It would easy, but then you're cluttering your library to make implementing the std lib easier, rather than making the lives of people using the std lib easier. > or maybe even make "basic formatted I/O" something like part of the language "built ins" Things that are in the language built-ins would need to go in the spec, and would need to be implemented by two separate compiler suites. The authors seem to be doing their best to keep the core as small as possible. Having libraries written in Go is cleaner, reusable across compilers, and give newcomers a place to read idiomatic Go.
  - nnq 14y ago
    > It would easy, but then you're cluttering your library to make implementing the std lib easier yeah, but the "advanced formatted I/O" package can include all the function from the "basic" one (i.e. act as if it contains all the functions and structs from both of them) and be the only package 90% of regular language users know about, and if happened to need to write some low level code that only needed the "basic/low-level formatted I/O" I would just import that ...it just seems 100x more "sane" to do it this way
smegel 14y ago
> It can be better to copy a little code than to pull in a big library for one function. I just don't get this. If you statically link in small functions from a big library, you only get the little bit you need anyway. Are they saying you avoid compiling the "big library" over and over? But if it is already compiled, that should not be necessary. And the chances are you are going to be importing lots of "little code" from the "big library" anyway. Unless they are saying the implementation of net's itoa is somehow simplified and not a just a straight code copy...otherwise I don't understand this approach.
- wsxiaoys 14y ago
  It does have simplified the implementation: strconv: http://golang.org/src/pkg/strconv/itoa.go http://golang.org/src/pkg/strconv/itoa.go net: http://code.google.com/searchframe#y_XiVF8bBuQ/src/pkg/net/parse.go&q=itoa%20net%20package:go%5C.googlecode%5C.com&type=cs&l=175 http://code.google.com/searchframe#y_XiVF8bBuQ/src/pkg/net/p...
- beagle3 14y ago
  > And the chances are you are going to be importing lots of "little code" from the "big library" anyway. That "big library" is often supported by someone else. One day, a year down the line, you realize startup time for you executables went from 0.01s to 2s because Big Library's initialization code now scans all subdirectories for some caching optimization, and stuff like that - stuff that's a win for general users of biglib, but not for you. > I just don't get this This is not about theory, it's about practical experience. You'll notice that successful C/C++ libraries tend to include everything that's small enough and that they need to function - because dependencies byte you later on. e.g. libav/ffmpeg has its own copy of md5, libtcc has its own slab allocator, gsl has its own everything, everything ships with a copy of libz in case the system libz is borked. The Go library just starts applying this principle a little earlier - inside the standard library. I suspect that's because they envision a python-style batteries-included extensive standard library, which has no benevolent dictator to put order in it.
lmirosevic 14y ago
"Go has garbage collection, only. [...] Day 1 design decision." http://talks.golang.org/2012/splash.slide#51 http://talks.golang.org/2012/splash.slide#51 Can someone tell me why GC was the obvious choice as opposed to say automatic reference counting?
- ybaumes 14y ago
  Maybe because they don't want the production code to deal with reference cycles? I don't know the real reason, better to ask Rob Pike directly ! :)
- jlouis 14y ago
  If you squint your eyes enough, automatic reference counting is a garbage collection method. But if you are going down that road, there are other garbage collector schemes which often produces way better performance in the common situations, i.e., copying collection or Mark'n'sweep. But it is a trade-off. Refcounting collectors need to address pointer cycles. And they are also quite slow due to all the refcount bookkeeping going on all the time. But they have the nice property that the lifetime of an object won't linger around in a zombie state. And there are no point in time where the system is in a "collecting" state and cannot give service. That said, many modern, multi-core malloc() routines contain a lot of ideas from GCs in them. The gap is closing fast.
- dsymonds 14y ago
  Because tracking memory allocation and ownership in a concurrent program is very hard. Programmers have to track a lot of that stuff in their heads, and it's easy to make mistakes. If the language is garbage collected, however, the programmer doesn't have to think about that.
ybaumes 14y ago
Does someone knows wath is the reference to Tom Cargill and "PI" in the 16th slides please? I did not find anything on Google.
pswenson 14y ago
Didn't we try error codes back in the day? I think exceptions are brilliant. They let you write your error code in one place (at the top of the stack), instead of planning for every contingency at every level. Once I discovered exceptions back in the 90s, life got a lot easier. Of course Java ruined exceptions with the invention of the CheckedException, maybe this tainted the Go designers' thinking?
- ConstantineXVI 14y ago
  As someone that grew up with exceptions, I like the idea of errors being recoverable by default. If it's not fatal, your catch block is going to swallow the exception anyway. And if your error is, panic(). (This could be Java experience scarring my then-young mind)
  - pswenson 14y ago
    Most exceptions aren't recoverable. They are usually a result of bugs or system problems. This means 1) the bug needs to be fixed. 2) the system needs to be fixed (start up a DB service, clean disk-space, add memory, etc). This is where java went wrong, java checked exceptions treats everything as recoverable when recovery is unlikely. I mean, someone tries to login to a web site and the DB is down. What do you do? Or there is a bug that throws a null pointer exception. How do you recover from that? I think the error code approach has the same effect as CheckedExceptions. People will tend to code to ignore the problems and not report them. Exceptions are great in that they bubble up to the top of the stack, so they are easy to report/alert on.
- msbarnett 14y ago
  The designers of Go rejected exceptions because, while seemingly simple, they are exceptionally hard to do correctly, and worse, it is extremely hard and subtle to distinguish between code that reasons about them correctly and code that does not. Raymond Chen has a good break-down of the problem here: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...
tomdeakin 14y ago
I spent a year working on a project in Go, so got pretty used to the language. One thing I did wonder though was how would it fare on very large systems; how could Go hook up to work like MPI across clusters of computers?
drivebyacct2 14y ago
I miss uriel to respond to some of the really inexplicable posts on this thread. :(
ExpiredLink 14y ago
http://talks.golang.org/2012/splash.slide#11 http://talks.golang.org/2012/splash.slide#11 > Pain > What makes large-scale development hard with C++ or Java (at least): None of the points apply to Java.
pdog 14y ago
I can't be the only one for whom this presentation is completely broken on the iPad (scrolling to fast and skipping multiple slides).

268 points by jbarham 14y ago

What annoys me a little bit about Go (and other projects similarly adherent to "worse is better") is the implied dichotomy between "research" and making "programming lives better". Do they think the point of Haskell isn't to make programming easier? That's what most of the research into the language is exactly about! This isn't just about Haskell either: most other PL research is also about making programming lives easier. And Go ignores essentially all of it. Now, there is even nothing strictly wrong about ignoring research like that. It's just annoying how they revel in ignoring all recent progress in the field.

cgag 14y ago
You aren't the first person I've seen that mention that goes ignores a lot of programming research. Would you mind expanding on that for someone who doesn't know much about PL research / theory? Are they missing things you think a modern language should have? What are they doing wrong according to research?
- dill_day 14y ago
  You might like to check out this blog post by Cristina Videira Lopes (though it's not about Go in particular): http://tagide.com/blog/2012/03/research-in-programming-languages http://tagide.com/blog/2012/03/research-in-programming-langu...
  - twelvechairs 14y ago
    Great link. Thanks!
  - comex 14y ago
    The way I like to think of it is that a large component of PL design is making something pleasant for humans to use, which is more of an art than a science: inherently subjective (not everyone likes the same things), holistic (it's not any one feature of Python that makes it Pythonic, it's the whole philosophy), and hard to quantify. So it's no surprise that rigorous design is not the prime factor in popularity of programming languages. I don't think, however, that really explains why research languages these days have very little in common with popular languages - why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted. There are a few reasons why this might be the case (not just "FP is hard and most programmers aren't very good at programming", although that is one factor), but their sum seems to be something fundamental about software design - perhaps changeable, but identifiable as a unit, not simply a consequence of the limitations of rigorous design.
    - pcwalton 14y ago
      I don't think the divide between research and industry languages is as deep as you imply. Take your examples: purity and strict typing. Purity has been adopted wholesale by Clojure and has influenced C++11 (constexpr implies purity in addition to many other things). Go, the subject of the post, is stricter about type conversions than the C family languages are. Java's type-safe implementation of generics was influenced by ML.
      - tel 14y ago
        Clojure is far from pure.
        pcwalton 14y ago
        Yeah, that was a bad choice of words; what I was getting at was the emphasis on immutability.
    - azth 14y ago
      > why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted. I am guessing is it mainly due to the inertia of the current popular languages (C, C++, Java, Python, etc.), and that none of them offer such guarantees. There are tons of libraries written in them, and so it is hard to move away from them. I am hoping that Scala and Rust will change things.
- azth 14y ago
  While I am not an expert at PLs, one thing they definitely missed for a language that claims to be "built for scale/multicore" is immutability. Not only is it not default for variables to be immutable (like many functional/hybrid programming languages), but there is no notion of immutability built in to the language in the first place.
leothekim 14y ago
"This isn't just about Haskell either: most other PL research is also about making programming lives easier. And Go ignores essentially all of it." That's a bold statement, and I'm not sure that's what Rob Pike is asserting. I saw his presentation as saying "We knowingly made tradeoffs in the programming language to, in part, make managing large codebases tractable." He's right in saying that dependency management isn't intrinsic in most of programming language theory today, and it's a big productivity sink for development organizations with very large codebases.
- kenko 14y ago
  Slides eight and nine, to me at least, suggest by the implicit contrast between research and helping programmers that the Go designers just weren't interested in the state of PL research.
  - Evbn 14y ago
    That is because PL research isn't interested in helping programmers write programs under their real world constraints. Pike isn't interested in what geologists have to say about programming languages either.
cageface 14y ago
Haskell is an elegant language but Haskell fans will be much more effective advocates of the language if they admit that it's conceptually very difficult for most programmers to grasp. Some of the most experienced and capable programmers I've ever known have struggled to get their head around Haskell, and I don't buy the argument that it's only because their minds have been poisoned by overexposure to other languages. Haskell is important and I'm glad it exists but I think Go has a much better chance of become a plausible alternative to Java and C++ and perhaps Python in most programming shops.
- dlisboa 14y ago
  > and I don't buy the argument that it's _only_ because their minds have been poisoned by overexposure to other languages. I've not heard that argument. I think most Haskell people would acknowledge theirs is not an easy language to learn and program. The argument is especially non-stick because in practicality every programmer will be "poisoned" by other languages. That means that even if Haskell wasn't a hard language to learn in theory (i.e. if a "virgin" brain could learn it just fine), in practice it will be. It's easier to expand on the solid points of the language, not easiness of understanding. But like I said, I've not seen Haskell being thrown around in that fashion.
  - dbaupp 14y ago
    And to add to that, many Haskell people freely admit that they themselves barely understand all of Haskell, or still have much to learn.
- Raphael_Amiard 14y ago
  I think Simon Peyton Jones says it best about Haskell : http://www.youtube.com/watch?v=iSmkqocn0oQ http://www.youtube.com/watch?v=iSmkqocn0oQ He says Haskell is useless. Without even debating that (it can certainly be useful for certain classes of programming problems), you can see his point : The goal of Haskell was to start from an ideal view (pure functional programming without side effects) and try and see how to make that eventually practical for everyday programming, without sacrificing the pure core of the language. You have languages, like F# (or even C# !) that takes lessons from Haskell, with at the same time being practical for pretty much every programming task (their platform , .Net, makes them useless for a lot of use cases, but that is another problem) And on the other side (in my opinion), you have languages like Go, being pretty dismissive about pretty much everything learned from languages like Haskell. I respect the point of view of Go's creator, i just disagree with it, and don't see any project i could do in Go that i wouldn't prefer doing in Scala/OCaml/C#. But more power to people who want to do great things in Go ! Go fills a niche (AOT compiled without a VM) that only OCaml fills in the list of languages i have listed, and OCaml is probably much more complicated to learn, even if it is way simpler than Haskell, so even if i don't agree with the design choices, i can see why Go could gain traction (apart from the fact that it is Google powered)
philwelch 14y ago
I just think Haskell and Go solve different problems.
6ren 14y ago
Gosling said similar about Java https://docs.google.com/viewer?url=dfjug.org/thefeelofjava.pdf https://docs.google.com/viewer?url=dfjug.org/thefeelofjava.p...
comex 14y ago
I'm not sure exactly what exactly you're referring to, but I'd say it's not so much "worse is better" (in the traditional sense that simplicity of implementation is better than simplicity of interface) but "simplicity is better" (than maximum functionality, whether in implementation or interface). Generics, for instance, are not exactly recent PL research, but Go doesn't have them (yet) because they tend to add complexity to both interface and implementation. As for Haskell, well - whether or not it makes programming easier, it adds complexity, and it certainly doesn't have the 'free and light' feeling borrowed from dynamic languages that Go likes to revel in.
btilly 14y ago
Different software communities have different opinions on what makes life better for programmers. As far as I can see, programming language researchers are just a subset of those communities with their own sets of beliefs. On average researchers are much smarter and better educated than most programmers. However it is likely that the majority of the smartest and best educated people are NOT in academia. (Before doubting that, remember there is an eternal brain drain of top people from academia to industry for the simple reason that industry pays more.) In the case of the developers of Go, we are talking about people who I believe to be smarter than the vast majority of programming language researchers, and who _definitely_ have more experience around large software systems. They have come to different opinions about what makes that kind of development work. People like Ken Thompson and Rob Pike might not be right, but it would be unwise to assume that they are necessarily wrong simply because they disagree with a bunch of programming language researchers.
- Raphael_Amiard 14y ago
  > In the case of the developers of Go, we are talking about people who I believe to be smarter than the vast majority of programming language researchers Why would you have such an opinion ? I can turn the problem in my head a thousand times, i still can't see why. Because it is from the makers of Unix ? The only way i could make sense of your statement is by saying people who makes the most used technology are the most clever, intrinsically. But i think this is an incredibly naive point of view. I can see a bunch of things that make Go susceptible to have success : Traction, from the name of it's inventors and main sponsor (Google). Simple philosophy that makes it easy to learn, and pragmatic orientation. It doesn't mean it's a better language in any way. Just that it's aiming for the path of least resistance. It is a respectable goal. Now i don't see the logic in saying that PL researchers are not as smart because they have more idealistic goals.
  - xyproto 14y ago
    That wasn't what he said, though.
  - gbog 14y ago
brianobush 14y ago
One of the original goals of Go was to be a practical systems PL; that isn't one of Haskell's goals which focus on higher-order programming.
Evbn 14y ago
Haskell's designers believe in the goal of great pegramming, but they refuse to compromise today to help engineers. Haskell Ultimate will be better than Go. But it doesn't exist yet.
Jare 14y ago
The slides (and plenty other Go literature) describe the metrics used to decide Go features in quite a lot of detail. If these metrics are applicable in your context, then Go is more likely to "make your life better" than Haskell. Can you point out to specific PL research results that Go has outright ignored, rather than decided against for X reasons?
- riffraff 14y ago
  this is a very interesting question, but can it be answered? I mean, we can say that design by contract (or linq/multiple dispatch/type state/whatever) offers an interesting solution to common problems and was ignored. But.. just because it's not listed in the FAQs?
- azth 14y ago
  Immutability.
grey-area 14y ago
It is strange the way negative comments float to the top of most HN stories, but I guess it sometimes makes for interesting debates. Do they think the point of Haskell isn't to make programming easier? This comment makes me genuinely curious, why do you feel Haskell has not taken off? Do you feel it is easier than Go to use or to pick up?
- peteretep 14y ago
  Do you spend most of your time "programming" learning how to program? Or using what you've learned? Haskell has a steep learning curve, for sure, and that's one reason it doesn't have widespread use. Once you've learned it, programming in it is arguably a lot more enjoyable (and thus easier) than other languages...
  - grey-area 14y ago
    It seems a lot of people have trouble ever escaping the steep learning curve stage in Haskell, but it does look interesting and your post has inspired me to go take a look at the Haskell intro docs. However I definitely wouldn't group Go with 'worse is better' languages like PHP, so that seems an inaccurate description to me. I suppose what I was interested to know from those advocating Haskell as intrinsically better than Go was whether the learning curve is the only issue with Haskell, or whether there are also times in daily use where it sacrifices ease of use/comprehension for power, as opposed to Go where there is a great emphasis on making the language itself as simple as possible, even at the cost of some convenience.
  - _feda_ 14y ago
    Ultimately it's not practical to use it, so even if it is easier to use after the great hump of the learning curve, it's still not good for real world applications, principally because of libraries, support and ubiquitousness . Certain languages reach terminal velocity, whereupon their real world usefulness goes up exponentially, and whether they are well designed or not the become practically necessary.
emmelaich 14y ago
I think it's about the long game. Go is for now. Haskell is for eventually. Mostly.
dscrd 14y ago
>Do they think the point of Haskell isn't to make programming easier? That's what most of the research into the language is exactly about! After a decade of trying to "get" Haskell, I have to say that they are doing an awful job at it.
fauigerzigerk 14y ago
I don't think making the lives of a maximum number of today's industrial software engineers simpler is the main concern of academic PL researchers, nor should it be. A PL researcher should be able to spend time working on formal aspects of some thought experiment without thinking about interoperability, compile times, social issues in large corporations, etc. And then programming languages are user interfaces. Hence, researching them is a social science and a cognitive science as much as it is a formal science. I don't hear much about that aspect from PL researchers. Arguably, language designers with an industrial background know a lot more about that than academic PL researchers. It may not be very scientific, but they should have pretty good intuitive access to these things.
- Evbn 14y ago
  Why should PL researchers care only about languages and lot about language usage? Only about programs and not how to create them? That seems extremely ivory tower to no good.
  - fauigerzigerk 14y ago
    I believe they do care about that, but it shouldn't limit their thinking too much. For instance, there could be a wonderful model of computing that no current machine can efficiently implement. Kind of like Lisp in the 1950s.
JulianMorrison 14y ago
For what it's worth, Rust includes a lot of pragmatically useful research stuff that was passed over in Go. In particular, I think Rust's emphasis on immutability is a better decision that will result in faster, lock-free code. (Yes, it counts as locking when you have to pass the one-and-only pointer to a thing over a channel just to read it.) But Rust is a big complicated language. Go is syntactically tiny, and that's an advantage in an number of ways, from speed of compilation to ease of use.
- pcwalton 14y ago
  Usually when people say "big and complicated", they mean C++, which Rust is much simpler than. We put a lot of effort into keeping Rust as minimalist as possible without sacrificing the language goals. It's certainly a bigger language than Go, of course.
  - deleted 14y ago
    [deleted]
aufreak3 14y ago
"Research" is about producing new knowledge about something, which in this case is programming computers. The slide on the problems that the Go system solves points out things the solving of which is unlikely to yield significant new knowledge in the domain. Yet solving those problems does improve the lives of programmers and so is a valuable engineering contribution. For some problems, they do reuse techniques that are at least two decades old. Putting import information in compilation units at the head to speed up compilation was already done in Turbo Pascal and is available in Free Pascal today. They also did take up CSP as a concurrency model. "Do they think the point of Haskell isn't to make programming easier?" The point of Haskell was stated by the community much early on -- that they'd try to "avoid success at all costs". "Making programming easier" isn't even a clearly definable research goal I think. Easier for who? .. for which problems? .. on which kinds of machines and environments? Haskell, as I see it, is a platform for experimenting with new techniques and asking "what if?" questions. A sandbox to play in. If it happens to make certain kinds of programming tasks easy and elegant, that's a by product.
- kenko 14y ago
  The focus on Haskell as an alternative is unfortunate. What about, say, Racket? There's a language that emerged out of PL research, by researchers that clearly care about getting programming concepts across to people (The Little Schemer, etc.), that's pragmatically oriented and has a lot of research-derived neat features. Is the problem that there are too few Racket boosters? Racket seems pretty swell to me.
  - krutulis 14y ago
    Good point. The focus on evaluating the success or failure of programming languages as a popularity contest is also unfortunate. There is also the matter of influence. In the mid 80's I took Dan Friedman's (author of The Little Schemer) Programming Languages course and simply had a ton of fun learning all about Scheme & the implementation of languages. I had no idea at the time it would be by far the most important class that I took as either an undergraduate or graduate student. Turns out, one of the most important things programming languages do is influence the way we learn and think about computation. I've learned crucial lessons from Scheme and all the languages I've worked in over the years. To this day, I am perplexed by people so vested in one programming language that they fear instead of savor the chance to work in another. As a math major, a key lesson demonstrated so vividly by Prof Friedman & by the philosophy of Scheme resonated with me personally: the importance of clearly understanding "what depends on what?" and of learning which things can and/or should be made fundamental and which derivative. The Golang Team has looked at their problem domain and, through the creation of Go, has built a striking and innovative statement on what they've judged as fundamental. I welcome their emphasis on selectivity over accumulation and believe there is much to be learned from their choices.

jlgreco 14y ago

As a warning, there seems to be no mouse-navigation of these slides. You have to use a keyboard. (or touch, probably)

cschmidt 14y ago
I was wondering what system created the slides as well. Anyone know?
- codewright 14y ago
  Not to be a smart-ass but: http://talks.golang.org/static/slides.js http://talks.golang.org/static/slides.js From that: // Copyright 2012 The Go Authors. So, I'm going to go with, "we wrote this ourselves and reused some code from other places in a couple spots". Btw, holy-hell 2413 lines, they have to be using a generator for this.
  - krakensden 14y ago
    Most of those lines are just linebreaks, and it's a fairly long slidedeck, so it's not impossible. But you're right, it's generated from a simple, markdown-like format: https://code.google.com/p/go/source/browse/present/parse.go?repo=talks https://code.google.com/p/go/source/browse/present/parse.go?...
- stephen_mcd 14y ago
  It's a tool called Present written by Rob Pike and Andrew Gerrand from the Go team: https://code.google.com/p/go/source/browse/present?repo=talks https://code.google.com/p/go/source/browse/present?repo=talk... They gave a presentation about it a couple of weeks ago at the Sydney golang meetup. It has an interesting feature where it runs a built-in websocket server that can be used to embed code in the presentation, and have it compile and execute output directly back into the presentation itself. I believe it's similar to the tech running behind the play.golang.org site.
  - warmfuzzykitten 14y ago

isbadawi 14y ago

I was a bit confused at slide 35 where he said that Go's declaration syntax is "easier to parse -- no symbol table needed" as I don't typically think of a symbol table being involved in parsing. Here's an interesting comp.compilers thread from 1998 about parsing C++: http://compilers.iecc.com/comparch/article/98-07-199 http://compilers.iecc.com/comparch/article/98-07-199

pcwalton 14y ago
I read that as referring to the lexer hack: http://en.wikipedia.org/wiki/The_lexer_hack http://en.wikipedia.org/wiki/The_lexer_hack
abhayb 14y ago
Couldn't pass this one up seeing as I should actually be dealing with this for a class instead of commenting on Hacker News. What it means is that certain sets of symbols cannot be parsed unambiguously without information generated during the parse itself (the grammar is not context-free). The link in the sibling comment has the canonical example: foo * bar; can either be parsed a multiplication or a declaration depending on whether "foo" has been typedefed previously. So you need to keep track of typedefs in a symbol table to correctly parse things. The biggest problem with this is that many parser generators (including yacc) are much harder (if not impossible) to use with context sensitive grammars.
- sytelus 14y ago
  To me it looks like Go is designed to make compiler writer's life easier rather than programmers. Why is it so important to save on symbol table if it does make language less intuitive (at least for people with C background)? We should be moving towards compilers that are capable of dealing with even more closer to natural semantics, not the other way around. I'm suspecting similar mindset was at work when making decisions on error handling which, IMO, is the most appalling part of Go. If you have coded in C most of your life then it's same ugliness as usual but for others it's a huge move backward. Again the designers of Go could have implemented exceptions and let programmers choose what mechanism they prefer. This would be same as in Java or C# where a programmer can choose to return error values instead of raising exceptions. But I guess that would be more work for compiler writers.

simonsarris 14y ago

Sorry to veer off topic, but why is the golang site so ugly? I clicked on the link in the second slide: http://golang.org http://golang.org compare with: http://www.ruby-lang.org/en http://www.ruby-lang.org/en http://git-scm.com/ http://git-scm.com/ http://www.haskell.org/haskellwiki/Haskell http://www.haskell.org/haskellwiki/Haskell Even Dart looks great: http://dartlang.org/ http://dartlang.org/ I feel a little guilty being negative about this, but presentation does matter, and Google ought to be able to afford it.

geoka9 14y ago
Not to hijack the thread; please see this: http://news.ycombinator.com/item?id=4551907 http://news.ycombinator.com/item?id=4551907
beatgammit 14y ago
I think it's nice. It's super functional and easy to find information. It may not be pretty, but I know exactly where to go to find what I want. I like that the urls are consistent. To find package documentation, I go to golang.org/pkg/<name of import>. For example, for http docs, I go to golang.org/pkg/net/http. For most languages, I resort to a Google search to find package docs. This is true for python, c++, and even Java. I rarely have to google search something in Go. I think the site very much fits in with their goal of simple and orthogonal. I actually wish more language documentation followed suit and made it easier for programmers to search for docs. Sure, everyone wants a pretty site, but it's not like they need to advertise anything. It gets the job done very efficiently.
- dualogy 14y ago
  Regarding docs, what's also extremely neat is, when you're offline, just run "go doc" and it starts an HTTP server on your local machine to serve the exact same fine documentation experience. So thoughtful, one of many small details just part of the overall package, when you need them you find them easily and are delighted.
krelian 14y ago
It's simply and minimalist. Just like the language.

eternalban 14y ago

http://talks.golang.org/2012/splash.slide#48 http://talks.golang.org/2012/splash.slide#48 Time for honesty: What bullshit. - Go codebases by non experts are peppered with magical incantation (sleeps, etc.) to avoid the dreaded "all goroutines are sleep". Of course "they are doing it wrong", but that is the germinal point. - A concurrent Go program will likely behave differently given 2 bits (just 2 lousy bits) of difference in the object binary. (runtime.GOMAXPROCS(1) vs runtime.GOMAXPROCS(2)). Imagine someone touching those 2 bits in a "large codebase". It is practically impossible to do the same thing in a large Java codebase and fundamentally change the programs runtime behavior. (Happens all the time in Go.) - It is very difficult to reason about a Go routine's behavior in a "large codebase" without global view and a mental model of the dynamic system e.g. which go routine is doing what and who is blocking and who is not. Pretty much defeats the entire point of "simple" concurrency, to say nothing of "scaling". Programming in Go's variant of cooperative multithreading is actually more demanding than preemptive multithreading. Cute little concurrency pet tricks aside, Go concurrent programming actually requires expert level experience. "You are doing it wrong". Of course. Point. - There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java. Sure, the cute syntactic go func() needs to be replaced with method calls to the excellent java.util.concurrent constructs, but the benefits -- high performance, explicit-no-magic-code -- outweigh the cute factor in this "programmer's" book. - On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go. - Once we factor in the possibility for bytecode engineering, then Java is simply in another higher league as far as language capabilities are concerned. (Most people who rag on Java are clearly diletantes Java programmers.) If Go actually manages to be as effective as Java for concurrent programming at some point in the future (when they fix the somewhat broken runtime) then the Go authors are permitted to crow about it. Until that day, go fix_the_runtime() and defer bs(). One thing that programming in Go has made me realize is just how awesomely Sun/Gosling, et al. hit that "practical programming" sweet spot. No wonder the modern enterprise runs on Java and JVM. It just works. (But it is "boring" because it's not bling anymore. Oh well, kids will be kids.)

jpeterson 14y ago
What in the world are you talking about?

lukehutch 14y ago

Favorite quote: "While that build runs, we have time to think."

beatgammit 14y ago
Ah, I remember my first job, where I worked on a huge, legacy C++ project. My first day of work was spent building and fixing linker errors. After that, to test it, I rebuilt everything from scratch, and it took about that long, 30-45 minutes. While waiting for it to build, I wrote my own PHP time tracking system (click when I got in, click again when I went home). Ironically, wasting a day on compiling caused me to save hours worth of work keeping track of hours.
btilly 14y ago
That reminds me of a story that I read ages ago. It happened in the 1980s. This group of programmers had taken to exercising while waiting for compiles. They were all buff. Then Turbo Pascal came out and they all turned back into couch potatoes. :-)
- pjmlp 14y ago
  Then C become widespread and they became fit again! :) I really miss Turbo Pascal compile times.
- tommorris 14y ago
  Exercise. That's what I'm supposed to be doing while Maven downloads the Internet.

wnoise 14y ago

One of the few nice things about the C include mechanism is that it's pretty easy (and standard practice) to set up separate implementation and interface files. If the implementation of something changes, but not the interface, I don't want to have to recompile all the clients. This is lost in almost all "modern" languages. (This is, of course, horribly broken in C++ which likes to inline everything.)

Evbn 14y ago
Java has interfaces.
- wnoise 14y ago
  Not the same thing. Think public-vs-private portion of a class.
  - pjmlp 14y ago
    The only advantage Go interfaces have over interfaces in other languages, is that you can make third party code comply to a given interface if you're lucky enough to have the same set of methods available. Even then, you might hit the issue that although the interface matches syntactical, the semantic meaning of the method calls differs. For the CS folks, Go interfaces are nothing more than structural typing, available almost any FP language. The only advantage over Java, C#, D is that you are not required to state explicitly which interfaces a given type implements. However this forces you to use tools to discover which interfaces a given type implements.
agentS 14y ago
As far as I can tell, there are 2 advantages to the separated header file, implementation file pattern in C. First, you get easy documentation of a library's API, and second, the advantage that you mentioned (implementation changes do not necessitiate a full recompile). I would argue that both of these (or atleast the core of these) is addressed by Go. For documentation, there is a simpler way to get at a library's public API; an automated program that extracts that API and presents it in a web page (or in your console). See http://golang.org/pkg/unicode/utf8/ http://golang.org/pkg/unicode/utf8/ for an example (for completeness, here is the file it is generated from http://golang.org/src/pkg/unicode/utf8/utf8.go http://golang.org/src/pkg/unicode/utf8/utf8.go) For avoiding unnecessary recompiles, Go solves this problem by making compiles really fast, rendering this problem moot.

lnanek2 14y ago

I never liked Go, but I admit I like it a lot more if it means I don't have to deal with Maven and other dependency systems as much like the slides say. I've been doing Android since it came out, but before that I was J2EE, and it could be hell if Hibernate needed a different version of a dep than something else in your code stack, for example. Handling JARs by hand stopped working, and the countless XMLs files listing deps for all parts of the system and library started getting full of overrides and the like. Eventually Oracle rewrote all the class loading for their app server which allowed dependencies to have dependencies which were invisible to apps using them. So something as basic as class loaders had to be completely reworked to deal with this, and it was still damn complex and a pain in the ass.

codewright 14y ago
>I never liked Go, but I admit I like it a lot more if it means I don't have to deal with Maven and other dependency systems as much like the slides say. Hrm, yeah, there are alternatives here. (Not in Java-land...other places.) > I've been doing Android since it came out, but before that I was J2EE, and it could be hell if Hibernate needed a different version of a dep than something else in your code stack, for example. You really should look into Clojure.
- geoka9 14y ago
  Wait, isn't easy access to Java libraries one of the premises of Clojure? In that case Java's dependency issues still apply?
  - codewright 14y ago
    Yeah but then you get to use Leiningen, not Maven. Leiningen is manna from heaven.

ddon 14y ago

slide show didn't work for me in FireFox... haven't tried it in Chrome :) Update: was trying to use a mouse to switch between slides, but later tried, and figured out that it only works with keyboard :)

etrain 14y ago

I'm pretty stoked on Go. I freaking love C. Love it. It's like they took C and went to the best disciples of C's creators and said "look - we've got these problems now nobody envisioned 40 years ago. Can you make C for us again, but better?" And they said "yes!" and it was good. We get some nice concurrency primitives, garbage collection, cleaner syntax, something between structs and objects that fits the right feeling, automatic bounds checking, cute array syntax, and a big-ass, well defined standard library. Oh, and this concept of interfaces that is so well executed it's not even funny. Except. I feel like they are forcing the fanboy mindset. At one point in this slide deck, there is the following bullet: "The designs are nothing like hierarchical, subtype-inherited methods. Much looser, organic, decoupled, independent." I didn't see the talk. But that is the most vapid, meaningless description I've ever seen of a feature of a programming language. Rob might as well have said, "it's hipster better," which would have conveyed exactly as much meaning. So here's my question - and I hope there are real answers - can someone point me to >3 real, big systems that are built using Go? I'll accept Google internal systems on faith.

Jare 14y ago
> It's like they took C and went to the best disciples of C's creators I'm confused, didn't they go to the _actual_ C creators? Or am I misunderstanding something?
- icebraining 14y ago
  Except for Ken Thompson, not really. Neither Dennis Ritchie nor Brian Kernighan (K&R) were involved in Go, as far as I know.
  - _ak 14y ago
    Ken Thompson wasn't actually involved in the development of C. He created B, though.
danieldk 14y ago
Oh, and this concept of interfaces that is so well executed it's not even funny. http://golang.org/doc/go_faq.html#nil_error http://golang.org/doc/go_faq.html#nil_error

eta_carinae 14y ago

I was having lunch with a friend of mine who works at Google a few weeks ago and I asked him how popular Go was at Google. He said the only people using it are the Go team. Java and C++ continue to reign supreme at Google.

enneff 14y ago
Your friend is out of the loop. I am one of the Go readability reviewers, and I review thousands of lines of Go code each week. The code is written by Googlers from different teams around the world. It is true that Go is in the minority compared to C++ and Java. Change takes time at a company of this size. But the graphs are all up and to the right, and the rate of Go code being written at Google is accelerating.
- pjmlp 14y ago
  So when do we expected it listed as an official Google language?
  - Symmetry 14y ago
    It already is.
    - pjmlp 14y ago
      I fail to see it like that. It is not listed here: http://google-styleguide.googlecode.com/svn/trunk/ http://google-styleguide.googlecode.com/svn/trunk/ These guides are much more than just what gofmt does. In a Google IO conference talk someone stated that the Google App Engine support was actually made by the Go team. Not all new APIs released by Google tend to offer Go APIs as well from day 1. So I miss the official language support that you say already exists.
      - enneff 14y ago
        Google had four canonical languages: C++, Go, Java, and Python. They are defined internally in an engineering handbook. There is no such similar style guide for Go, as a a lot of what the existing guides say is "don't use x." If that were needed for Go we would have failed.

Evbn 14y ago

I don't get the interface stuff. If you had a method on an interface, you have to add it to all implementors, or clients won't compile. How is that different from Java? Java just adds the implements declaration, so Eclispse can help you find those implementations, instead of making you pore over compiler error listings.

isbadawi 14y ago
In Java, you can run into situations where two classes share a method, but because they don't implement a common interface, for instance because they're part of two different libraries, you can't e.g. write a method that accepts instances of either. You can't straightforwardly take advantage of polymorphism. In Go this is never an issue; you can declare an interface that captures the methods you're interested in, and the existing code automatically implements it. It's kind of like duck typing in python (e.g. this function will work on any object that has a method <x>), except it's statically typed.
- pjmlp 14y ago
  Just because the method complies to the interface does not mean it does what you would expect from it. static fulfilment != semantic fulfilment.
  - msbarnett 14y ago
    You could equally say that just because a class declares that it "implements" an interface, it doesn't mean it does what you would expect from it. In practice, there is no language that can save you from people with malicious intent to confuse you. In practice, this is rarely an issue.
    - pjmlp 14y ago
      There is a big difference. When a developer makes a class implement an interface s/he signing a contract thus validating assumptions. When a type in Go matches an interface, it happens by chance.

ek 14y ago

I think all of the keynotes at OOPSLA this year were surprisingly engaging. I've seen a lot of Go talks from various Googlers, and I have to say that this was the best-motivated, most humble, and most honest of them that I have seen. Rob knew he was speaking to an extremely PL-oriented audience, and structured his talk accordingly, and the result was fantastic. Go comes from a very different standpoint than almost all academic PL work, and in that respect, for those of us in academia, it's an interesting breath of fresh air and a reminder of the uniquely fine line between industry and academia in computer science.

nnq 14y ago

Thinks like this have an unnerving "smell": "Dependency hygiene trumps code reuse. Example: The (low-level) net package has own itoa to avoid dependency on the big formatted I/O package." ...now, if this kind of attitude stays in the core dev land I don't really care about it. But when I'll consider Go as an alternative for a large project, I'll start worrying if people adopt the "it's OK to reinvent some wheels" philosophy when they start building higher level frameworks in Go... I mean, how hard can it be to split the "big formatted I/O package" into a "basic formatted I/O" package and an "advanced formatted I/O package" that requires the first one, and have the "net" package only require "basic formatted I/O" (or maybe even make "basic formatted I/O" something like part of the language "built ins" or smth - I don't know Go so I don't know the Go terms for this)?

agentS 14y ago
> I'll start worrying if people adopt the "it's OK to reinvent some wheels" philosophy when they start building higher level frameworks in Go... I certainly don't have this philosophy, and I don't know thats its a thing amongst Go programmers. I think its just a standard library thing. > I mean, how hard can it be to split the "big formatted I/O package" into a "basic formatted I/O" package and an "advanced formatted I/O package" It would easy, but then you're cluttering your library to make implementing the std lib easier, rather than making the lives of people using the std lib easier. > or maybe even make "basic formatted I/O" something like part of the language "built ins" Things that are in the language built-ins would need to go in the spec, and would need to be implemented by two separate compiler suites. The authors seem to be doing their best to keep the core as small as possible. Having libraries written in Go is cleaner, reusable across compilers, and give newcomers a place to read idiomatic Go.
- nnq 14y ago
  > It would easy, but then you're cluttering your library to make implementing the std lib easier yeah, but the "advanced formatted I/O" package can include all the function from the "basic" one (i.e. act as if it contains all the functions and structs from both of them) and be the only package 90% of regular language users know about, and if happened to need to write some low level code that only needed the "basic/low-level formatted I/O" I would just import that ...it just seems 100x more "sane" to do it this way

smegel 14y ago

> It can be better to copy a little code than to pull in a big library for one function. I just don't get this. If you statically link in small functions from a big library, you only get the little bit you need anyway. Are they saying you avoid compiling the "big library" over and over? But if it is already compiled, that should not be necessary. And the chances are you are going to be importing lots of "little code" from the "big library" anyway. Unless they are saying the implementation of net's itoa is somehow simplified and not a just a straight code copy...otherwise I don't understand this approach.

wsxiaoys 14y ago
It does have simplified the implementation: strconv: http://golang.org/src/pkg/strconv/itoa.go http://golang.org/src/pkg/strconv/itoa.go net: http://code.google.com/searchframe#y_XiVF8bBuQ/src/pkg/net/parse.go&q=itoa%20net%20package:go%5C.googlecode%5C.com&type=cs&l=175 http://code.google.com/searchframe#y_XiVF8bBuQ/src/pkg/net/p...
beagle3 14y ago
> And the chances are you are going to be importing lots of "little code" from the "big library" anyway. That "big library" is often supported by someone else. One day, a year down the line, you realize startup time for you executables went from 0.01s to 2s because Big Library's initialization code now scans all subdirectories for some caching optimization, and stuff like that - stuff that's a win for general users of biglib, but not for you. > I just don't get this This is not about theory, it's about practical experience. You'll notice that successful C/C++ libraries tend to include everything that's small enough and that they need to function - because dependencies byte you later on. e.g. libav/ffmpeg has its own copy of md5, libtcc has its own slab allocator, gsl has its own everything, everything ships with a copy of libz in case the system libz is borked. The Go library just starts applying this principle a little earlier - inside the standard library. I suspect that's because they envision a python-style batteries-included extensive standard library, which has no benevolent dictator to put order in it.

lmirosevic 14y ago

"Go has garbage collection, only. [...] Day 1 design decision." http://talks.golang.org/2012/splash.slide#51 http://talks.golang.org/2012/splash.slide#51 Can someone tell me why GC was the obvious choice as opposed to say automatic reference counting?

ybaumes 14y ago
Maybe because they don't want the production code to deal with reference cycles? I don't know the real reason, better to ask Rob Pike directly ! :)
jlouis 14y ago
If you squint your eyes enough, automatic reference counting is a garbage collection method. But if you are going down that road, there are other garbage collector schemes which often produces way better performance in the common situations, i.e., copying collection or Mark'n'sweep. But it is a trade-off. Refcounting collectors need to address pointer cycles. And they are also quite slow due to all the refcount bookkeeping going on all the time. But they have the nice property that the lifetime of an object won't linger around in a zombie state. And there are no point in time where the system is in a "collecting" state and cannot give service. That said, many modern, multi-core malloc() routines contain a lot of ideas from GCs in them. The gap is closing fast.
dsymonds 14y ago
Because tracking memory allocation and ownership in a concurrent program is very hard. Programmers have to track a lot of that stuff in their heads, and it's easy to make mistakes. If the language is garbage collected, however, the programmer doesn't have to think about that.

ybaumes 14y ago

Does someone knows wath is the reference to Tom Cargill and "PI" in the 16th slides please? I did not find anything on Google.

pswenson 14y ago

Didn't we try error codes back in the day? I think exceptions are brilliant. They let you write your error code in one place (at the top of the stack), instead of planning for every contingency at every level. Once I discovered exceptions back in the 90s, life got a lot easier. Of course Java ruined exceptions with the invention of the CheckedException, maybe this tainted the Go designers' thinking?

ConstantineXVI 14y ago
As someone that grew up with exceptions, I like the idea of errors being recoverable by default. If it's not fatal, your catch block is going to swallow the exception anyway. And if your error is, panic(). (This could be Java experience scarring my then-young mind)
- pswenson 14y ago
  Most exceptions aren't recoverable. They are usually a result of bugs or system problems. This means 1) the bug needs to be fixed. 2) the system needs to be fixed (start up a DB service, clean disk-space, add memory, etc). This is where java went wrong, java checked exceptions treats everything as recoverable when recovery is unlikely. I mean, someone tries to login to a web site and the DB is down. What do you do? Or there is a bug that throws a null pointer exception. How do you recover from that? I think the error code approach has the same effect as CheckedExceptions. People will tend to code to ignore the problems and not report them. Exceptions are great in that they bubble up to the top of the stack, so they are easy to report/alert on.
msbarnett 14y ago
The designers of Go rejected exceptions because, while seemingly simple, they are exceptionally hard to do correctly, and worse, it is extremely hard and subtle to distinguish between code that reasons about them correctly and code that does not. Raymond Chen has a good break-down of the problem here: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

tomdeakin 14y ago

I spent a year working on a project in Go, so got pretty used to the language. One thing I did wonder though was how would it fare on very large systems; how could Go hook up to work like MPI across clusters of computers?

drivebyacct2 14y ago

I miss uriel to respond to some of the really inexplicable posts on this thread. :(

ExpiredLink 14y ago

http://talks.golang.org/2012/splash.slide#11 http://talks.golang.org/2012/splash.slide#11 > Pain > What makes large-scale development hard with C++ or Java (at least): None of the points apply to Java.

pdog 14y ago

I can't be the only one for whom this presentation is completely broken on the iPad (scrolling to fast and skipping multiple slides).