
How Go was Made - beliu
https://sourcegraph.com/blog/live/gophercon2015/123748269730
======
jaytaylor
The article indirectly raised a few questions for me:

Why is there a massive skew favoring Googlers having their proposals
implemented compared to plebes? Did the stats change after rob's talk in 2012?

~~~
droopybuns
The skeptic in me points at android and deduces that the whole focus of Google
open source is skewing ecosystems towards google revenue and or hiring models.

~~~
rsc
The focus of Go's open source project is making a language that works well for
the kind of networked software Google and many other companies write, roughly
"cloud software". I am not sure what ecosystem that would skew toward Google
revenue: maybe cloud providers, but Go works just as well on Amazon and Azure
and Heroku as it does on Google's products. I am not sure what "hiring models"
means, but I've literally never thought about anything related to the hiring
process while working on Go.

For more about Go and open source, see my opening gophercon keynote, at
blog.golang.org/open-source.

~~~
droopybuns
Thanks for taking the time to make a sincere rebuttal.

------
gull
A separate issue - I never know exactly what people mean when they say this:

 _" Diverse teams are more innovative and adaptable than monocultures."_

~~~
seanmcdirmid
Just that groups of different people with different thinking styles are able
to come up with solutions to problems faster than a team of people who think
alike or are beaten into group think by a strong central authority.

It really follows the pattern of biological diversity in ecosystems: a diverse
ecosystem is able to thrive and overcome troubles more than a non-diverse one,
which is actually quite fragile.

~~~
gumpton456
But a 'diverse' team is code for a team with both black and white people, men
and women, straight and gay, etc.

So when you say that 'groups of different people with different thinking
styles' you are implying that, for example, black people think differently
from white people for the sole reason that they are black and other people are
white. Or in other words, that if you get a random black person off the street
you can assume his views will be different from a white person's?

Isn't that kind of grouping and assumption exactly what we don't want to
promote? I can't reconcile this in my mind.

Anonymous because I don't want to be shamed as a racist when I'm not, but a
genuine question.

~~~
ben0x539
The idea isn't that you make a pokemon team of people of all skin colors,
sexualities and genders to have all damage types covered. It's more that
cultural background and experiences made shape thinking, problem-solving
approaches, etc, and if your team is 100% straight white affluent men, chances
are pretty good they will all have roughly overlapping backgrounds and leave
the vast majority of the human experience uncovered.

~~~
gumpton456
I don't get it - either it's right to look at the color of someone's skin and
make an assumption about their background, or it isn't.

You could hire both a rich white guy and a poor black guy, in order to get
diversity, and then find out they both love classical music, basketball,
knitting, went to the same college and vote for the same political party.

If you're telling me you can look at the color of someone's skin and tell me
what their cultural beliefs and background is then you're the crazy racist
judgemental one!

~~~
gluelogic
I am glad to see this kind of doublethink addressed directly.

------
iopq
Go was made in China over 2500 years ago at which point it was called yì (弈).
Then some guy had to name his programming language Go and make "Go
programming" hard to search for.

~~~
aleksi
Search for "golang".

~~~
Artemis2
What if you want to search algorithms related to the game?

~~~
Lrigikithumer
It's also called baduk and weiqi, both should give good results

------
amelius
I have a question about the design of the garbage collector of Go. Does it
also clean up goroutines that are waiting on a "forgotten" channel? And does
this apply for processes waiting for each other in a cycle?

~~~
dsymonds
No, goroutines are never cleaned up until they exit. If they are blocked on a
channel that no-one else references then they'll be blocked forever.

------
nickpsecurity
Start with an existing language (Brand X). Reimplement it almost identically
with modern-looking syntax. Improve and worsen it with some change. Give it a
new name. Apparently a method that works:

[http://cowlark.com/2009-11-15-go/](http://cowlark.com/2009-11-15-go/)

In all seriousness, though, they could've just independently rediscovered a
lot of wise design decisions. Strange if they'd never seen this one studying
programming language history, though. I'm with the author wishing they applied
the innovations that have happened in recent decades or even new ones. Julia
is an example of an imperative one that tries to do that.

~~~
mseepgood
> Strange if they'd never seen this one studying programming language history

Read this summary of Robert Griesemer's talk (The Evolution of Go) then you
don't have to speculate:
[https://sourcegraph.com/blog/live/gophercon2015/123645585015](https://sourcegraph.com/blog/live/gophercon2015/123645585015)

~~~
nickpsecurity
Thanks for the talk as it was interesting! A friend who pushes Go on other
forums talked about how it reminded him of programming in his favorite, Wirth-
style languages. Interesting that re-creating that experience was an explicit
design goal with them drawing on good features of Wirth languages, ALGOL60
(not ALGOL68), and others. The ALGOL60 quote was similarly impressive:

"Hoare said of it, 'Here is a language so far ahead of its time, that it was
not only an improvement on its predecessors, but also _nearly all its
successors_.'"

Quite an achievement. It was had by using only experienced language designers
on the committee. Modern committee-driven actions could learn from this
technique of using people with brains and experience.

One of their smartest moves was how they marketed it. Many nice language
designs happen but don't get any traction. Their design choices, tooling
efforts, and big company support have been _much_ better than the Java rollout
and many minor attempts. My hope for the language is that it replaces the use
of C# and Java in as many places as possible so people don't have to learn all
that mess in maintenance phase. The simpler language should make for nice
legacy code work, I think.

Bookmarking the article.

------
gull
Although Go is more popular than ever, I'm not sure the following observations
are good signs. Something about them makes me uncomfortable.

 _" The decision process was consensus driven."_

 _" The first Go program was the prime sieve."_

 _" In July 2008, the project became more serious."_

~~~
rsc
Can I ask why those make you uncomfortable?

~~~
gull
Good question.

Design by consensus generally produces inferior results. The first version of
the most noteworthy innovations are often the result of a single person's
effort. But it's also evident big projects are the results of teams. You can't
produce something big without a team.

So what makes me uncomfortable is that I don't see one of the inventors of Go
having produced a rough version one before pulling other people in (but to be
fair, I simply don't know).

I'm more suspicious about the first Go program. Was computing a prime sieve
the number one problem the Go creators had? Doubtful. When C was being
written, the authors were also writing an application they deeply needed:
UNIX.

Finally, the thought of making something "serious" spoils the general hack
flavor of innovative solutions. It's like a beacon that ideas are about to
start being policed, which sounds like the opposite effect consensus intends
to produce. It may be a good idea to keep a project non-serious as long as
possible instead of optimizing it prematurely.

~~~
Artemis2
> I don't see one of the inventors of Go having produced a rough version one
> before pulling other people in

Well, Ken Thompson _did_ create B...

~~~
pjmlp
Actually, he adapted BCPL by changing a bit the syntax and taking a few things
out to fit into the PDP, but even the manuals were almost a copy from the BCPL
ones.

[https://vimeo.com/132192250](https://vimeo.com/132192250)

------
AdieuToLogic
> Go began with Robert Griesemer, Rob Pike, and Ken Thompson. “What should a
> modern programming language look like” (the story goes as they were waiting
> for some C++ to compile).

Cute. Nice to keep a dig[1] going. Since that horse has been kicked quite a
few times over the years, how about those in the Go community address these
language criticisms:

[http://yager.io/programming/go.html](http://yager.io/programming/go.html)

For specific examples from the aforementioned link:

    
    
      The "correct" way to build generic data structures
      in Go is to cast things to the top type and then
      put them in the data structure. This is how Java
      used to work, circa 2004. 
    

And:

    
    
      Go has the null pointer (nil). I consider it a
      shame whenever a new language, tabula rasa,
      chooses to re-implement this unnecessary
      bug-inducing feature.
    

Of which the latter has been regretted by its inventor[2] for years.

1 - "[C++] certainly has its good points. But by and large I think it's a bad
language." (source:
[https://en.wikiquote.org/wiki/Ken_Thompson](https://en.wikiquote.org/wiki/Ken_Thompson))

2 - [http://www.wisdomandwonder.com/link/2015/tony-hoare-sorry-
fo...](http://www.wisdomandwonder.com/link/2015/tony-hoare-sorry-for-
inventing-the-null-pointer)

~~~
pcwalton
Here, I'll address one of them:

"It is an extremely common occurrence for a programmer to accidentally forget
to account for the possibility that a pointer may be null, potentially leading
to (at best) crashes and (at worst) exploitable vulnerabilities."

Null pointers won't result in exploitable vulnerabilities in Go (not counting
straightforward DoS-by-causing-the-program-to-panic). They might, in very rare
cases, result in something exploitable in C or C++, because dereference of
null is undefined behavior and the compiler is free to optimize accordingly.
But in Golang the language semantics require the runtime to panic on nil
dereference, so that won't result in something like RCE as it technically
could in C or C++ (but isn't likely to).

~~~
AdieuToLogic
> But in Golang the language semantics require the runtime to panic on nil
> dereference, so that won't result in something like RCE as it technically
> could in C or C++ (but isn't likely to).

While you thoughtfully address the concerns Mr. Yager presents regarding the
potential result of using a null pointer in Go, IMHO the more relevant fact is
that Mr. Hoare identified in his own words a mistake he made _fifty years ago_
(1965) by introducing "null."

The fact that Mr. Gerrand stated in the submitted article:

“What should a modern programming language look like”

Begs the questions:

Why is this mistake oft addressed in _other_ languages repeated in Go?

What are the benefits of _intentionally_ introducing this boundary condition
into the language?

Put bluntly, there is no benefit to dragging 0x0 forward in "a modern
programming language." The lack of an answer to a function/method call is
trivially encoded with some form of an option[1] type.

1 -
[https://en.wikipedia.org/wiki/Option_type](https://en.wikipedia.org/wiki/Option_type)

~~~
zimbatm
nil dereference is only really critical if it can result in security issues
like in C and C++. After that there are a lot of class of errors that are
possible even in stronger types systems like in Haskell, nil dereference is
only one of them.

The question ultimately is what is the shortest path to developing a
functioning and correct program ? Compilers can be very smart and help you
catch a lot of errors but they can also introduce friction if they become too
slow. Everyone has different opinions about the "best" because we have
different ways of getting to the end-result. Programming is a discovery
process and some people prefer to think a lot upfront, some like to experiment
and probably a different mix of both for every one of us.

All this to say that nil in Go is not an absolute mistake. It's just a trade-
off like everything else. Since I took Haskell as an example, it's also much
much slower to compile.

~~~
catnaroek
In my experience, unless you enable all the crazy type system extensions
(which isn't a terribly good idea IMO), GHC doesn't really spend that much
time typechecking programs. Most of the time is spent on optimizations, which
are (0) possible thanks to purity [hooray!], (1) necessary to overcome the
limitations of laziness [dangit!].

In any case, Haskell supports exploratory programming just fine. It's true
that Haskell's definition of "exploring" (refine your design until you can
convice GHCi and QuickCheck that it makes sense) is somewhat idiosyncratic
from a Lisper or Smalltalker's point of view (refine your design until you can
convince _yourself_ that it makes sense), but that doesn't make it any less
legitimate. It's still experimenting, except now you have a tool to validate
the degree to which the experiment has been a success. It's experimental
_science_ , not experimental art.

\---

On the specific topic of nils, I think it's fair to say they're an absolute
mistake in a statically typed language first released as late as in 2007.
Standard ML and OCaml, both much older languages, have parametric
polymorphism, algebraic data types, freedom from nils, and fast compilers:
Poly/ML and OCaml's bytecode compiler, respectively. In addition, both Standad
ML and OCaml have unrestricted imperative facilities, so freedom from nils is
perfectly possible in an imperative language.

\---

Regarding the classes of errors that are still possible in type systems like
Haskell's, I have found only one that really matters, and where the usual
workarounds (e.g., phantom types) don't help. Haskell, being a mathematically-
inspired language, favors programming in terms of "timeless" entities whose
existence is unaffected by the number of times you use them. While appropriate
for manipulating pure data (numbers, strings, lists, trees, etc.), it's
awkward for manipulating ephemeral computational _resources_ , such as file
descriptors or open sessions.

A language that fares better in this regard is Rust. Rust has parametric
polymorphism, algebraic data types, freedom from nils (are we seeing a common
theme?) and type classes, but gives up on interactive programming in exchange
for precise control over data structure representation and resource
management. Rust's type system design understands very well the ephemeral
nature of objects: When a non-`Copy` object is passed around elsewhere, it's
truly gone from the current lexical context.

\---

Now, I don't want to give the impression that I think verification is the be
all and end all of computer programming. There's plenty of room for languages
that let you develop "fast and loose" solutions, as opposed to follow some
principled philosophy. (Ruby comes to mind.) However, Go's very own marketing
suggests that this isn't what they're trying to achieve. They _do_ want a
language that enforces a programming discipline. They just happen to have
designed a language whose discipline doesn't provide enough benefits to
justify the freedom restriction.

~~~
zimbatm
You are making some really good points.

One thing I would like to observe is that all the languages that you are
citing that don't implement nil also implement patter-matching. All have
something equivalent to the Haskell Maybe type which needs to unwrap the value
upon utilization.

I would be open to admit that nil is an absolute mistake if you can
demonstrate that unwrapping is as convenient as just checking for nil and then
using the value (or present another mechanism that is as convenient).

In regards to possible class of errors in Haskell I can think of a few: any
non-terminating program, any program that blows up the memory. It's possible
to implement a Monad that doesn't obey the monadic laws. It's possible to
inverse the order of arguments inadvertently if they have the same type. Any
insufficiently specified type, like using Int when only a range of Int is
acceptable or any String when only a URL is acceptable. I'm sure there are
more ;)

~~~
catnaroek
> if you can demonstrate that unwrapping is as convenient as just checking for
> nil and then using the value.

If you want to build a largefail at any point computation that may abort at
any point in the middle, you can use the MaybeT monad transformer. Or EitherT,
if you want to supply an error message when you fail. Inside a `do` block, it
looks just the same as imperative code. So no syntactic convenience is lost.

But the real benefit, at least in my opinion, is the ability to design APIs
that allow less room for error. In the vast majority of cases, pointers and
references simply aren't intended to be nullable in the first place.

> It's possible to implement a Monad that doesn't obey the monadic laws.

And it's possible to overload operators in C++ in ways that make no sense
whatsoever as well. (Using the same operator for bit shifting and stream I/O,
seriously?) At least Haskell has a culture of associating laws to type
classes.

> It's possible to inverse[sic] the order of arguments inadvertently if they
> have the same type.

No worse than any other language. If anything, Haskell's type system makes
_more_ distinctions, so this specific error is less likely.

> Any insufficiently specified type, like using Int when only a range of Int
> is acceptable or any String when only a URL is acceptable.

Idiomatic Haskell would make custom types, with smart constructors if
necessary. Using String when a URL is expected is simply bad API design in
Haskell.

\---

But, anyway, I'd rather not continue this subthread, since the topic is Go.

