Hacker News Reader

Comment by steveklabnik | Hacker News Reader

You need a collect on that first example, you end with a Vec<uint> in the second, but an Iterator<something> in the first.

View on HN

Oops, you're right. Fixed.

And that's why I like go.

Sorry, that's not really fair. I'm sure the compiler would have caught that when you tried to feed it into something that wanted a vector (or would have not cared if you were just iterating over it).

To be honest, I think Rust has a lot going for it. I just think Go has a lot going for it too... they're just different things. Which is fine, because if everything were the same, the world would be a really boring place. :)

Are you suggesting the Rust compiler didn't catch that?

No? I don't actually know rust, but I don't think the first thing he typed was invalid code. It just returned an iterator instead of a vector. I was suggesting that when he tried to pass the variable into a function that expected a vector, the compiler would complain. No snark, I just meant what I said.

To be fair, the line "And that's why I like go" seems to imply that Go is able to keep you from making errors in untested context-free code snippets. Perhaps you meant "and that's why I like that Go doesn't support operations like `map`"?

Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason.

The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period of time.

It's not that I like that Go doesn't have map, per se. I just don't miss it. At all. And the fact that it's not in the language means I don't have to read someone else's use of it and try to make sure they're not screwing it up somehow. A wise man once said "It's not that I don't want generics, I just don't want you to have generics."

  > Go does help prevent errors in untested context-free code 
  > snippets... by being really really simple, and not trying 
  > to mash a ton of logic into a single line for no reason.

But there is an example in this very thread of a manually-implemented map-via-a-for-loop from a well-meaning Go user that accidentally underflows into an infinite loop.

This isn't an attack on Go (which I respect as a language for having the temerity to be opinionated, a facet that more languages need to emulate), merely bafflement at your claim that implementing everything anew via bespoke loops is somehow effective at reducing errors.

Yes and that was a carefully constructed example explicitly to show problems with loops.... But underflows in loops are just not a common occurrence, which is why the example works in the first place.

Likewise, forgetting a `.collect()` call in Rust code doesn't happen, because the compiler will tell you without fail when it's given an iterator but expects an array.

> Yes and that was a carefully constructed example explicitly to show problems with loops

No, it was an example from my experience and a bug I have had to fix multiple times, as I mentioned. I didn't make it up.

Sorry, yes you mentioned that. Anyway, this is a stupid thing to argue about and I apologize for my part in it.

> Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason.

Sorry, I don't see the benefit of "preventing errors in code that's never actually executed" as a design goal.

> The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period of time.

I just demonstrated a counterexample in this thread.

Reply on news.ycombinator.com