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

71–80 of 211 posts

Re: I’m joining the Go team at Google

#71

Post by johncolanduoni »

coldtea wrote: post #33
favadi wrote: post #15

Earlier quoted context omitted.

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

How it is a balance if expressiveness suffers?

I guess the claim is that any more expressiveness would necessitate losses in readability or simplicity that the expressiveness doesn't make up for.

Personally, I think you're sense of relative value of those has to be pretty unusual to thinks it's "perfect". Though valuing simplicity above almost everything else is what's written on the tin with Go.

Re: I’m joining the Go team at Google

#72

Post by squeed »

Touche wrote: post #62
squeed wrote: post #8

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

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

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.

Re: I’m joining the Go team at Google

#73

Post by johncolanduoni »

rebeccaskinner wrote: post #34
jnordwick wrote: post #18

Earlier quoted context omitted.

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

> It is pretty readable, but really non-functional too There are projects starting to fix that: https://github.com/asteris-llc/gofpher

I think he meant non-functional in the sense of "not functioning", not functional programming. Neither of his immediately following complaints have anything to do with functional programming.

Re: I’m joining the Go team at Google

#74

Post by pmarreck »

Kubuxu wrote: post #50
pmarreck wrote: post #45

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.

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.

Finally, someone who's had the same experience i have had and which i got downvoted for!

Re: I’m joining the Go team at Google

#75

Post by pmarreck »

pjmlp wrote: post #69
pmarreck wrote: post #65

Earlier quoted context omitted.

If WPF was designed from the get-go using TDD, there would be less of a problem here in this case. I myself have hardly ever needed a debugger in any code i've worked on that has been TDD from the ground up. And it is almost ALWAYS related to OTHER code that was clearly not written with TDD in mind. Tell me something: What exactly is a "bug"? It is literally just a state the programmer did not expect, correct? So how…

I am yet to see TDD work with native GUIs.

http://stackoverflow.com/questions/382946/how-to-apply-test-...

It's possible, and it works. Read the topvoted comment there and follow its links.

Re: I’m joining the Go team at Google

#76

Post by pjmlp »

pmarreck wrote: post #75
pjmlp wrote: post #69

Earlier quoted context omitted.

I am yet to see TDD work with native GUIs.

http://stackoverflow.com/questions/382946/how-to-apply-test-... It's possible, and it works. Read the topvoted comment there and follow its links.

"This approach removes the GUI layer from TDD and unit testing. It does not mean the GUI is never tested but just acknowledges that it is not cost effective to pursue automated GUI testing, particularly as part of TDD. Integration and user testing should cover the GUI."

Hence, not tested at all via TDD.

Re: I’m joining the Go team at Google

#77

Post by gravypod »

sdegutis wrote: post #57
gravypod wrote: post #43

Earlier quoted context omitted.

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

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 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 they'll win. But, here's the caveat: It needs to be FLAWLESS integration.

I've been a java developer for my entire programming career. Java was my first language when I was 12 and I'm 19 now. I still can't use javac without looking at a compiler guide since I never use it. Eclipse does the business and I don't ever even need to think about what's going on outside my code. Not once.

Re: I’m joining the Go team at Google

#78

Post by howeman »

jnordwick wrote: post #19
XorNot wrote: post #12

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

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

Re: I’m joining the Go team at Google

#79

Post by junke »

aninhumer wrote: post #59
thwd wrote: post #53

Earlier quoted context omitted.

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.

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.

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 filters to avoid "false"-positives (I am not convinced that some function never should be checked for errors).

Re: I’m joining the Go team at Google

#80

Post by thwd »

pmarreck wrote: post #63
thwd wrote: post #53

Earlier quoted context omitted.

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.

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?

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?
Post reply on HN