Live data from Hacker News

I Love Go; I Hate Go

dtrace.org

41–50 of 329 posts

Re: I Love Go; I Hate Go

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

>>But it, and, more importantly, the use requirement for variables, has saved me from bugs repeatedly; So how is it better than C where you get a warning (at least from GCC) that you have unused variables? You can quickly test things and you are coming back to fix all the warnings later anyway.

You get warnings for lots of things in C. There's no getting around the use requirement in Go, at least not without crudding up your code.

Re: I Love Go; I Hate Go

#42
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?

It doesn't work as a language feature, because it's not precise or perfect. Package references can be ambiguous, and need to be overridden. It works extremely well as a tool though.

Re: I Love Go; I Hate Go

#43
post #34
post #33

I'm a little confused by the author's belief Go needs to be more pragmatic. All the points made in the "I Love Go" section (gofmt, the toolchain, interfaces) display strong qualities of pragmatism to me. The article literally describe interfaces as 'no-nonsense and pragmatic'. And, even if they do not personally like the opinionated nature, it is a prime example of solving questions in a practical way. No language ca…

>It's very clear to me when to write Go and when not to. Would you care to elaborate on this? :)

My main two use cases so far have been services and command line tools where it's not worth taking the effort to manage memory. The former I would have previously written in Java or C# (yeah, tie me to the cross right now language hipsters, I don't care, I already said I'm a pragmatist), and the latter in Ruby or Python.

I actually enjoyed going from dynamic to static typing for command line tools, the compiler saves me a lot of time tracking down bone-headed errors, which are typos in variables 95% of the time.

Re: I Love Go; I Hate Go

#44
post #40
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.

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

Re: I Love Go; I Hate Go

#45
post #25

Honest question: How does a post with just 4 points and posted 11 minutes ago get to be on the front page? Even amazing it is number 2 right now.

That's normal. I'm a nobody (to answer the accusation below) and my submissions of articles that are years old and not recognizably "hot" make it to the front page with only three to five upvotes all the time. Quick upvotes or comments count for a lot.

When I saw it on the front page, it had only 4 votes. How can that count for anything?

Re: I Love Go; I Hate Go

#46
post #31

Honest question: How does a post with just 4 points and posted 11 minutes ago get to be on the front page? Even amazing it is number 2 right now.

Besides other points mentioned, I think HN crowd has a love/hate relationship with Go (the other one I noticed is Python), so it's natural to go up quite fast.

Sure, but it had only 4 votes and it was second on front page

Re: I Love Go; I Hate Go

#47
post #29
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…

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…

> I get the sense that most Go programmers use "goimports" to work around the annoyance. I have my Emacs configured to use it automatically. I never even think about imports anymore.

You haven't yet encountered clashing names?

https://golang.org/pkg/crypto/rand/

https://golang.org/pkg/math/rand/

Or?

https://golang.org/pkg/text/template/

https://golang.org/pkg/html/template/

goimports is wonderful, but some care is needed to make sure it has added the one you intended to add.

NB: Only an issue when new imports are added, not an issue if the correct package is already referenced.

Re: I Love Go; I Hate Go

#48
post #25

Earlier quoted context omitted.

That's normal. I'm a nobody (to answer the accusation below) and my submissions of articles that are years old and not recognizably "hot" make it to the front page with only three to five upvotes all the time. Quick upvotes or comments count for a lot.

When I saw it on the front page, it had only 4 votes. How can that count for anything?

Four upvotes in the first minutes are absolutely a strong signal.

Re: I Love Go; I Hate Go

#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 provides no improvements. No `try!`&`Result` like Rust, not even warning by default if you ignored returned error (IIRC, go lint or go vet checks it) . So what's the point?

How do you decrement an atomic in Go?

AddUint32(&x, ^uint32(c-1))

That's how. Easy to read, and self-explaining. https://golang.org/pkg/sync/atomic/ . I mean... come on.

Unused errors being an error is super annoying, and changing variable capitalization everywhere, because you want to change symbol visibility is another daily frustration source.

Oh, and all my contacts with the community were very unpleasant (maybe it's just me, or bad luck). Any questions ended with some form of "you must do it one true way, otherwise you're stupid". Eg. once I was looking for a way to terminate unit test in case of error, instead of writing `if err != nil { t.Errorf(...) }` over and over again after every line, as in test, every error is just terminating condition. In Rust I would just `.unwrap()` or `.expect()`, which would fail the test, report backtrace, etc if anything unexpected went wrong. All the help that I got was just snarky comments for being lazy.

I will continue to use Go in some projects, as it gets the job done, performance is OK, has some userbase, and ecosystem is quite vital, but overall, it seems to me that it's rooted in same form of stubborn crudeness that has no good reason in XXI century, ignoring years of research and good ideas. For anything more demanding, or fun I would always go with Rust.

Re: I Love Go; I Hate Go

#50
post #29
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…

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…

"But it […] 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 […] most Go programmers use "goimports" to work around the annoyance. I have my Emacs configured to use it automatically. I never even think about imports anymore."

If you don't think of imports anymore, how can they save you from bugs?

(I do (somewhat) understand the "more importantly, the use requirement for variables" part, but also there, I think a warning should be sufficient. Your editor could/should color-code dead code, anyways, making it stand out before you compile)

Post reply on HN