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

111–120 of 329 posts

Re: I Love Go; I Hate Go

#111

Post by sagichmal »

junke wrote: post #99
laumars wrote: post #87

Earlier quoted context omitted.

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

This is literally the "perfect is the enemy of the good" fallacy.

Re: I Love Go; I Hate Go

#112

Post by EugeneOZ »

masklinn wrote: post #106
nutheracc wrote: post #102

Earlier quoted context omitted.

Yes, agreed, the Rust error messages are very helpful. Failure to understand the messages is a lack of familiarity with Rust, not a problem with the error messages.

> Failure to understand the messages is a lack of familiarity with Rust You could have said the exact same thing of G++'s pages of template error messages. That's indictment not praise. If you must be highly familiar with the language to understand the compiler's error messages you might as well remove the messages altogether and just print "?" as ed(1) does, developers familiar with the language obviously don't need…

You are trying to catch on words, but it's just not true. I went my way from the 0-noob in Rust to comfortable using and I can say compiler errors were always helpful. Always. From the very beginning of my journey.

Re: I Love Go; I Hate Go

#113

Post by nindalf »

thewhitetulip wrote: post #63
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…

>and all my contacts with the community were very unpleasant I can testify to this! I even got banned from the golang subreddit :-D EDIT: I didn't bully anyone or anything, just told them that they can't call the language as golang, because when I had asked feedback on my work an year ago, the only feedback I got from a certain person and that too very rudely was "to not call the language Golang and call it Go, ruby…

> > all my contacts with the community were very unpleasant

> I can testify to this

Even though you showed up on the golang subreddit, asked a question about javascript [1], got two answers (one without jquery, one with), you can attest to the unpleasantness of that subreddit? Even when you posted your todo manager written in Go, the majority of the feedback you got was positive.

I find your reaction a little surprising.

[1] - https://www.reddit.com/r/golang/comments/44g3ln/help_require...

Re: I Love Go; I Hate Go

#115

Post by matthewmacleod »

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?

Unfortunately yes. It's a great example of the sort of thing that Go does pretty badly in my experience – even though it's idiomatic, and technically performant behind the scenes, it looks immediately confusing and slow.

Re: I Love Go; I Hate Go

#116

Post by MaulingMonkey »

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

Bad macro matches can sometimes result in some rather obtuse error messages, and the exact root cause of some of the type mismatch errors can also be relatively obtuse - at least to a beginner.

Still way better than C or C++'s though, I suspect. (I'm too fluent in C++ errors to have a proper feel for how bad they are anymore...)

Re: I Love Go; I Hate Go

#117

Post by matthewmacleod »

_ph_ wrote: post #103
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...

If the order of the elements in a slice does not matter, this should be the easiest solution for deleting the element "n": slice[n] = slice[len(slice)-1] slice = slice[:len(slice)-1] Probably one should campaign for adding a delete operator to slices, though so far I have never missed it.

This is a great example of the sort of thing that frustrates me when I'm using Go. Deleting an element from a slice is an obvious, common, simple operation. In order to do this, I have to build that operation from primitives, despite the fact that it will be more error-prone to do so. There are lots of other annoyances like this, too.

Re: I Love Go; I Hate Go

#118

Post by Onewildgamer »

nutheracc wrote: post #102
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…

Yes, agreed, the Rust error messages are very helpful. Failure to understand the messages is a lack of familiarity with Rust, not a problem with the error messages.

To me, an error message should help in understanding the language better. It shouldn't impose a requirement to have the knowledge beforehand.

Re: I Love Go; I Hate Go

#119

Post by EugeneOZ »

Onewildgamer wrote: post #118
nutheracc wrote: post #102

Earlier quoted context omitted.

Yes, agreed, the Rust error messages are very helpful. Failure to understand the messages is a lack of familiarity with Rust, not a problem with the error messages.

To me, an error message should help in understanding the language better. It shouldn't impose a requirement to have the knowledge beforehand.

Each compiler error message in Rust have special code, using it you can find article with detailed explanation how things work, targeted to beginners.

Re: I Love Go; I Hate Go

#120

Post by valarauca1 »

MaulingMonkey wrote: post #116
valarauca1 wrote: post #98

Earlier quoted context omitted.

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

Bad macro matches can sometimes result in some rather obtuse error messages, and the exact root cause of some of the type mismatch errors can also be relatively obtuse - at least to a beginner. Still way better than C or C++'s though, I suspect. (I'm too fluent in C++ errors to have a proper feel for how bad they are anymore...)

Macro errors are horrible, especially in match branching. They also become really nonsensical when you deal with built in macro's as well which have a completely different set of rules for themselves.

Iterator errors as well get massive when dealing with passing tuples down lazy lists.

Post reply on HN