Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I’m joining the Go team at Google

spf13.com

Post reply on HN
Print view View original

201–210 of 211 posts

Re: I’m joining the Go team at Google

#201

Post by johncolanduoni »

pjmlp wrote: post #200
johncolanduoni wrote: post #198

Earlier quoted context omitted.

Unfortunately .NET Native is still for UWP only, so for most places you'd use Go it's pretty useless. Microsoft appears to have no plans to even bring it to ASP.NET: https://github.com/aspnet/Home/issues/285

Probably not, but they have CoreRT instead. https://github.com/dotnet/corert Many of us are actually mostly working on Windows, so NGEN, RyuJIT and .NET Native are all very good nice toolchain features. And if I compare Go with the whole .NET stack and tooling, there are lots of things I see missing, in spite of better AOT support across the board.

... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all.

I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.

Re: I’m joining the Go team at Google

#202

Post by pjmlp »

johncolanduoni wrote: post #201
pjmlp wrote: post #200

Earlier quoted context omitted.

Probably not, but they have CoreRT instead. https://github.com/dotnet/corert Many of us are actually mostly working on Windows, so NGEN, RyuJIT and .NET Native are all very good nice toolchain features. And if I compare Go with the whole .NET stack and tooling, there are lots of things I see missing, in spite of better AOT support across the board.

... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all. I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.

But that isn't a language feature, rather a toolchain one.

Once upon a time, on the PC we only had static compilation, regardless of the language.

.NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.

Re: I’m joining the Go team at Google

#203

Post by johncolanduoni »

pjmlp wrote: post #202
johncolanduoni wrote: post #201

Earlier quoted context omitted.

... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all. I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.

But that isn't a language feature, rather a toolchain one. Once upon a time, on the PC we only had static compilation, regardless of the language. .NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.

Is the .NET stack and tooling any more a language feature? You were happy to argue that tooling was important a moment ago.

In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you listed, but the goalpost shifting is getting ridiculous.

Re: I’m joining the Go team at Google

#204

Post by pjmlp »

johncolanduoni wrote: post #203
pjmlp wrote: post #202

Earlier quoted context omitted.

But that isn't a language feature, rather a toolchain one. Once upon a time, on the PC we only had static compilation, regardless of the language. .NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.

Is the .NET stack and tooling any more a language feature? You were happy to argue that tooling was important a moment ago. In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you…

I am just digressing, sorry if you see it as goalpost shifting.

Re: I’m joining the Go team at Google

#205

Post by candiodari »

aws_ls wrote: post #191
vvanders wrote: post #115

Earlier quoted context omitted.

> 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…

Just to make myself clear, on the point of 'providing a better C'. I just made that comment from language evolution point of view. And did not at all mean that Go is better than C, in all respects. I dare not say that. What I meant was taking a step back to a point before C++ was created. And looking ahead, and choosing what works and is essential (strings, GC,... and some modern Internet usage things...concurrency..…

How do you know this isn't just a new language thing ? All of the advantages you say always result from essentially any redesign, and they never last.

A quote from "Java in a Nutshell", from (I believe, 2002):

"Because Java is a simple and elegant language with a well-designed, intuitive set of APIs, programmers write better code with fewer bugs than for other platforms, again reducing development time."

Reads pretty similar to your argument for Go. I remember similar quotes for Modula-2, ML, (a lot of versions of) LISP, C itself, and I'm sure there's many more. It seems to me pretty likely that we're seeing the same evolution : Go currently is a simple, easy language that matches the current hotness (microservices) pretty well, because it was directly written to support that. The current hotness will go away and Go will have effectively-mandatory bloated libraries to support the next hotness, just like today it's becoming close to embarassing to use Go's standard library's http server for anything non-trivial.

Additionally, many of the criticisms of C apply to Go. It's looooooooooooooooooong simple code doing "a; if error { ... }; b; if error { ... }; c; if error { ... } ...". Many abstractions just don't work, and have to be "fixed" with crutches (like sorting, logging, ...)

Re: I’m joining the Go team at Google

#206

Post by weberc2 »

pjmlp wrote: post #179
_ph_ wrote: post #177

Earlier quoted context omitted.

Of course you can. None of those languages would be in use, if projects could not be managed at all. The question is: are you benefiting from their "features" or are you able to succeed despite of the challenges brought up to you because of those features and their complexity?

It was the simplicity of Java 1.0 that lead to some of the famous patterns we see in some frameworks, that were initially created to workaround language limitations. The same path that is being followed by those that rely on libraries to reduce error handling boilerplate and go generate, just as two examples.

Who is using libraries to reduce error handling boilerplate? I rarely see `go generate` used for things that don't require static code gen (e.g., automatically generating bindings to C libraries). Sounds like you're inventing problems...

Re: I’m joining the Go team at Google

#207

Post by weberc2 »

pcwalton wrote: post #142
weberc2 wrote: post #120

Earlier quoted context omitted.

> You don't have control over what goes on the stack/heap You do have this control. There is escape analysis, but I've never had to dance with it to make it put things on the stack when I need them to. I can get very close to C speeds with Go without much effort.

In that sense, Java and C# both have control too. There are lots of cases in which escape analysis falls down. In particular, higher order control flow (closures/interfaces) will always cause it to fail, until Go implements some sort of higher order control flow analysis (which I doubt it will). Go uses interfaces a lot.

C# doesn't have escape analysis, but it has stack-allocated value types. Java doesn't have stack-allocated value types (yet), but it has escape analysis. It seems a lot harder to me to reason about escape analysis without value types, and I have no idea what happens in C# if you take a reference to a value type (i.e., is it moved to the heap?).

I never meant to imply escape analysis was somehow perfect; only that it is (mostly) easy to reason about.

Re: I’m joining the Go team at Google

#208

Post by weberc2 »

vvanders wrote: post #122
weberc2 wrote: post #120

Earlier quoted context omitted.

> You don't have control over what goes on the stack/heap You do have this control. There is escape analysis, but I've never had to dance with it to make it put things on the stack when I need them to. I can get very close to C speeds with Go without much effort.

Can I say X is a value-type(or better annotate it in declaration)? If not then I don't have that control. Your compiler doesn't know your data access patterns, dataset size or a myriad of other factors that you need to tune if you really want to get full utilization from your hardware. To be clear I'm talking about ~5% of software out there, but when you need it you really need it.

Yes, it has value and pointer types, just like C (except without pointer arithmetic).

Re: I’m joining the Go team at Google

#209

Post by svintus »

dmix wrote: post #155
Jgrubb wrote: post #135

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. St…

> 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 alg…

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.

Re: I’m joining the Go team at Google

#210

Post by aws_ls »

candiodari wrote: post #205
aws_ls wrote: post #191

Earlier quoted context omitted.

Just to make myself clear, on the point of 'providing a better C'. I just made that comment from language evolution point of view. And did not at all mean that Go is better than C, in all respects. I dare not say that. What I meant was taking a step back to a point before C++ was created. And looking ahead, and choosing what works and is essential (strings, GC,... and some modern Internet usage things...concurrency..…

How do you know this isn't just a new language thing ? All of the advantages you say always result from essentially any redesign, and they never last. A quote from "Java in a Nutshell", from (I believe, 2002): "Because Java is a simple and elegant language with a well-designed, intuitive set of APIs, programmers write better code with fewer bugs than for other platforms, again reducing development time." Reads pretty…

Aah, Seeing such a good reply, so late. Does HN need notification? Probably not :-)

So, I agree with you a lot. There are no guarantees that Go will remain good for ever. It would be a challenge and need effort on the part of the language developers.

That said, I believe, when a language evolves over a period of 20 years. You get the benefit of hindsight to introduce the good things in a new language. So, Java's garbage collection is a big success. And Go developers incorporated it. Its a tradeoff with extreme (C like) performance, and devs went with convenience and security. Good call, in my opinion.

But the object oriented part of Java, in my opinion, is just a C++ inheritance, as at that point of time (mid 1990s). OO was the silver bullet, to all your sofware spaghetti problems. But as it turns out, it got more complex, if the design/architecture was bad. And good engineers design good enough without the OO.

So Go has taken that approach, which gels with me and lot other developers.

Your comment regarding the error handling part. Yes, it is cumbersome. But surprisingly, it seems to look better than exception handling when you write couple of modules with it. And for some reason, which others have articulated better than I can at this time, your programs are more stable as a result.

So overall what I like about Go, is the minimalist approach of just having the proven things which are good. And avoiding which are grey area or bad.

Post reply on HN