Live data from Hacker News

I’m joining the Go team at Google

spf13.com

121–130 of 211 posts

Re: I’m joining the Go team at Google

#121

Earlier quoted context omitted.

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.

Sure, agreed, but I think you misunderstand my point. If I took away your Java IDE would you be able to get very far?

Re: I’m joining the Go team at Google

#122

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…

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

Re: I’m joining the Go team at Google

#125
post #64
post #54

Earlier quoted context omitted.

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.

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

Think of all the hours you save not having to work around the misfeatures available out of the box in other languages. I know, you don't make mistakes or use those nasty features, but think of your coworkers.

Re: I’m joining the Go team at Google

#126
post #64

Earlier quoted context omitted.

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

Think of all the hours you save not having to work around the misfeatures available out of the box in other languages. I know, you don't make mistakes or use those nasty features, but think of your coworkers .

My coworkers are savvy enough to handle those features.

Re: I’m joining the Go team at Google

#128

Earlier quoted context omitted.

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

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.

I'm not going to say categorically that you never need a debugger...

But, I've been working with Go for years and have never used a debugger. I don't feel like I'm missing out on anything.

Re: I’m joining the Go team at Google

#129

Earlier quoted context omitted.

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.

I'm not a Java developer, so I'm interested to know what the amazing parts of IntelliJ are. When I look at it it just looks like they ripped off the skin from Sublime Text and it has some debugging features that are readily available in other editors. I get pretty much everything on https://www.jetbrains.com/idea/whatsnew/ in my vim setup.

All the refactorings and context-aware code completion, for starters. And as for ripping off, IntelliJ came out 7 years before Sublime Text.

Re: I’m joining the Go team at Google

#130
post #78

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

[deleted]
Post reply on HN