
Go’s runtime C to Go rewrite, by the numbers - davecheney
http://dave.cheney.net/2014/09/01/gos-runtime-c-to-go-rewrite-by-the-numbers
======
johan_larson
Why Go?

I had a chance to do a bit of Go a year or so ago, and found the language very
(how to put it?) bland. There just didn't seem to be anything surprising or
obviously better about it.

If the alternative is C++, I can understand the appeal of garbage collection
and getting away from the complexities of the STL. But Java provides both.
Anyone want to make the case for Go over Java?

~~~
jbooth
A lot of us _love_ bland. Personally working on Scala for my day job and I
curse the authors every time I see some neato feature that's been abused by a
bored dev or a dev on a deadline.

As far as Go over Java, in terms of differences:

1) Error codes instead of exceptions, big difference, puts Go more in the
'write a server' than 'write an application' category although those lines
have been blurred

2) Duck typed interfaces, type inference, automatic delegation and whole bunch
of useful little things that make Go, IMO, "Java done right". Regardless of
the fact that most of the Go community would want to punch me for calling it
that. Go's conventions encourage 2010s Java, Java can sometimes encourage
1990s java.

3) Goroutines being first class is quite different from always
instantiating/passing-around an ExecutorService.

4) First class functions and lambdas, although lambdas are a little less
useful for not having generics.

~~~
georgedrummond
I love bland and hate surprises.

One of the features I despise most in Ruby is Monkey Patching since it changes
expected behaviour.

------
silversmith
What's interesting is amount of C and Go code being so proportional - for
every 100 lines of C code rewritten you seem to get 100 lines of Go.

It surprises me, because from what I've seen Go seems to be much higher level
language. Or are those just all the `if err != nil` lines?

~~~
andrewchambers
The runtime code probably deals with a few things that aren't as compact in Go
either. For example using the unsafe package in Go is very verbose since you
are trying to work around the type system. C just lets you dereference any
pointer you want etc etc.

There are many types of code that are significantly longer in C# or java than
in C, just because C lets you do crazy things with memory mapping.

To get more terse code, you need to switch from the C family of sytax imo.

~~~
zak_mc_kracken
There are plenty of C family syntax languages that are more compact. The main
reason why Go is very verbose is because it doesn't support generics (so you
have to duplicate a lot of code) and no exceptions (so your code is littered
with

    
    
        ok, err := Foo()
        if err { ... }
    

and then the caller has to do the same thing (basically reinventing manually
what exceptions do for you).

~~~
_delirium
Absent exceptions, for quick-and-dirty stuff I wish Go had a mode like Bash's
'set -e', which just aborts on any error return from any call. When the only
thing you want to do on errors is abort the program, it's really tedious to
write that same "if err, exit" after every function call. But perhaps the
golang people's answer would be that for those kinds of quick-and-dirty
programs, I should be using a shell script anyway, not Go? Or maybe Perl,
which does require an explicit check, but uses a compact idiom for it, _f() or
die;_

~~~
Lewisham
Yeah, I'd quite like an `or die;` equivalent, as I've run into the same thing
as you: scripts that can't do anything if the chain of commands fails
anywhere. I have written functions that do the same thing: xOrDie(), but it's
a bit sucky.

As far as "Why Go for shell scripts?" I actually think Go is pretty well
suited to shell scripts (aside from no or die): getting stdout/stderr pipes
set up is pretty trivial with the exec package. There must be anecdotal law
somewhere that states that all shell scripts tend to Turing completeness over
time: what starts with "oh, a small shell script would do this" always ends up
growing to a full blown 1000+ line program with multiple code paths. Writing
the first script in Go is a piece of defensive programming so that when it
inevitably grows, it's growing into a language that better supports its size
(static typing, readability, libraries etc.) It's probably overkill for
personal stuff, but it is probably the right hammer for the job over time when
it comes to corporate work.

------
mholt
Cool visualization. What causes the spikes? Code merges?

~~~
vanderZwan
Wouldn't make sense for the few solitary spike though. Perhaps they are found
regressions, causing them to go back to the original C code for a while? That
would make sense in the context of merges too - there's _always_ a few bugs
that show up under closer scrutiny.

------
fulafel
Spoiler: Flash plugin would let you see a timeline graph showing lines-of-C vs
lines-of-Go in the go project.

(Strange that a Google Docs widget requires Flash...)

~~~
Cthulhu_
Google Docs was built before HTML5 was a thing. Second, lots of companies
switched to Docs without being able to switch to a modern browser, so they're
stuck with Flash for proper visualisations like that - and Google can't just
drop support without losing enterprise customers.

~~~
cokernel_hacker
The seem to have a workable solution for Youtube: they support both HTML5
_and_ flash.

