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

111–120 of 211 posts

Re: I’m joining the Go team at Google

#111

Post by traverseda »

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…

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

Re: I’m joining the Go team at Google

#112

Post by zzzcpan »

wyattjoh wrote: post #92
the_duke wrote: post #37

Earlier quoted context omitted.

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…

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

Promises and some other higher-order programming without generics are not really usable in Go.

Re: I’m joining the Go team at Google

#113

Post by omginternets »

zzzcpan wrote: post #112
wyattjoh wrote: post #92

Earlier quoted context omitted.

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

Promises and some other higher-order programming without generics are not really usable in Go.

Why would you need, or indeed want promises in Go?

Doesn't a channel/channel-select fulfill this requirement?

EDIT: the answer seems to be downvote. Okay.

Re: I’m joining the Go team at Google

#114

Post by maxlybbert »

pmarreck wrote: post #89
thwd wrote: post #80

Earlier quoted context omitted.

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?

> 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 guaranteed to get them).

Re: I’m joining the Go team at Google

#115

Post by vvanders »

aws_ls wrote: post #98
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…

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

Re: I’m joining the Go team at Google

#116

Post by aninhumer »

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.

While Java may be somewhat verbose, good tooling is not just about "making the language bearable".

Things like being able to jump to a definition, rename it throughout the project correctly and jump back without even thinking about it are hugely valuable in any language.

And maybe you have ways of doing that in your workflow too, in which case great, you too appreciate the value of good tooling.

Re: I’m joining the Go team at Google

#117

Post by sdegutis »

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.

Thanks for your comment. It inspires me to write a blog post on why Java is my new favorite language, especially in comparison to Go.

Re: I’m joining the Go team at Google

#118

Post by dragonwriter »

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…

> 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 other factors weigh in C's favor. For a system that you might be otherwise do polyglot Python (or some similar dynamic language)/C development for that reason (or where you might do C-only somewhat reluctantly for that reason), Go could be a reasonable replacement for C (and, in the case where the alternative would be polyglot, Python or whatever else.)

Re: I’m joining the Go team at Google

#119

Post by knocte »

javajavaj wrote: post #110
pmarreck wrote: post #63

Earlier quoted context omitted.

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?

Dave Cheney gave a talk about error handling in Go that sheds some light on how the Go community thinks about errors: https://www.youtube.com/watch?v=lsBF58Q-DnY

Wow, that talk just demonstrates that all downsides about error handling in Go are due to its lack of exceptions (at least how they work in languages like C#). It's a step backwards, it's ludicrous.

Re: I’m joining the Go team at Google

#120

Post by weberc2 »

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…

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

Post reply on HN