
I’m joining the Go team at Google - duck
http://spf13.com/post/joining-go-team-at-google
======
coldtea
> _As I had before, I recognized that this technology had the potential to
> revolutionize how software was written at a fundamental level._

Congrats and all, and I love Hugo (use it all the time).

That said, I think the kool-aid was spiked with something.

Sorry, but in what way is Go "revolutionizing"?

I'd buy "refreshing simplicity" and "yay, static builds again" but it's hardly
revolutionary, even in its most touted feature (channels).

And it hardly changed how people write software. At best, it introduced some
dynamic language programmers to static types and static builds.

All the rest, including creating a language that's easy for average
programmers to program at scale was already the goal, and a success at that,
of Java.

~~~
jerf
Go's big success, in my opinion, was to fuse the lightweight, spawn a million
threads we don't care, style of programming to conventional imperative,
conventional static-type programming. I know of several other runtimes that
had that lightweight threading capability, I've been using them since years
before Go was even a thing, but they all required programmers to learn a new
paradigm. At times, a _radically_ new paradigm (Haskell).

You may complain that programmers have a professional obligation to learn
those new paradigms. You may complain that programmers should consider
"learning a new paradigm" a smaller strike against a language, especially if
it brings other good things with it. But that won't change observed reality,
in which programmers do want to not have to risk several months to a year on
something they aren't sure will pay off. By contrast, if you know any of the
existing manifestly-typed languages at all (Java, C, C++), which most
programmers do to some extent, you'll be writing fancy concurrent code in Go
next _week_. Possibly even "tomorrow". You can be shipping production code in
a month.

The language nerd in me really wishes Go had isolated its goroutines from each
other and only passed things by value. (While I like Rust's much finer-grained
handling of that for a lot of other reasons, you can get a lot of the benefits
in a language where the threads aren't supposed to be that large by isolating
to small threads, and it's way easier to implement.) The pragmatist in me is
forced to reluctantly admit that had it done so it probably wouldn't have
succeeded as much, because while that may not have been a "full" paradigm
shift if the rest of the language was still imperative, it still would have
been at least half of one. That affects how you design larger programs. In a
lot of good ways, I think, but still, change with an unknown prospect of
payoff.

So... it depends on your point of view. It's not revolutionary in the sense
that there's anything new in it. But it is a somewhat revolutionary
combination of concepts.

You're even free to join me in being a bit sad that fusing your concepts to an
Algol-descended language is basically mandatory for success right now. But,
one step at a time. We are slowly creeping away from it. As I've often
observed, programming as a profession does not move anywhere near as quickly
as some people think; there's a constant surface churn of technologies and
languages, but deep paradigm shifts take decades.

~~~
pcwalton
> I know of several other runtimes that had that lightweight threading
> capability, I've been using them since years before Go was even a thing, but
> they all required programmers to learn a new paradigm.

One of those runtimes is Ruby (Ruby uses lightweight threads, not OS threads),
and Ruby is not a new paradigm.

~~~
dragonwriter
Ruby (that is, the main implementation, from 1.9 on) uses OS threads with a
global lock so that only one thread running Ruby code is executing at a time
in a process, same as, e.g., Python.

Up through 1.8.x, Ruby used N:1 lightweight threads (multiple lightweight
threads on one OS threads.)

Go uses M:N threading (multiple lightweight threads, which may be distributed
among 1 or more OS threads.)

M:N threading is a different model than either the Ruby 1.9+ model (1:1
threading on OS threads with a global lock) or the older Ruby approach (N:1
threading), or even the JRuby approach (1:1 threading on OS threads with no
global lock.)

------
squeed
Congratulations!

And never, ever, ever give up the fight for GNU-style double-dash command-line
flags!

~~~
Touche
Context? Are people actually switching to single dash flags? If so I'll get my
pitchfork out of the closet.

~~~
squeed
The default golang flag package
([https://golang.org/pkg/flag/](https://golang.org/pkg/flag/)) does not
implement gnu-style long-with-shortcut options. Instead, one and two-dash
arguments are identical. For example, -enable-pants and --enable-pants are
equivalent. Compare this with the GNU style where you can have -p or --enable-
pants.

Most go programs I've read use spf13's flag library, which _is_ GNU-
compatible.

~~~
Touche
Is this a remnant of Plan9 or something? Ugh, this is why I don't dabble in
ecosystems with overly opinionated leaders. You have to know when to have a
strong opinion and when to do things the standard way, and some people can't
do that.

~~~
4ad
Plan 9 doesn't have --long-options at all. In Plan 9 arguments are single
letter.

------
Jgrubb
I interviewed at Mongo a long time ago for a Drupal developer position. It was
strange, they took me through a bunch of whiteboard algorithm crap that had
nothing to do with Drupal. Obviously they weren't Drupal devs and didn't know
how to interview for one so they just gave me the standard CS stuff. Obviously
I was a Drupal dev so I didn't know shit about actual CS topics. I failed hard
and learned a lot from it.

Steve was the only one of the 3 that I interviewed with that didn't come
across as a self-important asshole. He was kind and helpful and overall seemed
like the perfect guy for a Developer Advocate or whatever the title was. I
wish him luck.

~~~
dmix
> they took me through a bunch of whiteboard algorithm crap that had nothing
> to do with Drupal.

Oh I hate that type of interview. I had a similar experience getting
interviewed for a front-end dev position by two backend devs at a consumer VPN
company in Toronto who asked me to write common CS algorithms while they both
sat there staring at me.

Even ignoring the total lack of connection between the content of the algo
with the job in question, I've never coded like that in my life. Largely
because I also never took a CS course and didn't bothered to study cliche
interview questions because I don't apply to big cos. But most importantly, I
don't solve problems on the spot in front of other people IRL, so what
aptitude are they testing for exactly?

I'm an introvert who always codes with headphones on and likes to spend time
thinking through problems on my own - but can also work with other devs to
solve problems when needed. I also had OSS projects, private repos I could
show them, and live production apps with tens of thousands of visitors I built
myself to point to my aptitude. That's been more than enough for other smart
teams to hire me. It's also the content I look for most when I've hired people
myself.

The non-technical founder also never told me ahead of time they were going to
do this type of interview so I was surprised when they sat me down.

Also during a telephone interview with their other semi-technical founder
asked me to describe how NAT works (yes asking a front-end dev to describe
network implementation details). I figured he was just confused about what I
would be doing for them... then I showed up to meet the two backend devs the
next day.

I just walked out of the interview and told the founder his hiring process was
silly, even though I liked the company (product). I'm happy I did.

I should note that I'm not against the idea of measuring aptitude during the
hiring process, if companies want to be thorough. For example. during another
interview process with a different company a dev team gave me a problem to
solve (with ample warning before I arrived that day) and let me solve it on my
own, using my own laptop in a quiet room, while they went back to work at
their own desks for an hour or two (taking however long I needed). I was fine
with that process and it worked out. There was also a collaborative element to
it as well. That was a test better grounded in the reality of software
development.

~~~
svintus
Person who interviewed you here. Our interview process may not be perfect, but
surely going into a technical interview, you could expect some coding
questions. You mentioned that we "asked [you] to write common CS algorithms",
like we asked you to do invert a binary tree. That, indeed, would be
ridiculous.

In fact, if I recall, we asked you to reverse a string. This is not an
"algorithm" question, it's a basic programming aptitute test and if you can't
do it on a piece of paper, this is a major red flag for us. Furthermore, you
demonstrated a lack of understanding of basic JavaScript concepts like
prototypes and scoping. This, and your personal attitude, were the reason why
we did not hire you for the front end deveoper position.

You are no doubt a hardworking and resourceful individual, but we were looking
for something more than ability to glue JavaScript libraries together. I wish
you, and "other smart teams that hire [you]", all the best.

~~~
zepolen
Hey, what was the acceptable answer to reverse a string in javascript?

------
bigato
The one request I make is, please do not give in to complexity in order to
accommodate to all users' requests.

------
pmarreck
I'm sorry to hear that. Go is _not_ revolutionary (unless you count
"completely ignoring runtime errors" to be revolutionary). If anything,
functional languages are the new, old, revolutionary thing.

~~~
thwd
How does Go completely ignore run-time errors? For all I know it forces you to
deal with them by treating them as values instead of exceptions.

~~~
pmarreck
How does treating them as values _force_ you to deal with them (except on
principle)? Does the language force you to check the return value of every
line of code? And the checking would only encompass _expected_ errors, not
_unexpected_ ones, no? The unexpected ones (read: bugs) would simply be
swallowed up and the actual problem would finally turn up far away in some
other stack scope, no?

~~~
thwd
True, you can discard errors on purpose by assigning them to "_", which is an
explicit way of saying "I do not care about this error happening". If you do
that and get a panic down the line, you already know where to start debugging.
That's much better than having an exception bubble up from deeeeep inside your
code with some context-less cryptic message or number, isn't it?

~~~
pmarreck
> That's much better than having an exception bubble up from deeeeep inside
> your code with some context-less cryptic message or number, isn't it?

I don't see how that follows. A stack trace (as initially cryptic as it seems)
is a record of all the code that would have affected the current buggy state
you find yourself in. If anything, a stack trace isn't comprehensive enough,
ideally it would include all known/named values at every level of the stack...
a large quantity of information, to be sure, but perhaps it could be narrowed
down by diffing each stack level with the previous one or something. But if
you could have those 2 things, you would have literally ALL the information
you needed to fix the bug. Since bugs are programmer-unexpected states, and
the stack trace plus the known values at each stack level are LITERALLY the
entire state.

So correct me if I'm wrong, if you don't assign an error to a variable on the
same line in Go, it throws? Because it was my understanding that there were
absolutely no throws at all in Go. Or is it only that certain kinds of
statements are _expected_ to possibly error, and must therefore be assigned to
a variable (or _)?

~~~
Conlectus
Any error return values in go must be assigned to a variable at call time,
otherwise it's a compile error. Unused variables are also a compile error, so
you are forced to do something with it.

Assigning to _ effectively ignores the error, but is considered a very bad
practice.

Unavoidable runtime errors (eg divide by 0) will generate a panic, which is
similar to an exception, but is uncatchable within the Go routine it
originates in.

~~~
danieldk
_Any error return values in go must be assigned to a variable at call time,
otherwise it 's a compile error._

Nonsense.

    
    
       fmt.Println("Hello world!")
    

I just ignored an error and it compiles fine. Go check the return type of
Println:

[https://golang.org/pkg/fmt/#Println](https://golang.org/pkg/fmt/#Println)

tl;dr, it's very easy to accidentally ignore errors in functions that are
side-effecting or modify parameters. Been there, done that.

~~~
pmarreck
Yeah, that's what I thought. And I've _also_ been there, done that. Is there
basically some willful blindness around this issue with Go fans, or something?
Or a lack of experience doing code? Or am I completely missing something?

------
kozikow
> What is missing from the Go ecosystem?

Personally, golang "IDE" experience is not as good as Java or even C++.

For example, ycmd only supports subset of functions for golang. I miss ycmd-
goto-references the most.

~~~
leetrout
Please do try atom with the go-plus package. It has goto def, can show "doc
strings", and has decent integration with delve.

~~~
akhilcacharya
For me, using LiteIDE and Atom + go-plus was what got me comfortable with Go.
Without it, I felt it was far too finicky and had lots of hidden gotchas (like
no unused variables).

------
XorNot
* Interfaces which can have fields would be really, really great.

* A rust-style borrow checker would make dealing with channels and pointers a lot safer.

* Equality operations for slices would clean up some ugly parts of the standard net library (addresses are []byte, so a direct x == y doesn't work but seems like it should).

* Closed enum sets: some ability to setup an enum type which can be "complete" when used in a switch statement without needing a "default" and which will only panic/fail when a bad type conversion is made. Let me sanitize out a whole bunch of possible errors at one point in my code when I want to use constants (and be warned when I break the guarantees).

~~~
jnordwick
My two Golang pet peeves, not very important either:

-still no math.round WTF?

-make() should be syntax and not this quasi-function that takes this vast array of argument types, and while you're at it, you should just rename it `new`, because that's what it is.

~~~
howeman
[https://godoc.org/github.com/gonum/floats#Round](https://godoc.org/github.com/gonum/floats#Round)

~~~
jnordwick
Is gonum part of Golang? I don't think I should have to pull in an entire
library just to get a working round implementation.

------
tkubacki
I'm using C# mainly because of debugger integration in Visual Studio.

Make decent visual debugger and devs will come.

~~~
swah
What are you developing with C#? I see Go more for server-side stuff, and C#
for Unity/Desktop development...

~~~
rpeden
Interesting. I've used C# heavily at my last couple of jobs and it has all
been server side web work - mostly back ends of web apps, but also services
and microservices of various kinds.

From talks with coworkers, the impression I've gotten is that most C# in the
wild is running server side, though there's obviously a lot of it in desktop
apps, and on mobile with Xamarin.

------
fibo
I am happy for you spf13, congratulations! And thanks again for software you
wrote, like hugo!

------
karakal
Why do people find the need to write about themselves in third person?
[https://stevefrancia.com/](https://stevefrancia.com/)

~~~
coriny
As a habit it is bad, but this is actually standard for short bios. It allows
it to be dropped in place directly for conferences, PR shots, news articles,
etc without any rewrite.

~~~
briceb8e
Great to make it look like someone took the time to do a bio about you because
you're important, while it's just you writing. Lack of self-confidence if you
ask me.

~~~
dagw
_Lack of self-confidence if you ask me._

How do you figure? Every time I've been asked for a bio for a conference or
similar, they've asked for it in third person. Reading bios in conference
proceeding in first person would just come across as weird to me.

~~~
whamlastxmas
The difference is having a bio on a website _about yourself_ versus a bio on a
website about a lot of people. No one thinks that your johndoe.com site was
made by your official fan club.

~~~
jnordwick
You really named your user account after WHAM!? That's fucking awesome. Tell
me you're either George Michael or Andrew Ridgey in deep disguise... please
please.

~~~
whamlastxmas
Just another jitterbug, but you gotta have faith that I'm once bitten and
twice shy.

------
erikb
What is your favorite opening? I like the High Chinese.

~~~
aurelianito
If someone makes an alternative go implementation, they should name it baduk
or weiqi.

~~~
cbHXBY1D
At least it would make the language and ecosystem [slightly] more Google-able.

~~~
aurelianito
It would collide with the game. It should be worst in the beginning.

------
hnarayanan
Congratulations, but what of Hugo? :)

------
smegel
> Go has the nearly perfect balance of readability, expressibility and
> simplicity

Is Go really expressive?

~~~
jnordwick
It is pretty readable, but really non-functional too. Eg, they still don't
have math.round and you wind up writing a lot of code because it can be a
little bare bones or does things in a way that isn't quit usable.

I wouldn't say it is very expressive either. Go can be very wordy and verbose
at times, and some things are downright a pain or poorly thought out (e.g,
while Java has finally and C++/Rust have RIAA for dealing with resource
deallocation Go has defer and it doesn't work really well when you encounter
an error in the dealloc logic).

Simplicity is about Java 1.0. Give Go some time to add some technical debt
before you get too excited about it simplicity.

It isn't a bad language. This is my second run thought the language, and I'm
neither excited nor turned off by it.

~~~
rebeccaskinner
> It is pretty readable, but really non-functional too

There are projects starting to fix that: [https://github.com/asteris-
llc/gofpher](https://github.com/asteris-llc/gofpher)

~~~
johncolanduoni
I think he meant non-functional in the sense of "not functioning", not
functional programming. Neither of his immediately following complaints have
anything to do with functional programming.

~~~
rebeccaskinner
I was trying to be funny and missed the mark

------
asdfologist
Generics please.

------
Lord_Zero
How does this guy just stumble his way into Mongo and Docker. WTF am I doing
with my life?

~~~
bitmapbrother
I dunno, perhaps develop very good open source projects like Viper, Hugo,
etc...

------
snippet22
One thing I liked the most about JavaScript was chaining methods.

One thing I liked the most about c# was the libraries in one place.

One thing I liked the most about PHP is the many array methods and easy to
call methods from objects.

One thing I liked the most about Python is the readability and built in
debugger into the language.

One thing I didn't like about all of them is all the libraries you have to
memorize.

