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