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

131–140 of 211 posts

Re: I’m joining the Go team at Google

#131

Post by vvanders »

dragonwriter wrote: post #118
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…

> Go is not a C replacement/better C. Its not a replacement for C in most of the places where C is far and away the best existing choice for a whole project, it is a replacement for C in the zone where C's performance and static typing are attractive and would decided the choice in its favor, but Python's expressiveness, batteries-included stdlib, etc. also make it attractive and make it a little bit painful that the…

Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's performance in any of those languages.

If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.

Re: I’m joining the Go team at Google

#132

Post by eternalban »

jerf wrote: post #66
coldtea wrote: post #31

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

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

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.

Re: I’m joining the Go team at Google

#133

Post by pjmlp »

vvanders wrote: post #115
aws_ls wrote: post #98

Earlier quoted context omitted.

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

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

If the constrained hardware is more powerful than a Xerox PARC Dorado (Mesa/Cedar), a ETHZ Ceres Workstation (Oberon), DEC Firefly (Modula-3), then Go is certainly a better C.

Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed.

In spite of lacking a few features that I consider any modern language should have, ability to create memory friendly data structures isn't one them.

Re: I’m joining the Go team at Google

#134

Post by rpeden »

javajavaj wrote: post #107
gravypod wrote: post #77

Earlier quoted context omitted.

I think as developers we are so used to pain that we forget how "easy" development can be if we allow people the right tools. If any language had the tooling and development Java did it would hold the market share. It's my opinion that if Rust makes a similar IDE experience (even just using Eclipse's platform) with every feature like code completion, formatting, debugging, the hole 9 yards and integrate Cargo into it…

That you need an IDE to make a language bearable speaks volumes to the design of the language. Go is doing well because it realizes we can strip so much away, stay with the standard lib, and get real work done quickly. That's not to say that Java, in particular the JVM, isn't an impressive piece of engineering, but more that we should be careful when we choose our tools so as to not overly complicate things.

Rather than looking at it as a language that needs an IDE to be bearable, it might be more helpful to look at it as a language that is most pleasant to use in concert with well build tools.

I look at it similarly to the way I look at Smalltalk. It's possible to use it as just a series of text files (with GNU Smalltalk), but using it with tools that understand the language (such as Visualworks or Squeak/Pharo) turns it into a very different experience.

I know that a Smalltalk dev environment feels alive in a way that Java doesn't, but using Java with a tool like IntelliJ is a nice experience. Using something like JRebel or HotSwapAgent to swap code changes into a running application also improves the dev experience significantly.

Re: I’m joining the Go team at Google

#135

Post by 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.

Re: I’m joining the Go team at Google

#136

Post by pmarreck »

microtonal wrote: post #103
Conlectus wrote: post #101

Earlier quoted context omitted.

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…

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 tl;dr, it's very easy to accidentally ignore errors in functions that are side-effecting or modify parameters. Been there, done that.

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?

Re: I’m joining the Go team at Google

#137

Post by jnordwick »

howeman wrote: post #78
jnordwick wrote: post #19

Earlier quoted context omitted.

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.

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

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.

Re: I’m joining the Go team at Google

#138

Post by pmarreck »

maxlybbert wrote: post #114
pmarreck wrote: post #89

Earlier quoted context omitted.

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

> > 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. You get stack traces in Java, C#, Python, etc. You don't get them in C++ (well, you aren't g…

But you agree that a stack trace is a tool to mentally reconstruct (read: "realign") your mental model of the state the code produces, with what really happened?

Re: I’m joining the Go team at Google

#139

Post by jnordwick »

Vendan wrote: post #20
jnordwick wrote: post #19

Earlier quoted context omitted.

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.

note that new() already exists in the language.

Yes, and make() is completely superfluous. make() and new() can be completely rolled into one piece of syntax without ambiguity because they are the same thing.

Re: I’m joining the Go team at Google

#140

Post by AnimalMuppet »

bsdetector wrote: post #88
junke wrote: post #79

Earlier quoted context omitted.

Ignoring on purpose is fine. The problem is when the only return value is an error which can be ignored simply by not assigning the result to a variable. Forcing the user to do: _ = f.Close() ... in order to explicitly ignore the error would be nicer, but then, there are many functions which are known to never be checked for their errors, like fmt.Println. That's why the typical advice is to use errcheck, which has f…

> functions which are known to never be checked for their errors, like fmt.Println In Java println is checked for errors, as it should be. Every Java program that does println either aborts or deals with the error in some way. It matters. Take any program that writes to stdout and run it with ">&-" to close stdout. Because of unix, the next file it opens will be file descriptor 1 and the program will start writing th…

And the cynic in me says that, if you do that with a program that handles the password file, you almost deserve what you're going to get...
Post reply on HN