5 ms·
No more complaining about lack of generics, yeah! But you will still have people complaining about error handling in every single discussion about Go
by dgellow 5y ago
No more complaining about lack of generics, yeah! But you will still have people complaining about error handling in every single discussion about Go
- rob74 5y agoPeople who are looking for reasons to complain will always find more than enough - in Go and any other language too...
- throwaway894345 5y agoI guarantee we will still hear about how long it took them to add generics to the language and how the language is only popular because of “massive Google marketing campaigns” and how the language is “stuck in 1970” and so on for years to come. People who make silly criticisms aren’t likely to be pacified, and I don’t think generics will make people less upset that Go is eating into their language’s marketshare.
- lowmagnet 5y agoI've been using Go since maybe 1.4 and that's only 7 years ago. I started using it as my main language around 2016 or so. I knew people complained about generics and wanted them myself, but the ease of using this language have far outweighed any complaints I've ever had about generics or comma-error or comma-ok patterns that have evolved out of the core design. I would love some of the proposals surrounding errors to move forward, of course. But I'm OK with the current state, and will be happier with 1.18.
- latchkey 5y agoOk then... how about something easier... for bar := range list { }
- Joker_vD 5y agoAnd of course "list" is defined as []int, so you get really peculiar results.
- latchkey 5y agoMy all time favorite. https://golang.org/doc/faq#closures_and_goroutines https://golang.org/doc/faq#closures_and_goroutines
- amelius 5y agoThis caveat exists in every language that supports closures, afaict.
- 5e92cb50239222b 5y agoSome… cough… oxidized languages prevent you from doing stupid shit like that. But apparently those languages are too complicated, I'd rather not rely on compiler helping me and keep yet another rule in my head as I'm writing code.
- heheheheheeh 5y agoEven if it didnt, I'm sure you'd be able to realize your mistake while you wait 6-8 weeks for you code to compile.
- roblabla 5y agoErr, no? Most languages will make a copy for scalar values (e.g. ints), e.g. Javascript and python do that. C++ and Rust go further and provide the user the ability to take the arguments by value or reference, even for classes/structs, which gives you control over what you want. And in this specific case, `v` should be a new instance for each iteration really, it makes very little sense to say that a reference to v of a previous iteration of the loop stays alive for the next iteration. Which is why the program as it exists would be a compile time error in rust, for instance (Maybe in C++ as well, I'm not well-versed enough in the lambda rules of C++).
- jhgb 5y agoWhat does this have to do with values or references? They are orthogonal to scopes, and this example is an issue of scoping. A closure finds free variables in one of its enclosing scopes. If the for loop creates one mutable binding for its control variable, even multiple closures created within the loop's body can all see this single mutable binding because they all share the single environment with this mutable binding in which all of them were created, so they can all observe this binding mutating over time. There are no "arguments by value or reference" because the closure in the example is nullary -- it has no arguments at all.