Live data from Hacker News

I Love Go; I Hate Go

dtrace.org

121–130 of 329 posts

Re: I Love Go; I Hate Go

#121

Earlier quoted context omitted.

> The author clearly hasn't worked with Rust. The author links to a previous post on the subject, from mid-2015, so they clearly have at least tried Rust in the past. And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good). Here's a clearer example (fixed since): http://dbeck.githu…

So are you talking about error messages or about complexity of borrow-checker? Because I can agree about borrow-checker, but not about error messages (although there is a lot of noise, yes).

> So are you talking about error messages or about complexity of borrow-checker?

Er… both? In separate sections of the comment?

> Because I can [not agree] about error messages

I've provided a clear example of an issue, are you denying objective reality or are you asserting that providing incorrect suggestions leading beginners in entirely the wrong direction is fine?

Re: I Love Go; I Hate Go

#122
I have great hopes for D since Andrei Alexandrescu joined to work on it.

When you see all those new system languages, (go, rust, swift), D was there before them, and did not pretend to be a new cool thing with good ideas, it just tries to be a nicer C++ to work with.

I don't need to do things the right way, I just need a language that is usable and doesn't try to do the job for me.

Re: I Love Go; I Hate Go

#123

Earlier quoted context omitted.

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

> You are trying to catch on words

No. I'm clearly replying to a clear opinion, there's no catch although I might be exaggerating very slightly.

> but it's just not true.

What is not true?

> I went my way from the 0-noob in Rust to comfortable using and I can say compiler errors were always helpful.

That's got nothing to do with the comment you're replying to.

Re: I Love Go; I Hate Go

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

For your unit-testing problem, I highly recommend `testify/assert`:

https://godoc.org/github.com/stretchr/testify/assert

Re: I Love Go; I Hate Go

#125
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 think that's the thing that really gets me about Go. I really like that it's opinionated and forces you to write good code, but I just can't understand why they refuse to allow you to turn them off when you need it.

Also doesn't that workaround completely nullify all the arguments they made in that section? And it puts the programmer in a worse position than if they could just turn it off temporarily.

Re: I Love Go; I Hate Go

#126
post #100
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.

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

In practice you don't really have this problem. It's a beginners issue thst's not worth "fixing" because there are tools that can help(goimports). I'm glad there are not such compiler flags.

Re: I Love Go; I Hate Go

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

> ignoring years of research and good ideas And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least prete…

> Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc.

I find some of those strengths and others shine in a small team of strong developers too, if they "get" Go.

But to your point: some people expect their startups to eventually employ a large number of programmers, at which point they will inevitably have some mediocre ones, that being a side effect of "hiring only the best."

Planning for that day is not shooting yourself in the foot.

Re: I Love Go; I Hate Go

#128

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?

A slice is a view over a continguous array. deleting an index in a continguous array is inherently O(n). Go doesn't obscure this. The pain of writing it out reflects the complexity of the operation.

Re: I Love Go; I Hate Go

#129

Earlier quoted context omitted.

What about just really obnoxious compiler warnings that can't be disabled?

More than once I've built some free software from source, only to witness literally thousands of warnings being spit out during the compile phase.

I would argue that that's becuase checks had to be enabled not because they could be disabled.

Re: I Love Go; I Hate Go

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

Do you find using pub/extern keywords more elegant than a simple capitalization? To me rust is verbose in many cases like java with a lot keywords heading towards C++ complexity which is exactly what Go tries to avoid. I understand that now crago becomes somehow part of the language as the extern declarations will become "optional"/deprecated. So yeah, I hope Go won't adopt any of these fancy/XXI century features.
Post reply on HN