HN Theater @HNTheaterMonth

There may be other languages that have taken a similar approach—I’m not up to speed on that—but simplifying elements of the language design to enable fast compilation was definitely a conscious design choice for Go.

See Rob Pike’s 2012 talk “Go at Google: Language Design in the Service of Software Engineering”

video + slides: https://www.infoq.com/presentations/Go-Google/

transcript: https://talks.golang.org/2012/splash.article#TOC_5.

Some of the things it calls out:

  - unused dependencies are a compile-time error

  - dependency graph has no cycles

  - importing a package only looks at object files, not source files, so template/macro stuff is generally out

  - declaration order is reverse from that of C so that parsing code is faster and easier

The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language.

[*] https://www.infoq.com/presentations/Go-Google

⬐ SZJX

tbh I don't think workers even inside of that environment will be much pleased either. The managers are likely pleased because it speeds up the organizational efficiency, but that doesn't necessarily have anything to do with the happiness of the developers who actually write code and have to bear its many unpleasantness. That's just two separate things.

⬐ 20yrs_no_equity

Google is not the only entity that operates at scale, and simply because google does it does not mean it is the correct choice. That's kinda cargo cultish.

In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill your program. When that happens you have no idea why things are broken-- nothings happening.

And this is a language without a decent debugger!

⬐ lossolo

> In distributed systems, go is fragile and dangerous -- because it will panic.

Do you know when it will panic? Do you know you can recover from panic if you for example want to communicate with other systems that this node is going offline?

> it has the potential for deadlocks

I could write that for most of languages that have mutexes. This is design problem, not language problem.

> When that happens you have no idea why things are broken-- nothings happening.

It's only true if you do not know how to use debugger and don't know how language features you use works.

⬐ None

None

> I wonder what rob pike has to say about OOP

https://talks.golang.org/2012/splash.slide#55

https://talks.golang.org/2012/splash.slide#56

https://talks.golang.org/2012/splash.slide#57

From this talk: http://www.infoq.com/presentations/Go-Google

"O-O is important because it provides uniformity of interface. Subtype inheritance encourages non-uniform interfaces." - Rob Pike http://www.infoq.com/presentations/Go-Google 43:00

It's interesting to see how some of these opinions are reflected in Go, because Rob Pike helped design Go about 20 years after writing this essay:

Typography: Automatic formatting is part of the standard Go tooling and culture.

Function pointers / Protocols: This section seems to be decsribing a technique similar to Go's interfaces.

Include Files: Rob Pike talked about this in his presentation at SPLASH [1,8:00-12:30]. He mentioned that Plan 9 had fast compile times in part due to following this discipline. He contrasted that with one of Google's C++ code bases in which the compiler had to read 2000 bytes for every byte of source. That was largely because of includes, and was a problem for compile times. A little later he talks about Go's method of importing dependencies, and presents them as a big improvement to the situation.

[1]http://www.infoq.com/presentations/Go-Google

> Being regular would mean that you could decide it with regular expressions.

Hence almost regular. Of course, there is no concrete definition for "almost regular", but what I mean by it (Rob Pike himself also characterizes it as such too[1]), is that you get to decide which way to parse a construct quite definitely early in the token stream and you don't have to read arbitrary following tokens to figure out how to construct a parse tree branch.

C++ is the exception here. Most other block oriented high level programming language (at the syntax level) are indeed fully context-free, so just being context-free does not deserve a high prize.

[1]: http://www.infoq.com/presentations/Go-Google

⬐ chrismorgan

You are meaning that it is an LL(k) parser. Rust is an example of an LL(1) parser. Various things that might be convenient to have in the language in certain circumstances have been rejected because they would cause ambiguity in the parser which would require arbitrary lookahead.

https://en.wikipedia.org/wiki/LL_parser

⬐ mehrdada

What I have in mind is more loosely defined than LL(k) and in a way more restrictive than a general LL(k) grammar, but LL(k) is probably a good way to formally capture something close to what I had in mind. I try to avoid using the term "almost regular" as it is imprecise. I only used it since it was relevant to the context and I'd heard Rob Pike describe Go as having almost regular syntax several times.

⬐ Crito

Do you have the timestamp of when in this talk Rob Pike mentions this? If he says that it is "almost regular", then that settles it in my book, but I am pretty certain that you are wrong about most block oriented high level languages being context free.

C++ is an extreme case, as it's Turing complete, but C is definitely context sensitive (http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv...), Perl is just as bad as C++ (http://www.perlmonks.org/?node_id=663393), and I can't find a link for it right now but IIRC the Java is context sensitive for some reason too.

⬐ mehrdada

In that video mentions regularity around minute 51. I have seen him using that term in person too.

The blog post you mentioned is misinformed. YACC does not parse all context-free grammars. It generates LALR parsers, that parse a strict subset of context-free languages (called deterministic context free languages). Not parseable with YACC does not imply not context free.

It is important to distinguish the programming language and its syntax. In most real compilers, the parser accepts a superset of the programming language and then other components of the compiler restrict it with semantic rules like type checking. What I am talking about here is the syntax only. In that sense, things like C, Java, and C# are most definitely context-free. The language specification usually comes with a context-free grammar describing the syntax. Whether you can use it to parse programs efficiently (in O(n)) and meaningfully is another matter.

⬐ Crito

If a piece of C code that parses in two different ways, depending on what other code may have also been parsed, isn't context sensitive, then what is?

⬐ mehrdada

http://en.wikipedia.org/wiki/Context-sensitive_language#Exam...

My understanding is that that is, in a single sentence, exactly why the project initially got started at Google.

http://www.infoq.com/presentations/Go-Google

I think that's simply a misunderstanding of what "systems language" means. It does not mean "go write an operating system", even though that's an application that comes to mind because of C.

From the top of golang.org: "Go is an open source programming environment that makes it easy to build simple, reliable, and efficient software." That's a pretty general statement. Follow on with this one from [1]: "Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language." They're pretty clear that they want to have their cake and eat it too, regarding the benefits of these language classes.

For more color on Go's origins, focus, and design, I highly recommend the "Go at Google" talk by Rob Pike, available as video [2] or an edited article version [3].

[1] http://golang.org/doc/faq#creating_a_new_language

[2] http://www.infoq.com/presentations/Go-Google

[3] http://talks.golang.org/2012/splash.article

⬐ MatthewPhillips

It's not a misunderstanding at all. From day one the target was C/C++. The initial demos were all about how fast Go compiles compared to C++.

Hell, that FAQ makes it pretty clear what the target is. Please read "What is the purpose of the project?" and tell me how the target is anything but C/C++...

⬐ shurcooL

Going through this, I now realize one of the significant reasons I took such a big liking to Go. They realize [1] how important it is to make it easy not just for a programmer to work with the language, but also for writing tools that work with the language. And this happens to be very important for what I do. [2]

[1] http://talks.golang.org/2012/splash.slide#34

[2] https://github.com/shurcooL/Conception#conception

⬐ laureny

> but also for writing tools that work with the language.

What I've seen from go's tooling today: a very crude debugger and zero IDE support.

The bar for "good tooling" in 2013 is quite a bit higher than it was in 1999.

⬐ coolsunglasses

IDE support comes in the form of the gocode daemon. Works fine with Emacs, Vim, Eclipse, etc.

There's a Golang-specific IDE but it isn't very fancy. Most people just use the Gocode daemon with their editor of choice.

⬐ coldtea

>Rob Pike explains how Google designed Go to address major development issues they encounter while using other languages: long build times, poor dependency management, lack of robustness, etc.

So not exactly "Go at Google" (which is meant to give the impression this is all about how Google uses Go), but more like "How Go was initially thought out and built by a team at Google as a side project" or "How the team that built Go hopes to 'sell it' to Google".

⬐ oinksoft

This is the summary at the top of the page:

  Rob Pike explains how Google designed Go to address major
  development issues they encounter while using other
  languages: long build times, poor dependency management,
  lack of robustness, etc.

In any case, Google is heavily invested in Go. There's no need to "sell it."

⬐ coldtea

>Rob Pike explains how Google designed Go to address major development issues they encounter

Only Google never "designed Go" -- in the way it designed the V8 or Dart, SUN designed Java or MS designed C#, ie. assembled a team, funded them, and told them to specifically build a language as a project to fix some specific issues.

A team at Google designed Go on their own, as a side project, to scratch their own itches/pain-points.

For me at least, those are two clearly distinct cases.

Now, you can argue that the second, being grassroots and all, is better, or whatever, but I would not use the words "Google designed Go to address major development issues they encounter" for the second case.

Now, afterwards, the team got some funding from Google to work on it now, and Google even has added other people to work on it, but it was never "designed" by Google (ie as a company decision at large) to solve their pain points, and the language was never officially adopted by Google by some decree in the "teams, use that, it solves our pain points" sense.

As for heavily invested, I don't know. A few projects seem to use it, but mainly minor ones. A db balancer for YouTube, Google Downloads (which was "no longer actively maintained" before switching to Go, etc). Of course they could adopt the language more in the future, but as of yet I haven't heard of any heavy rewrites and main components done in it.

Not to mention that at some point Google was "heavily invested" in Wave too, and that didn't come out that good. Who's to say at some point during the regular spring cleaning they wont kill the funding for the Go work, to streamline their development story? I can even see them killing Dart at some point, if it fails to get any adoption in 3-4 years.

⬐ pjmlp

> In any case, Google is heavily invested in Go. There's no need to "sell it."

Really?

That is why Go is part of the standard Android SDK/NDK. Oh wait!

That is why Go is part of the NaCL SDK. Oh wait!

That is why I can have first class treatment for all Google APIs with Go. Oh wait!

⬐ drivebyacct2

Is the last one less than at least 90% the case?

⬐ None

None

⬐ None

None

⬐ laureny

> In any case, Google is heavily invested in Go.

There is very little evidence of that. The language is a few years old now and the only presentations are coming not even from random Google employees but exclusively Go team members. If Rob Pike wasn't involved in this language, it would be completely invisible.

So, there's not a lot of concrete evidence that Go has made any inroads inside Google against Java and C++ and from what I can see, the language is hardly every used outside Google as well.

⬐ justin66

> If Rob Pike wasn't involved in this language, it would be completely invisible.

Being the last item on Ken Thompson's resume prior to his retirement makes it kind of visible, too.

> So, there's not a lot of concrete evidence that Go has made any inroads inside Google against Java and C++ and from what I can see, the language is hardly every used outside Google as well.

Do you work at Google?

⬐ coldtea

>Being the last item on Ken Thompson's resume prior to his retirement makes it kind of visible, too

In the way Plan 9 got mass adopted?

Do lots of people know what Alan Kay does now? Or what was McCarthy's last project?

⬐ weareconvo

> Do you work at Google?

I did for over 5 years. While I left before the Go programming language was released, I seriously doubt they've transitioned much of the codebase to it, for one simple reason:

The Google codebase is fucking massive. I simply cannot describe how unbelievably huge it is, and while I don't doubt for a second that Go will be used for some of the systems-level projects (some of which Rob Pike is directly involved with - how's that for vague), you simply don't transition that big of a codebase to a new language.

It would basically be impossible... unless you're Jeff Dean.

⬐ justin66

Thank you. That's fair, but I think a better metric of the success of Go - which is how this train of thought started - would be how much new stuff is being started with it, for just the reason you stated. It'd be nutty to rewrite a bunch of working code.

⬐ weareconvo

In addition to the difficulty of rewriting existing code, even when you program something new at Google, you'd be a fool not to leverage what infrastructure already exists. If you try to do that while at the same time writing the new project in Go, you run into weird interoperability issues.

⬐ Evbn

Do you know whether Go is compatible with Google infrastructure? With protobufs and stuff like SwIG/JNI, why would it not be?

⬐ weareconvo

That's a good point, though protocol buffers aren't used for everything. There's more tightly-bound systems stuff going on, plus libraries and so forth. Which is to say, I have no idea.

⬐ Lewisham

a) It doesn't make a lot of sense for Random Google Engineer #62 to give a presentation about a small project.

b) Go, like every other programming language, will take time to get up to speed. Programmers need to be familiar with it. Managers need to be OK approving new projects to use it. Old projects will need a really good reason to get a rewrite in it. There is no edict at Google to use any given language, it just has to be one of the four blessed languages: Java, C++, Python or Go. Go has to prove its value against languages that are decades old with full library support.

So no, I wouldn't say that it is clear Go has made inroads at El Goog, because I don't think anyone reasonable would expect it to. Is it fair to say "Google is heavily invested in Go"? I don't know. I think it's fair to say Rob Pike and his team are very clever, and they're spending their time on Go, so that bodes well.

⬐ laureny

> I think it's fair to say Rob Pike and his team are very clever

Rob's cleverness and contributions to computer science are indisputable, but that doesn't make him a good language designer.

From what I've seen of Go, it seems like it was designed by a team that stopped looking at other programming languages in the late 90's.

⬐ coolsunglasses

Late 90's is being gracious to a language that smells like an ALGOL and Pascal cross-over.

Leaves me to wonder why some of these people bothered with C to begin with and didn't just use Pascal. Momentum in the Unix world maybe?

⬐ Evbn

Accidental NoTrueScotsman alert.

If a Googler thinks Go is awesome and builds a bunch of stuff in Go, what happens to that Googler? They become member of the core Go team!

⬐ coldtea

If I understand correctly, your argument is:

"Parent says only members of the core Go team are known to be doing stuff with Go in Google. But that is circular reasoning on his part, because anybody who makes something in Go also becomes a member of the core Go team (or he considers him one, anyway).

I don't think it holds.

The core Go team is more or less specific and stable over the years, and the news about projects and stuff usually come from certain core members (Rob, Brad, and 1-2 more).

Very rarely do they come from other, random guys at Google (the YouTube thing being the exception IIRC).

So it's not like Google has mass adoption from tons of Google developers but he dismisses it because they all are "just from members of the Go team" in his eyes.

And, of course, thinking a language is excellent and using it in your project, by no means necessitates you becoming a member of said language's core team. We don't see much rise in the Go core team members anyway (if any).

⬐ voidlogic

I would like to see more internal Google stats as well but-

"and from what I can see, the language is hardly every used outside Google as well."

3 Months ago Go was more popular on github by number of unique committers than Lua, Clojure, Haskell, Erlang, D, OCaml, Lisp/Scheme, Rust, Delphi, Prolog, F#, Ada etc [1]. Surely you consider some of those languages as being relevant? That is not a perfect metric, but those stats don't fit your narrative of Go being unused very well.

1: https://gist.github.com/igrigorik/4440674

⬐ pjmlp

I doubt GitHub reaches at all 1% of the code developed in all companies in the world.

⬐ chmike

Today or in 10 years ?

⬐ pjmlp

1 - Except for open source startups, companies only use internal repositories;

2 - Many are still using centralized repositories like cvs, svn, clearcase and TFS

⬐ coldtea

>3 Months ago Go was more popular on github by number of unique committers than Lua, Clojure, Haskell, Erlang, D, OCaml, Lisp/Scheme, Rust, Delphi, Prolog, F#, Ada etc [1]. Surely you consider some of those languages as being relevant?

No, none of them is really relevant industry-wise at this point. That doesn't preclude them being excellent languages, used in a lot of projects, but the "a lot" for Haskell and even Clojure is some orders of magnitude less than the "a lot" for Java, C, VB, etc.

The listing has Java and Ruby head-to-head which is not at all the case, not even close, in programming at large. It's just that Ruby is more popular with the GitHub using type of people, whereas tons of enterprise programmers using Java can never put their source up there for all.

(The same listing has VimL and Emacs Lisp above of Go -- I guess people merely storing their Emacs configuration on GitHub are probably counted as programmers doing actual development work).

⬐ DanielRibeiro

About 30 mins into the presentation, Rob Pike does give a few examples of real Go usage inside Google. In the end he even mentions a few products that use it, like Youtube and dl.google.com

⬐ coldtea

Those have been the 2 major products that use it for like 2 years.

One is a database load balancer (in YT), not the most essential or irreplaceable piece of infrastructure (ie. they can write it in another language whenever they want if the need arises without messing other stuff)

and the other is a services that was not updated anymore, and was left to die, before someone from the Go team asked and re-wrote it in Go. It's not even the full download service, just a part of it IIRC.

⬐ Evbn

To be clear: a broken product that was actively annoying users and that no one knew how or had energy to fix, got fixed by a Go dev, and you are saying that is NOT a point in Go's favor?

Maybe if Reader were written in Go, it wouldn't have been killed.

⬐ coldtea

>To be clear: a broken product that was actively annoying users and that no one knew how or had energy to fix, got fixed by a Go dev, and you are saying that is NOT a point in Go's favor?

Sure is a point in Go's favor. It means it can be used to solve an actual problem in a large company.

But what I'm saying is it's not that big of a deal as it may seem to some: it's not like they used Go in some highly critical for them infrastructure or important new project.

On the contrary: they used it at so low a priority project, that it was abandoned and left to rot before somebody volunteered (was not even asked!) to do the rewrite.

(And, no, it was not abandoned because it's C++ codebase meant it could not be fixed -- after all it could be redone from scratch in C++ or Java, as it was redone from scratch in Go. It was merely due to neglect).

So, my point it, this story is not a "investing internally in the language big time" thing, but rather baby steps.

⬐ Evbn

You say the big company is not investing in a big way, I see a small team of revolutionaries rescuing a behemoth from crushing itself under its own weight. :-)

⬐ Maxious

Not to mention Google Public DNS http://wilmer.gaa.st/blog/archives/58-Google-Public-DNS.html...

⬐ rossj

"While BIND (written in C) can only serve 1000 queries per second on an old 486, the Go rewrite can serve all DNS queries in the world"

Maybe I mis-read it, but that comment comes across as a little sarcastic. Hope I'm wrong.

⬐ Evbn

If I were charitable, I would say that the Go version supports horozontal scaling and external caching and queue buffers in a way that the BIND does not.

⬐ cgcardona

The most suprising part to me is that it doesn't support inheritance. I'm currently reading 'Object Oriented Design with Applications' by Grady Booch [1] and I noticed the following in the section 'Object Oriented Programming'

> …object-oriented programming (1) uses objects, not algorithms, as its fundamental logical building blocks; (2) each object is an instance of some class; and (3) classes are related to one another via inheritance relationships.

> …By this definition, some languages are object-oriented, and some are not. Stroustrup suggests that "if the term 'object-oriented language' means anything, it must mean a language that has mechanisms that support the object-oriented style of programming well. A language supports a programming style well if it provides facilities that make it convenient to use that style. A language does not support a technique if it takes exceptional effort or skill to write such programs; in that case, the language merely enables programmers to use the techniques"

>…if a language does not provide direct support for inheritance, then it is not object-oriented. Cardelli and Wegner distinguish such languages by calling them object-based rather than object-oriented.

Per this definition I wonder if Go might not be better labeled 'object-based.'

[1] http://www.amazon.com/gp/search?index=books&linkCode=qs&...

⬐ koalaman

FWIW, I think that removing inheritance is a major strength of Go. Interfaces and composition give you most or all of what you want and get you in a lot less trouble.

⬐ zik

It does have inheritance although the syntax is different:

  type SubClass struct {
    SuperClass
    other fields...
  }

⬐ shared4you

So, according to this logic, even C is Object-oriented with support for inheritance, because:

     struct SubClass {
        struct SuperClass super;
        // .. other fields ...
     }

is valid.

⬐ mdwrigh2

I don't think you really understood the Go example. In C if I have:

    struct SuperClass {
        int foo;
    };
    struct SubClass {
        struct SuperClass super;
    };

Then to set the foo item I'd have to do: struct SubClass bar; bar.super.foo = 5;

Whereas in Go I could say: type SuperClass struct { foo int } type SubClass struct { SuperClass } bar := SubClass{} bar.foo = 5

So, small difference, but I think valid.

⬐ Evbn

Go try calling SuperClass's method on Subclass, and tell us the two problems you face.

⬐ voidlogic

So Go has embedding not inheritance because SubClass is not an instance of SuperClass, there is no hierarchy, only composition.

BUT what you might not realize is that any method defined on SuperClass (and only defined on SuperClass) can be called on SubClass, but it operates on SuperClass data. This allows SubClass to use SuperClass to help it fulfil an interface for example.

See it in action: http://play.golang.org/p/8kiwu1PlW_

⬐ shared4you

This is similar to C++ in which base class methods are 'virtual'. Is there a way to stop this behaviour? Just thinking how non-virtual methods can be implemented then. C++ has a keyword, 'virtual', for switching this behaviour, but any analogue in Go?

⬐ voidlogic

You mean like final in Java? I don't believe there is. Go has a different way of handling OO and so far I have never needed "final". In Go embedding is not common and interfaces are used much more.

In Go, having final in an embedded struct affect the containing struct seems wrong IMHO- this would allow embeded fields to dictate the behaviour of things that embed them. I don't think most programmers would be happy with adding a field to a struct and as a consequence be prevented from implementing a given method signature.

⬐ shared4you

Ah sorry, I have no idea about Java or final, so ... can't comment.

⬐ voidlogic

http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods

⬐ redbad

Embedding is not strictly the same thing as inheritance.

⬐ voidlogic

That is not inheritance, it is embedding: http://golang.org/doc/effective_go.html#embedding

⬐ codygman

Define "direct support" for inheritance. IMO, a symbol named inherit doesn't have to exist for there to be inheritance.

Here is a blog post answering your exact questions: http://areyoufuckingcoding.me/2012/07/25/object-desoriented-...

Here are examples of inheritance in Go: http://golangtutorials.blogspot.com/2011/06/inheritance-and-... http://diveintogo.blogspot.com/2010/03/classic-inheritance-i...

⬐ shared4you

I come from C++ background, so by "direct support", I think he means a language construct that clearly shows the inheritance relationship, as in

Java:

       public class MountainBike extends Bicycle

or C++:

      class MountainBike: public Bicycle

From those links, it looks like in Go, you use an anonymous struct inside a normal class. I would call it "aggregation" or "containment" (or implicit delegation), not inheritance. It suggests "has-a" relationship rather than an "is-a" relationship. The Go's "syntax" for inheritance (if you can call that) is ambiguous, unlike C++ or Java.

⬐ Evbn

Inheritance is implicit delegation, in any language. The "implicit" is what makes it inheritance.

⬐ codygman

I don't see any downsides to this though, could you enumerate any you can think of? For instance, I believe I an model relationships either way and accomplish the same thing with little to no difference.

⬐ brianpgordon

> The dependencies have to be a true tree.

Surely he means DAG?

⬐ jknightco

I believe you are correct. Otherwise you could only import each package once during the whole project, right?

The masochistic side of me is now interested in trying to build a project like this...

⬐ Maxious

Have you tried java? Let me show you my TimeDateAccessObjectFactory.

⬐ drzommer

Daily post on go.

Go and its advertisement campaign have something in common: lack of subtlety.

I will eat my hat if tomorrow I don't see another go post.

⬐ waterlesscloud

Weird isn't it? Posts on a new-ish, interesting programming language on a site frequented by a large number of programmers with a penchant for new, interesting languages.

⬐ hugopeixoto

You can just check the slides here: http://talks.golang.org/2012/splash.slide

I read them a couple of weeks ago when I decided to take a look at Go,

and they were really helpful and eye opening to the problems it is trying to solve.

⬐ mseepgood

Or the article: http://talks.golang.org/2012/splash.article