Sure, the performance characteristics could be improved, but other than that they solve all my main pain points I wanted them to solve while being constrained enough to not result in ivory towers on every corner.
My main pain points having been duplicated functions for each type as well as data structures.
You can easily and cleanly work around this by exposing getter and setter method in your interface.
BTW, accessing common fields is temporarily disabled before releasing Go 1.18, because there is another fundamental problem which needs to be resolved firstly.
Concepts?
So, how do I specify, using concepts, that my template expects a type which has a field “.foo” of type int?
template<typename T>
concept has_foo = requires(T x){
{ x.foo } -> std::same_as<int>;
};
template<has_foo T>
int get_foo(T x){...}
// or
template<typename T>
requires has_foo<T>
void f(T x){...}
// or even
void f(has_foo auto x) {...}type hasFoo interface {
getfoo() int
setfoo(int)
func f(hasFoo) {}
?
func f[T interface{.Foo}](T) {}
func f[T interface{GetFoo(); SetFoo()}](T) {}
foo.baz = 1; // baz could be a int or could be a setter.
int baz = foo.baz; // sameRust is the same I think, where you'd need to have methods that explicitly implement the trait (interface in Go). However, Rust has a built-in code generation tool (macros), and you can decorate your structs to have it automatically implement some traits for you. That's the equivalent of adding one more entry to your Go generated code loop, except that it's right next to the struct.
If Go did support field methods (which it looks like they may one day), that might be the tipping point for me for disabling a bunch of generated code. Not sure if there's other things getting in my way, because I gave up once I noticed I couldn't do that.
In the meantime I guess there's always anonymous functions (to use as accessors). They're not hard to be generic over.
If that performs the same as a normal field access (or the equivalent behind a non-inlined function or something), yeah, that'd be completely fine. My main thought was that you can very easily reference and use `type.Method` (you just have to pass an instance as an additional first argument), so a straightforward `type.Field` equivalent would be convenient in a number of places. E.g. you could avoid the need to add accessor methods, which isn't possible on types you don't control, and no need to create anonymous functions everywhere to work around that.
The best performance you'll get is probably from putting the fields together into a substructure and passing around pointers to that. Which doesn't need any reflecting or additional language scaffolding.
It's not that it's bound vs. unbound, it's that you passed it somewhere else so the call is necessarily dynamic. It would happen with non-method functions also. (In neither case is there a "function table lookup" - that's rather if you call through an interface / generic dictionary.) A bound one would be even more expensive because you also have to allocate a closure for the receiver.
The point is: You want some non-compile-time behavior, whether that's a function or field access, you're going to pay more. That time, not regular field access, is what should be compared to reflect performance.
Hiding an anonymous `return it.field` behind an interface{} in an attempt to stop inlining or other optimizations: 2x worse than directly accessing a field (same as direct access when not doing the interface dance, so it's preventing something at least). So "excellent performance", though there may be optimizations happening in a benchmark that aren't realistic in a larger system.
Using `reflect.ValueOf(it).Field(0).String()` each time: 60x worse than direct field reference. Go reflection remains pretty fast, but that's rather noticeable.
There does not appear to be any way to cache ^ that reflection operation. I.e. I don't see any way to go from `reflect.TypeOf(it).Field(0)` to "read that field from this instance".
---
And somewhat surprisingly: `m := instance.Method; benchmark{ m() }` performs ~10x worse than `benchmark{ instance.Method() }` and `m := type.Method; benchmark{ m(instance) }`. There's no intentional optimization-defeating here, so it is entirely possible this difference disappears in practice, but I'm surprised that they're not identical.
And I couldn't figure out a way to get a reference to a pointer-implemented method, e.g. `m := (&type).Method` or something. It only works on `m := type.Method` when the method is a value receiver. Possibly I'm missing something obvious.
---
I kinda want to redo ^ these and check compiler output closely, and try adding more packages / make more realistic optimizer-information-loss like you'd see in more normal go code. I suspect there are still some unrealistic ones occurring. But I've gotta drop this for now, so that's going on my ever-growing todo list.
I’m also not sure about the `benchmark{ ... }` syntax, but:
m := instance.Method; benchmark{ m() }
m := type.Method; benchmark{ m(instance) }
benchmark{ instance.Method() }
---
reflect.ValueOf(it).Field(0).String()
60x sounds bad, but I really cannot stress enough: As soon as you're not doing a simple fixed-offset memory fetch from a base pointer, you might be paying 10x anyway no matter how good your optimizer is. That's just the cost of unpredictable memory access, even before we start talking about downstream impact on the code generator.
If you only want to support direct fields and not really the equivalent set of named fields you could type in a Go program, you can do some tricks with unsafe.Offsetof which will be faster, and probably cachable. But it's also called unsafe for a reason.
Optimization-defeating: go infers when to move things the heap vs keep it on the stack, and does somewhat aggressive in-function optimizations and inlining that it does not do cross-function. One common, very simple, and reasonably effective way to prevent some of that is to erase type information by passing a value through an interface{}. Even if you immediately unpack it and reuse the reference, Go has no jit, so it gets the job done alright. There are some other things that don't survive cross-package analysis, last I looked, so using multiple packages can also help make your benchmarks more realistic. It takes a lot more effort to be truly realistic in even one benchmark, much less the 9 various flavors that I tried.
And the String() piece is because I had it return a string because why not. Variable-sized data is extremely common so it's realistic enough, and using the correctly-typed reflection funcs usually avoids some reflection and boxing and allocation costs that I didn't feel like trying to address in more detail.
None of which was written out explicitly because there are tons of caveats regardless of the care I tried to take, so I just mentioned that they existed and moved on because I couldn't spend more time at that time.
Rich Hickey's talks can be very insightful in this regard. He surely convinced me :)
On the other extreme, you have Rust and Haskell type systems where you spend gratuitous time on pacifying the type checker for negligible quality gains (arguably negative gains).
I always felt Go hit the sweet spot.
It's easy to confuse type systems with correctness or clarity of thought. I've fallen victim to this myself – "oh this didn't map well to Rust's type system, I must be thinking wrong", kinda. It tickles this ocd nerve and I lose focus on the problem I'm trying to solve, often without realizing that I'm just wasting time.
I also like Go for these reasons. It's dumb and predictable, which let's me focus on the problem I'm solving. My only annoyance is really verbosity and small amounts of boilerplate.
Unfortunately, this nuance is missing from the discussion with people mostly talking about software as though it’s all mission critical / infrequently updated / rapid iteration doesn’t matter which is exactly incorrect for the general case.
I'm not kidding. Go is at a very nice verbosity level as far as reading code goes, but writing it is indeed tedious occasionally. However, in practice, Copilot is able to handle those bits extremely well, giving us the best of both worlds.
(Edit: This is a serious question; I recently semi-seriously commented that maybe solutions like Copilot are particularly well suited to solve this problem with Go, so I'm curious how well it works in practice.)
I'm mostly talking about boilerplate like writing `if err != nil` with a nice wrapping message every other line. Copilot will just write 2-3 lines at a time. That's imo the kind of boilerplate that might often be annoying to write.
I'm not talking about generating multiple copies of the same function nor anything like that. That would be better suited to deterministic generation or copy+paste. Copilot doesn't help you here.
My bigger annoyance is when I want to write non-trivial functionality that works for different data types.
I'm not aware of anything else that writes good wrapping error messages automatically though.
Your use-case is precisely what you'd be using generics / standard codegen for.
Each error wrap has a situation-dependent wrapping message, different for each wrapped error in the function.
Copilot is great at writing the whole `if err != nil`, including context-specific wrapping messages. It's also great at writing your code in many other situations where the intent is clear and simple, but it just takes a few lines to write in Go.
I'm not sure if you've ever used Copilot yourself, but it's basically autocomplete on steroids.
When programming in the large, type systems are flat out an unmitigated win. The more you can confidently assert about your program before run time, the more time and money your team will save. If you are programming a large system and not using strong static typing, optimally with higher-level features like parametric types, then you are doing it wrong.
In the early stages of developing something complex you often want to play fast and loose with the type system - get some code running, and some tests set up, and go from there. But later on you want to refine it and start catching some more errors statically.
The pendulum has swung really far to static typing - and I get why. But if it swings back I hope we don't forget about gradual typing.
The poster child of gradual typing has to be TypeScript, and it's been a wild success. TypeScript allows gradual implementation to any JavaScript project and there's almost a million small different gradients you can use. From simply using a js file, to noImplicitAny, to simple types, to using complicated built-in types (eg Partials).
With TypeScript, you never lose the speed of dynamic typing. The whole point of gradual typing is you can jump between more and less types, so at no point are you restricted from reverting to full dynamic typing. And it is true, you can't rely on all types being checked, but the point is you add it to the important/stable bits. And having your largely stable important bits being typed while your more experimental unstable code can be dynamic (while still getting the benefit of consuming the stable types) is a nice place to be.
As I said, it is what you make of it. If you spend all your time typing the unstable bits and leave the stable core bits untyped, well, you've just wasted your time and would get the worst of both worlds.
I believe Haskell has them, is that where you've used them?
I mainly use Swift these days but I haven't had a need for them yet so was asking out of curiosity.