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

I Love Go; I Hate Go

dtrace.org

Post reply on HN
Print view View original

91–100 of 329 posts

Re: I Love Go; I Hate Go

#91

Post by eloff »

oolongCat wrote: post #44
eloff wrote: post #40

Earlier quoted context omitted.

Bikeshedding much? I can't see this being a real problem. There are a lot of other decision that the Go team made, for better or for worse that have much greater effects on real code. Unused imports is a joke. var _ = unusedImport Or use goimports. Then you don't even have to think about it.

>Then you don't even have to think about it. Can't agree with that. We once had an issue with our code because someone had made a copy of his code base and goimports was importing an older version of a library. Yes definitely this is something the programmer could have prevented. BUT! "not think about it" is not really true.

Ok. Effectively don't have to think about it 95% of the time then. Close enough.

Re: I Love Go; I Hate Go

#92

Post by vertex-four »

dpc_pw wrote: post #49

Oh. Go love-hate relationship post. My turn. So I really like channels and coroutines built into language and used everywhere: it makes some patterns compose nicely and language very productive. But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provide…

I think that a lot of people who like Go for its channels/coroutines would like one of the BEAM VM languages - Erlang or Elixir - with its OTP. It's a bit more heavyweight, and the community is a bit smaller than Go's, but it works nicely for lots of sorts of problems.

I'd keep using Go for one-off scripts (grab SSH keys from LDAP for sshd, that sort of thing) and system integration stuff, though.

Re: I Love Go; I Hate Go

#93

Post by junke »

sagichmal wrote: post #84
wruza wrote: post #35

Earlier quoted context omitted.

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

> There are two phases: active development and release > engineering. For you, perhaps. Go encourages you to think about your problem and develop it in the "release engineering" style from the very beginning. This is a virtue of the language, in my view.

Ada is probably the most real-software-engineers-dont-hack language ever designed, and yet compilers have flags to control checks and warnings.

Re: I Love Go; I Hate Go

#94

Post by microtonal »

nneonneo wrote: post #74
millstone wrote: post #55

Earlier quoted context omitted.

> How do you decrement an atomic in Go? Ooh. How do you delete from a slice in Go? With append() of course! http://stackoverflow.com/questions/25025409/delete-element-i...

That solution (append(a[:0], a[1:]...)) doesn't look remotely performant. I don't have a copy of go handy to test, but exploding most of the list into individual arguments and passing them to a variadic function, just to pack them all back into an array, seems quite circuitous to me. Is that really the _best_ way to delete from a slice in Go?

It doesn't explode the slice:

If the final argument is assignable to a slice type []T, it may be passed unchanged as the value for a ...T parameter if the argument is followed by .... In this case no new slice is created.

https://golang.org/ref/spec#Passing_arguments_to_..._paramet...

(Otherwise, I completely agree that having to use append to remove an element is stupid.)

Re: I Love Go; I Hate Go

#95

Post by xyproto »

millstone wrote: post #38
tptacek wrote: post #29

Earlier quoted context omitted.

I used to feel this way. It was my top complaint about the language. But it, and, more importantly, the use requirement for variables, has saved me from bugs repeatedly; I more and more notice the bugs it's protecting me from as I keep coding in the language. I am rapidly coming to the conclusion that this was very, very much the right call. I get the sense that most Go programmers use "goimports" to work around the…

Oftentimes when I write in Go, I'll produce an unused variable as a side effect of commenting out code as a debugging experiment. What would you think about Go issuing a warning instead of an error in this case? Also, if goimports solves import issues, why isn't it just built into the compiler?

This is a problem specifically about commenting in and out code. The IDE should comment in and out imports accordingly.

Re: I Love Go; I Hate Go

#96

Post by EugeneOZ »

> Contrast this with Rust whose errors read like mind-bindingly inscrutable tax forms.

It was "lol what?" for me. Rust's compiler error messages are very informative and sometimes contains tips what to change in your code to make it work (not just general words, but code you can use right now, with your variables/functions etc.).

Borrow checker explains step-by-step where ownership starts, where it ends and where you are trying to use it.

Panicking messages - another story, but it's not compiler's error messages, it's runtime. In example of code Adam using as proof, author is using 'panic' and 'unwrap' - reasons to don't expect gentle behavior.

If you can't write code in idiomatic way, try to catch your panics and give more descriptive runtime error message in your code - other users of language shouldn't pay for it.

Re: I Love Go; I Hate Go

#97

Post by ckastner »

laumars wrote: post #87
wruza wrote: post #35

Earlier quoted context omitted.

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

> Stockholm syndrome in action. That's a very negative way of saying "that's not my personal behavioral preference" > There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghett…

>> Stockholm syndrome in action.

>That's a very negative way of saying "that's not my personal behavioral preference"

In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive.

In the grandparent's own words:

>>> i was shocked by that at first too. Then I came to love it.

Re: I Love Go; I Hate Go

#98

Post by valarauca1 »

EugeneOZ wrote: post #96

> Contrast this with Rust whose errors read like mind-bindingly inscrutable tax forms. It was "lol what?" for me. Rust's compiler error messages are very informative and sometimes contains tips what to change in your code to make it work (not just general words, but code you can use right now, with your variables/functions etc.). Borrow checker explains step-by-step where ownership starts, where it ends and where you…

This was where I stopped reading. The author clearly hasn't worked with Rust. Not only are the messages very descriptive, but you have an extended explaination for each error in the form of:

    rustc --explain EXXX
Which pulls up a long form explaination, and code samples of what is happening/why it is happening/how to fix it.

The blog explaining the author's disdain for Rust mostly just seems to whining about the borrow checker.

Re: I Love Go; I Hate Go

#99

Post by junke »

laumars wrote: post #87
wruza wrote: post #35

Earlier quoted context omitted.

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

> Stockholm syndrome in action. That's a very negative way of saying "that's not my personal behavioral preference" > There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghett…

> Except it does though, since that's the very behaviour you're complaining about.

No, the meaning was: if someone cannot handle unused things, that someone is screwed. Go will not save him in other aspects which require a little bit of discipline and are not checked by the compiler.

Re: I Love Go; I Hate Go

#100

Post by philh »

eloff wrote: post #40
_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

Bikeshedding much? I can't see this being a real problem. There are a lot of other decision that the Go team made, for better or for worse that have much greater effects on real code. Unused imports is a joke. var _ = unusedImport Or use goimports. Then you don't even have to think about it.

(I've never used Go, so please correct any errors.)

> var _ = unusedImport

This is what the devs suggest as an alternative to having a compiler flag to turn off the check.

But with a compiler flag, I can easily discover the unused import when I build for production, simply by turning that flag off. By using the variable in a dummy way, I need to remember to go back and check for such things.

Presenting this as a way to address the problem feels like it's missing the point.

Post reply on HN