I’m joining the Go team at Google

http://spf13.com/post/joining-go-team-at-google

by duck • 10 years ago

245 199 10 years ago

spf13.com

fibo• 10 years ago

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

kozikow2• 10 years ago

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.

tqkxzugoaupvwqr2• 10 years ago

JetBrains WebStorm with the free Go plug-in provides an excellent Go IDE experience. There are some free community editions of JetBrains IDEs that are supposed to work with the Go plug-in (e.g. PyCharm, if I’m not wrong), so you do not even have to pay anything.

https://www.jetbrains.com/products.html?fromMenu#type=ide

powerslave85• 10 years ago

It is not excellent. All other editors I used autoformat Go code after save. There are two types of format provided by IDEA - IDE Format & go fmt. Both not ideal. IDE Format does not format code according go guidelines. It can delete unused imports if you go through options. go fmt does not delete unused imports, and as result code is not compileble.

Refactorings are missing in IDEA. It is not excellent, it is something you can work with.

vetinari2• 10 years ago

That looks like limitation of ycmd, not golang.

Most go modes for various editors use native go utilities as their backend, for example gocode/godef/golint/gorename/guru, etc.

the_duke4• 10 years ago

My main iusses:

-) A proper package manager. (no, go get is not enough. They have realized this and have a team coming up with a draft for an official one)

-) Well written, well maintained libraries that do proper releases. There are very few of those out there. Might get better with an offical package manager and ideally package repository a la npm/crates.io

-) Generics. This will help the previous point also. Often it's hard to write proper reusable libraries due to the lack of generics. And no, they didn't keep generics out because they are to complicated for the language users. They just (quote) "didn't find a good way to implement them", and big language changes like that are out of scope before 2.0.

-) Macros probably won't ever come, but if not, please at least give us a language construct that reduces error handling boilerplate. (Rust has some nice macros for that).

wyattjoh• 10 years ago

Generics

I was concerned by this at first as well, but after using Go full time for the past two years, I've never found a need/use for them. Go doesn't lean towards strict OO principles, where I feel that most of the Generics uses are applied (Arrays, sorting, etc.).

Not everyone's opinion, just my two cents.

leetrout• 10 years ago

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

akhilcacharya• 10 years ago

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).

kozikow2• 10 years ago

I have the same features form ycmd. ycmd actually works with atom as well and also supports go.

Pushing all "IDE" features into editor-agnostic daemon is a good path for the future. ycmd is taking this spot.

ruffrey• 10 years ago

Atom has surprisingly consistent and useful support for go - fmt on save, debugging, automatically manages imports in a file, and the autocomplete works very well.

karakal• 10 years ago

Why do people find the need to write about themselves in third person? https://stevefrancia.com/

pgt• 10 years ago

It irks me too, but it is a convenient piece of ready-made press text that can be used for introducing you on stage or in other media.

TurboHaskal• 10 years ago

So that others can spot the narcissist.

amelius• 10 years ago

It's better than first person plural form :)

bbcbasic• 10 years ago

We'd like to think so

coriny2• 10 years ago

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• 10 years ago

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.

patates• 10 years ago

I think it's just a convention that's used when writing "About The Author" sections. Not really a statement of personality.

oneloop• 10 years ago

I noticed that too. Also, "leader".

hnarayanan• 10 years ago

Congratulations, but what of Hugo? :)

squeed2• 10 years ago

Congratulations!

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

Touche2• 10 years ago

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

squeed2• 10 years ago

The default golang flag package (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.

smegel• 10 years ago

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

Is Go really expressive?

favadi• 10 years ago

Fairly verbose. But he was talking about the "balance".

coldtea6• 10 years ago

How it is a balance if expressiveness suffers?

jnordwick5• 10 years ago

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.

Profan• 10 years ago

... R-RIAA? You probably meant RAII right: http://www.riaa.com/

Resource management by litigation sounds innovative though

rebeccaskinner2• 10 years ago

It is pretty readable, but really non-functional too

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

ex_amazon_sde• 10 years ago

Not really. It's very verbose compared to Python, almost like Java.

the_duke4• 10 years ago

Noo that's an overstatement.

Of course it's not as clean as Python, it's statically typed.

But type inference makes code way cleaner than your typical Java code (Javas type inference is improving, though).

XorNot• 10 years ago

* 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).

jnordwick5• 10 years ago

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.

Vendan• 10 years ago

note that new() already exists in the language.

howeman• 10 years ago

https://godoc.org/github.com/gonum/floats#Round

petre• 10 years ago

Haha, no number rounding function/method in the standard math lib? And I thought Dlang missing a BigFloat type was a deal breaker.

tkubacki2• 10 years ago

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

Make decent visual debugger and devs will come.

romanovcode• 10 years ago

Visual Studio code has pretty decent debugger for Go.

chillydawg• 10 years ago

Is that delve? If so, it doesn't work debugging tests, which makes it, depending on your style either totally useless or just quite annoying to use.

swah• 10 years ago

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

tkubacki2• 10 years ago

some legacy Windows server stuff - part of this could be rewritten to Linux/Go/whatever_server_lang just team mates are not willing to leave their comfortable VS env. if not provided with decent IDE/debugger

rpeden2• 10 years ago

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.

pjmlp19• 10 years ago

On our case desktop applications for interacting with healthcare and manufacturing devices, web sites and distributed computing.

gravypod6• 10 years ago

In general make good tooling and others will come. Look at Java/Eclipse

sdegutis5• 10 years ago

Can confirm. At work we're moving from Clojure 8 to Java 8 partially because IntelliJ is amazing and partially because Java 8 plus the right libraries is close enough to Clojure anyway, except much faster.

pmarreck10• 10 years ago

Make decent unit test coverage and you'll hardly ever see a debugger again. Neither will you need a fancy code editor.

tigershark• 10 years ago

Nope. It is absolutely false. You will always need a debugger and there are some problems that are not unit testable at all. How do you unit test a random WPF bug? And you'll always need a fancy code editor unless you're masochist.

Kubuxu• 10 years ago

That is true, I used to work in legacy Java code base and the debugger was my Lord and Saviour. I am now working in fresh, well tested (both unit and integration) Go codebase and I yet to have to use debugger. Usually adding few debug logs (which usually just stay there for future) and writing test case for new discovered edge case is enough.

zvrba• 10 years ago

Programming in C# feels almost like scripting. Blazing-fast compilation with the added benefit of static type system. If only MS took a different path of cross-platform support in the beginning.

pjmlp19• 10 years ago

That was already our experience in Turbo Pascal, Delphi, Oberon, .... :)

My only complaint is that they took the CLR path instead of the Ext-VOS one, with is now reborn as UWP (aka WinRT).

erikb• 10 years ago

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

aurelianito2• 10 years ago

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

cbHXBY1D• 10 years ago

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

asdfologist• 10 years ago

Generics please.

coldtea6• 10 years ago

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.

dgb23• 10 years ago

Some of the harder more time consuming things in high level programming include abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java. Think about how many hours you have to invest to learn any of these things in either language.

tmpxkdks• 10 years ago

abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java

Really? A lot of copy/pasted code, generics replaced with casts on empty interfaces, poor support for collections, only very primitive concurrency tools, and so on...

I can understand that simplicity is good for small CLI/network tools, but it is hardly an alternative for really big applications where Java is vastly used

pjmlp19• 10 years ago

Think about how many hours you have to invest in writing workarounds for features available out of the box in other languages.

jerf2• 10 years ago

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.

eternalban• 10 years ago

I take no issue with your take on the language, but the OPs' opposing views on "revolutionizing how we write software" isn't really addressed by you.

Go is popular because it is accessible. The cognitize load of the language is in effect ammortized by being spread over the life cycle of the dev process (i.e. run vet to do x) instead at localized in cycle/space of code-time/source-code, so even professionals not bothered by complexity can see an incentive to using the language.

But I am not aware of the language enabling a class of software systems, etc., that have become more feasable because of the language.

As has been pointed out by many, at some point even the novice programmer has to get serious given the mix of pointers and channels and sync constructs which demands a degree of sophistication, so the accessibility aspect degrades over time.

And then -- and here is why I feel there is pushback regarding Go koolaid -- this somewhat on 'the fence' approach of the language towards concurrency (originally "communicate don't share memory") gives this impression of a glorious hack but a hack aspect to this "revolutionary mix" that you refer to. At some point, the ala cart type system of Go presents issues to people who have invested the time to get serious about these matters but find that their favorite light-weight language is not fully up to the task of keeping up with our conceptual models of thinking about our software.

pcwalton3• 10 years ago

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.

coldtea6• 10 years ago

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.

I'm ok with the Algol part as it pertains to syntax.

Semantics and expression though, is another thing...

aws_ls4• 10 years ago

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

By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need? Ideal for minimalists. That's its beauty. Programs are very stable. Takes less memory than Java (some amount more than C/C++). Faster compilation time compared to C++. A convenient C. For minimalists, who like to cut down all the jargon, and solve the problem. Looking at it that way, you see its beauty.

edit: typo

vvanders3• 10 years ago

And providing a better C.

I keep seeing this come up and I wonder if people have actually used C in the domains where it matters.

Go is not a C replacement/better C. You don't have control over what goes on the stack/heap which means you can't control memory layout. If you can't do that you're throwing away one of the key reasons you'd use C. Memory layout is critical to getting that 10-50x performance that you can't get in a managed language.

There's a bunch of domains where Go excels but if you're on constrained hardware where you really need the last bit of perf/memory it would not be the tool I reach for.

coldtea6• 10 years ago

By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need?

Language consistency (no magical functions like "make" or magical items like slices), DRYness (generics), better type-safety than C (interface{} is the void * of the 21st century), would be a good start.

Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc.

nbevans• 10 years ago

It's not really surprising though is it. He worked for MongoDB. He's a "magpie developer".

traverseda• 10 years ago

At best, it introduced some dynamic language programmers to static types and static builds.

Can confirm (well, add another point of anecdote), I played with it a bit in order to get some experience with static stuff before diving into the whole C ecosystem.

Next thing I build that needs that kind of development will probably be C though.

pmarreck10• 10 years ago

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.

thwd3• 10 years ago

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.

aninhumer3• 10 years ago

However it treats them as product values (tuples) instead of sum values (Either), so it's perfectly possible to ignore the error and take the result anyway.

pmarreck10• 10 years ago

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?

junke5• 10 years ago

Go forces you to use errcheck.

packetslave3• 10 years ago

You're "sorry to hear" that he got a great job doing something he's excited and passionate about? Wow.

junke5• 10 years ago

Funny how taking things out of context can change the meaning. If you look at the second sentence, you can infer what the first one is about.

bigato• 10 years ago

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

snippet22• 10 years ago

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.

Lord_Zero• 10 years ago

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

bitmapbrother• 10 years ago

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

Jgrubb• 10 years ago

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• 10 years ago

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• 10 years ago

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.

I’m joining the Go team at Google

Related Stories