3 ms·
>> because the maintainers refuse to add any new syntax they now basically cram everything they need into the reflect package. I think they want to try differe
by themihai 10y ago
>> because the maintainers refuse to add any new syntax they now basically cram everything they need into the reflect package.
I think they want to try different avenues before to decide what features to add. Generators("go generate") are used a lot too but they are a pain to develop. Most of them still use templates or print statements instead of specilised packages such go/ast , go/types, go/parser etc to actually generate/print code. Usually you should use reflection to prototype and switch to generators only where the performance is really a big issue or where reflection can't help(i.e define new named types, import/use arbitrary packages/functions)
- eropple 10y agoAlternatively, you build a type system that can express what developers actually need it to express and solve the problem without reflection at all. =)
- themihai 10y agoThat's easier said than done. There are tradeoffs on expressive type systems too. That being said I wouldn't mind more expressivity in the Go type system. I'm actually looking to implement my own small features(i.e optionals, variant types) in a Go superset.
- camus2 10y agoWhere do you think struct tags fit in all this ? do you really think go designers took the time to consider the tradeoffs of such feature ? I don't think so.
- DrJokepu 10y agoAny sufficiently advanced type system is indistinguishable from magic.
- camus2 10y agoBut putting struct tags in Go was a good idea that promote simplicity ... I prefer the magic of generics or pattern matching or covariance to insane features like this, thank you.