3 ms·

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 v

by NateDad 12y ago

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

kxo 12y ago
Are you suggesting the Rust compiler didn't catch that?
- NateDad 12y ago
  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.
  - kibwen 12y ago
    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`"?
    - NateDad 12y ago
      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."
      - kibwen 12y ago
        > 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.
        NateDad 12y ago
        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.
        kibwen 12y ago
        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.
        pcwalton 12y ago
        > 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.
        NateDad 12y ago
        Sorry, yes you mentioned that. Anyway, this is a stupid thing to argue about and I apologize for my part in it.
      - pcwalton 12y ago
        > 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.

by NateDad 12y ago

kxo 12y ago

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

NateDad 12y ago
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.
- kibwen 12y ago
  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`"?
  - NateDad 12y ago
    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."
    - kibwen 12y ago
      > 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.
      - NateDad 12y ago
        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.
        kibwen 12y ago
        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.
        pcwalton 12y ago
        > 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.
        NateDad 12y ago
        Sorry, yes you mentioned that. Anyway, this is a stupid thing to argue about and I apologize for my part in it.
    - pcwalton 12y ago
      > 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.