Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No. I suppose, maintainers of popular open source projects couldn't justify introducing generics into their code. This is exactly my story - I was actively seeking places in VictoriaMetrics codebase, which could benefit from switching to generics. Unfortunately, not a single place has been found yet. There was a promising place for generics [1], but it has been appeared that it is better from readability and maintainability PoV to use plain old interfaces instead.

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...



Tacking on generics on a working code base is difficult.

I effectively used it in this little experimental CLI library: https://github.com/cpuguy83/go-cli/blob/main/command.go

It's pretty simple, but the nice thing is it can use any flag library you want (stdlib flag package, pflag, whatever).


Try substituting F generic type with the FlagSet interface - and the code will become more clear without the need to use generics.


That totally changes it as it requires type assertions to use. With generics `Flags()` returns a concrete type and not an interface.


The question is whether the Flags() should return the concrete type instead of FlagSet interface? Another question is whether the additional complexity related to generics worth the ability to get the concrete type from Flags()?

In fact, the generic-free implementation based on the FlagSet interface is more flexible, since it allows storing multiple different FlagSet implementations in the same Cmd.


I mean the generic type def there could be changed such that different Cmd's can have different flag implementations.

The main point is that generics come in handy when building libraries so that you aren't forcing callers of your library into specific types or loosing some type safety.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: