problem with interfaces in Go, is that theyre not compile time. which means
No errors - debug later (HAHAHAHAHA EVIL) jk
Runtime-Casting.
So, tbh I dont think interfaces are a solution. Problem is that Go was built with "Simplicity in mind" and "Remove every single feature modern languages have" like enums … or generics … which were both made for very good reasons. And I hate that. It makes me think that some kind of hipster made that language (yes I know who the "hipster" is :P damn you Rob Pike and your hipster mind) and now they're trying to retaliate with "putting Generics 10 years later" … generics that barely work or are useful at all, let alone the things they still don't have but should have. I dont wanna pollute my package namespace with ""enums"" that have HUMONGOUS names just to make them different from other enums. Reminds me of C when Golang is supposed to be … "the modern C" or "how modern C should have looked like"?? (which is stupid assessment imo, it's not comparable in any way) As they advertised it? Or at least I've heard that many couple of times.
Well let's not be unfair, aside from things like enums or other features, sometimes generics do work, but in comparison with Rust's, C++, C#, Java's generics they're not comparable at all. It's like a drawing on top of Go. It doesn't feel like it's Go-ish and that Go has adopted generics properly at all. But still, good enough for making performant but not critical as you said projects, in an efficient way without having to deal with memory too much and still keeping some middle ground until you need the "critical" part.
tbh happy we came to a middle ground. thanks for discussing through it.
And I think the idea of interfaces is fine, just not Go's implementation. Interfaces could be a compile-time, duck-typed abstraction with very basic runtime reflection (basically just a type-assertion switch), but they're not. They instead leaned way too hard into it and made interfaces a value type, when they really shouldn't be like that at all.
The vast majority of the time, I just want to pass a concrete type as an abstract type, and occasionally check if that abstract type has any extra features (e.g. does this io.Reader have a Close() error?). I've done runtime reflection a few times in Go, and every time it was a disgusting hack.
Rust goes the opposite direction and forces the developer to explicitly opt in to traits. That's a bit more annoying, but it makes for much more scalable software. I don't know how many times I accidentally didn't implement an interface fully and my types didn't come through until I ended up with forcing the compiler to help out: var_someInterface= concreteType{}. I ended up doing that pretty much everywhere because I ran into so many times I accidentally didn't fully implement a type.
I still think Go is a fine language, I just don't think it scales well to larger applications. And that's what I want to build, so I don't use Go much anymore.
problem with interfaces in Go, is that theyre not compile time. which means
So, tbh I dont think interfaces are a solution. Problem is that Go was built with "Simplicity in mind" and "Remove every single feature modern languages have" like enums … or generics … which were both made for very good reasons. And I hate that. It makes me think that some kind of hipster made that language (yes I know who the "hipster" is :P damn you Rob Pike and your hipster mind) and now they're trying to retaliate with "putting Generics 10 years later" … generics that barely work or are useful at all, let alone the things they still don't have but should have. I dont wanna pollute my package namespace with ""enums"" that have HUMONGOUS names just to make them different from other enums. Reminds me of C when Golang is supposed to be … "the modern C" or "how modern C should have looked like"?? (which is stupid assessment imo, it's not comparable in any way) As they advertised it? Or at least I've heard that many couple of times.
Well let's not be unfair, aside from things like enums or other features, sometimes generics do work, but in comparison with Rust's, C++, C#, Java's generics they're not comparable at all. It's like a drawing on top of Go. It doesn't feel like it's Go-ish and that Go has adopted generics properly at all. But still, good enough for making performant but not critical as you said projects, in an efficient way without having to deal with memory too much and still keeping some middle ground until you need the "critical" part.
tbh happy we came to a middle ground. thanks for discussing through it.
Yeah, no worries.
And I think the idea of interfaces is fine, just not Go's implementation. Interfaces could be a compile-time, duck-typed abstraction with very basic runtime reflection (basically just a type-assertion switch), but they're not. They instead leaned way too hard into it and made interfaces a value type, when they really shouldn't be like that at all.
The vast majority of the time, I just want to pass a concrete type as an abstract type, and occasionally check if that abstract type has any extra features (e.g. does this
io.Readerhave aClose() error?). I've done runtime reflection a few times in Go, and every time it was a disgusting hack.Rust goes the opposite direction and forces the developer to explicitly opt in to traits. That's a bit more annoying, but it makes for much more scalable software. I don't know how many times I accidentally didn't implement an interface fully and my types didn't come through until I ended up with forcing the compiler to help out:
var _ someInterface = concreteType{}. I ended up doing that pretty much everywhere because I ran into so many times I accidentally didn't fully implement a type.I still think Go is a fine language, I just don't think it scales well to larger applications. And that's what I want to build, so I don't use Go much anymore.