3 ms·
I'm really glad they don't have C++ style generics, and I hope whatever way they do it if/when they do, it keeps that Go minimalism. I'd like to see the Interf
by kortex 7y ago
I'm really glad they don't have C++ style generics, and I hope whatever way they do it if/when they do, it keeps that Go minimalism.
I'd like to see the Interface system more powerful. You can already do some very un-gothonic things with map[string]interface{}. I'd like to be able to compose functions already based on an interface, to implicitly implement other types, rather than spelling out each function (maybe you can already, I'm still only a few months in to Go).
I liked the concept of "try" but I agree with the peanut gallery, the syntax needs work. But many gophers (it seems) agree there should be a shorthand for "I got an error, bubble it up to the caller" aka "if err != nil {return nil, err}"
Or maybe not. In some ways, the verbosity of err != nil everywhere makes me look for ways to solve problems with less error returning.
- gtycomb 7y agoI don't miss generics either, not in the least. The interface system, Go's particular approach to it, takes me a long way ... I won't ask for any new feature for today or tomorrow. But for day after tommorow, within a longer time research horizon, I wonder whether compiled and distributed Go applications can be made to interact along the lines of interfaces within an application now. May be its my struggle with Kubernates (as a newbie) that makes me want: Can there be secure language mechanisms supporting clustering, scheduling etc in a distributed enviroment with an external agent armed only with prior package interface definitions of a deployed Go application. Please don't sacrifice performance, and fast compilation times. That module system is looking good!