5 ms·
Has Go's interface{} single-handedly confused a generation of software developers, to the extent that they just couldn't understand the language? Is this what h
by grenoire 6y ago
Has Go's interface{} single-handedly confused a generation of software developers, to the extent that they just couldn't understand the language? Is this what happens when languages reach an escape velocity of userbase?
- Thaxll 6y agointerface{} has a performance and security cost.
- nixpulvis 6y agoThat heuristic seems to be changing somewhat, depending on how and where you use those specific characters. It sounds like they plan to make `interface{}` the same as `any` in the type parameters. This makes sense if you forget anything you know about what an empty interface's implications were before, I think. Though I assume all the old reflection tricks are still valid, and potentially dangerous. I didn't read all the discussion, but I wonder if someone is thinking about detecting cases of existing `interface{}` and helping lift it to a generic constraint when possible. Or have I misunderstood something?
- ladberg 6y agoI also haven't read most the discussion, but I'm kinda hoping golint / go vet disallow using the reflection stuff on variables with type parameters. A lot of the design of generics is intended to remove runtime errors (and C++-esque) compile-time errors that require you to inspect the body of a function instead of the function type). Casting a generic would go against that.
- deleted 6y ago[deleted]
- majewsky 6y agoThese are two entirely different concepts: `any` is a compile-time construct, `interface{}` is a run-time construct. At any specific callsite, `any` resolves into one specific type that gets passed at that specific callsite. Buy `interface{}` can hold values of different types at the same callsite.
- nixpulvis 6y agoComment on the issue: https://github.com/golang/go/issues/43651#issuecomment-758867068 https://github.com/golang/go/issues/43651#issuecomment-75886... From the proposal: > However, it‘s tedious to have to write interface{} every time you write a generic function that doesn’t impose constraints on its type parameters. So in this design we suggest a type constraint any that is equivalent to interface{}. Further unification possible: https://github.com/golang/go/issues/33232 https://github.com/golang/go/issues/33232 However I do agree this is making it somewhat confusing what is in a static and what is in a runtime position.
- majewsky 6y agoFrom what you quoted: > we suggest a type constraint any that is equivalent to interface{}. That's my point. They chose the keyword any to disambiguate the type constraint interface{} from the type interface{}.
- grenoire 6y agoThank you for articulating my snark, that's what I was referring to. Had it been called and treated as `any` then it would have made Go much easier and clearer to use.
- nixpulvis 6y agoSome say snark is my native language ;)
- tptacek 6y agoI'm not sure I buy the "security cost" argument.
- dcu 6y agothey mean safety, because using `interface{}` is like using dynamic languages (python, js, ruby, ...)
- tptacek 6y agoI buy the safety argument!
- tedunangst 6y agoOne could argue fat pointers are vulnerable to race conditions in a way normal pointers are not.