3 ms·
> func (o Option[T,U]) Map(f func(a T) U) Option[U] { ... } I love GO and it's simplicity and yes I do want generics, but is it just me or is this reading mu
by rawoke083600 5y ago
> func (o Option[T,U]) Map(f func(a T) U) Option[U] { ... }
I love GO and it's simplicity and yes I do want generics, but is it just me or is this reading much much harder now ? It reminds me of those ugly voidfuncptr signatures of C and C++ :(
Maybe my eyes should just get used to it but I do feel a little my simple Go now reads not as easy. YMMV
- tgv 5y agoPersonally, I think that Rust's Option and Result are not well suited to Go. Option may serve a purpose, but the language was not built around these constructs. It's best (still IMO) to use generics to avoid code repetition, not to build semi-mathematical abstractions for their own sake right now. With time, we'll know how to use generics properly.
- Groxx 5y agoWithout generics this is func (o IntToStringOption) Map(f func(a int) string) IntToStringOption { ... } // ... but that has to be repeated dozens of times tbh I don't see it as much different. The func argument is the most complex part of the whole thing. And much of the readability comes from not using single-char type names, but you do learn to see past that with time.