
Alan Donovan and Brian Kernighan Answer Questions on Go - signa11
http://features.slashdot.org/story/15/11/18/1748247/interviews-alan-donovan-and-brian-kernighan-answer-your-questions
======
atilaneves
Go is as far removed from "extreme abstraction" as any other language I know.
I don't know how it can even for a second be considered to have that
desireable attribute.

I, for one, don't like abstraction and power just because I'm a PL geek. I
admit those are also reasons, but the truth is I use them to make my codebase
smaller, simpler, and easier to reason about.

For some, achieving that goal means writing for loops. For me, it's never
having to write explicit loops.

~~~
rubiquity
Agreed. There's abstraction and then there's abstraction. I might have been in
the camp of Go enthusiasts if my experience with abstraction only included C++
or Java. But once I discovered Standard ML and OCaml I found out how wonderful
abstraction can be.

~~~
bkeroack
I'm not sure many people are arguing that abstraction isn't good for _those
who are writing the code_ \--that's the whole point of abstraction after all,
to make the developer's job easier.

The problems tend to crop up for other people trying to decipher and read it.
Sometimes also for the machine trying to execute it.

------
nothrabannosir
_> > ..., and extreme abstraction capabilities in high level languages like
Common Lisp, ..._

 _> Go has everything you mention in both of your lists of desirable
attributes (depending perhaps on what you mean by "extreme abstraction")_

"perhaps"? By whose definition would it ever even come close to "extreme
abstraction"? All of us assembly programmers, maybe?

Don't get me wrong, I use Go where it makes sense. It has pros and cons. I'm
literally programming Go right now. But "extreme abstraction"... you need more
than "perhaps" to qualify that.

Or was that his point and did I just completely miss the joke? Actually,
that's probably it.

~~~
howeyc
You missed what Donovan said, which answered the question. Obviously PL-
enthusiasts (give me all the shiny! all the time!) wont like the answer
though.

~~~
sanderjd
I don't really understand the claim that generic programming is "shiny". It is
an old idea that has been implemented many times. It's totally fine that the
Go team left out generics – it's their decision – but denigrating people who
lament that decision as shiny-chasing PL-enthusiasts is unfair.

------
agentultra
Kernighan's response to the C question was rather odd -- where is this myth
that C is only used in embedded systems and drivers coming from?

The Linux kernel is still written in C.

Ben Klemens, author of 21st Century C, leads the statistical computing group
for the research arm of the U.S. Census Bureau. He models complex systems and
computations in C.

The entire Python scientific computing stack is resting on C.

A huge portion of the GHC compiler is written in C.

Many AAA game developer studios are writing their engines in C (with vendor
supplied C++ compilers, but C none-the-less).

And do people really write C89 for greenfield projects today? C99 is pretty
amazing and has added some great features to the language. C11 _might_ be the
trivial change having only added some atomic operators (depending on whether
you think this is trivial) and rescinding VLAs (though most compilers will
probably continue to support them anyway).

I think Go is a perfectly fine language but it seems like perhaps the group is
a little out of touch with the rest of the world judging by replies to
questions like this.

~~~
lobster_johnson
Kernighan wasn't the one claiming that C was mostly used for embedded systems
and drivers; that was the guy who posed the question. Kernighan only agreed
that C is still popular in that space.

As for C99, I would love to see some hard stats about rate of adoption.
Personally I can't imagine starting out on a new project and _not_ use C99,
but then the hard-core C contingency is a pretty conservative bunch. (Are
there still systems where you can't get a C99 compiler?)

~~~
4ad
> Are there still systems where you can't get a C99 compiler?

In windows it's pretty annoying to get a C99 compiler. The "standard" compiler
to do Windows development is Microsoft's, and it doesn't support C99.

Of course you can install MinGW (gcc); most open source software on Windows
uses it, but it's very unusual for the average Windows developer to even have
gcc, and completely unheard of in the commercial space.

I will also note that installing MinGW in Windows is a pretty painful
experience as well, which doesn't help.

For most Windows developers, if it doesn't ship in Visual Studio, it doesn't
exist.

~~~
cygx
Don't forget about the Intel C++ Compiler and Clang, never mind more obscure
alternatives like TinyCC, Pelles C and Comeau C/C++.

There _are_ options.

Also note that Microsoft has finally started improving C99 support with Visual
Studio 2013 and 2015.

~~~
pjmlp
> Also note that Microsoft has finally started improving C99 support with
> Visual Studio 2013 and 2015.

Only as far as C++ standard requires C compatibility.

For Microsoft the future for native programming on Windows are C++ and .NET
Native.

For compatibility with open source world and ISV that still care about C, the
answer is the integration of Clang frontend with Visual C++'s backend, that is
coming with Visual Studio 2015 Update 1.

------
gamesbrainiac
I never knew that the decision to not have versioning built into go was
because of the diamond dependency problem. This makes a lot of sense now that
I think about it. I wonder what alternatives to manually versioning things the
go team is considering.

Also, at the beginning the Go team wasn't all that enthusiastic about an IDE,
but its great to see that Go will get an IntelliJ grade IDE soon, so that
works for me :)

~~~
lostcolony
I really am not a fan of the lack of versioning, even with that explanation.
Of course diamond dependencies are a problem. But they haven't actually fixed
that problem; they've just declared a method for picking one of the two
dependencies that is ill defined ("whichever one you happen to have pulled in
first"). At least with versioning I get told that there's an incompatibility
in the expectations between two libraries.

With Go's removal of version numbers, they haven't removed any of the
complexity of resolving incompatibilities, they've just hidden the fact that
there is one. I would have much preferred a strategy of maintaining version
numbers, and resolving them via "either you specify what version you want
pulled in, or we'll build with the most recent and throw a warning".

~~~
psadauskas
I think that the solution to this problem is one of the few things that nodejs
got right. Instead of declaring a global dependency on `require("D")`, you
assign it a variable name. Then, each package can declare its sub-
dependencies, and even when the versions differ, the different versions are
kept in a different scope.

[https://nodejs.org/api/modules.html](https://nodejs.org/api/modules.html)

    
    
      // Package A:
      import B from "B"; // A/node_modules/B/1.0.0
      import C from "C"; // A/node_modules/C/1.0.0
    
      // Package B:
      import D from "D"; // A/node_modules/B/1.0.0/node_modules/D/1.0.0
    
    
      // Package C:
      import D from "D"; // A/node_modules/C/1.0.0/node_modules/D/2.0.0

~~~
jasonwatkinspdx
I'm convinced this is the right approach: dependencies should be purely local
to a module. The tooling should make it easy to detect you have a diamond, but
let each module get what it needs. As generally everyone moves towards more
continuous update and integration, at the end of the day it's all gonna be
sha's anyhow.

~~~
wtetzner
But what do you do in a typed language? For example, suppose you have modules
A and B, which depend on module C. Let's also say that module A has a function
foo that return a value of type C.t, and module B has a function bar that
accepts a value of type C.t.

Now let's say that module A is depending on version 1.0.0 of module C, and
module B is depending on version 1.5.2 of module C.

Does B.bar(A.foo()) still work? Is type t the same in C version 1.0.0 and
1.5.2?

~~~
eknkc
Good point. But if B.bar accepts an interface that C.t implements, then
everything should work just fine and that should be the way to go on public
APIs.

~~~
wtetzner
But what if the interface is defined in C? The interface has to live
somewhere, and wouldn't it be versioned too?

------
stcredzero
Here's a solution to the diamond dependency problem: Imports can only be done
for a specific lexical scope. Also, imports must specify a particular version.
Lastly, calls to a package go to a specific version of the package, and types
are defined in a specific version. (This is why all imports must be done for a
specific lexical scope.)

The same scheme could be used to resolve diamond dependencies in multiple
inheritance as well.

~~~
pcwalton
That's essentially the solution Rust and Cargo adopt. It occasionally causes
strange errors like "expected Foo, found Foo" (where the first Foo was, say,
Foo version 1.1 and the second was Foo version 1.2), but the compiler now
detects this situation and tries to explain what's going on.

I'm certain I'm biased, but in my experience it's been the most robust way to
handle versioning that I've dealt with.

~~~
stcredzero
I proposed this in a Smalltalk newsgroup over a decade ago. The reaction? I
was ridiculed.

Imports naming specific versions would also allow better integration of
code/build into a version control system. Actually, the entire OS should be
built with version control in mind from the ground up.

~~~
CyberDildonics
No truly good idea will ever escape ridicule.

------
KyleBrandt
The recently open sourced VSCode also has Go support now. Good first
impression. The docs and type inference stuff are more convenient compared to
the oracle plugin + GoSublime for sublime it seems.

~~~
ngrilly
I thought it was just syntax highlighting. Any link documenting VSCode's Go
suppport?

~~~
pjmlp
There is a video of the presentation:

[https://channel9.msdn.com/Events/Visual-Studio/Connect-
event...](https://channel9.msdn.com/Events/Visual-Studio/Connect-
event-2015/060)

~~~
cdnsteve
Jump to 2:15, great to see!

------
percept
"The reason it took God only six days to create the universe is that he didn't
have to deal with the embedded base."

------
nickpsecurity
Nice interview. Plenty of good details. I mean, there was this slip:

"The languages... are either long gone (PL/1) "

[http://www-03.ibm.com/software/products/en/plicompfami](http://www-03.ibm.com/software/products/en/plicompfami)

[http://www.fujitsu.com/fts/products/computing/servers/mainfr...](http://www.fujitsu.com/fts/products/computing/servers/mainframe/bs2000/software/programming/pl1.html)

[http://www.iron-spring.com/about.html](http://www.iron-spring.com/about.html)

Next he's going to be telling you COBOL is gone, too. Big time writers'
definition of dead/gone in IT has always seemed different than general usage.
;)

------
lynchdt
This us utterly hypnotic. Nice work.

------
incepted
> In general, Go strongly encourages being explicit about errors.

That's completely incorrect: it's trivial (and common) to just ignore errors
in Go:

    
    
        ok, _ := Foo()
    

Checked exceptions don't let you get away with this kind of sloppy
programming.

~~~
ngrilly
It's also trivial to "just ignore errors" in a language based on checked
exceptions:

    
    
        try {
            ok = foo()
        } catch (Exception e) {
            // Do nothing
        }
    

Checked exceptions don't save you from "this kind of sloppy programming".

~~~
incepted
But you have to write the `catch` (or a `throws`). That's the point.

Now if you choose to handle this stupidly, that's entirely your fault, but at
least the compiler did its jobs by forcing you to think about the error case.

In Go, the compiler doesn't enforce anything.

~~~
ngrilly
How many lines of Go have you written before writing this?

In Go, as in Java with checked exceptions, the compiler forces the programmer
to handle the error.

Using _ in Go is not idiomatic. It's the exact equivalent of using a try/catch
block with nothing in the catch block in Java.

~~~
pcwalton
If you call a function that returns nothing but an error, Go does not force
you to acknowledge the error's existence and will silently allow you to drop
it.

