101–110 of 125 posts
Earlier quoted context omitted.
Try implementing a shared map type where access is protected by a mutex and otherwise works just like Go's builtin map type (which is a generic map type).
Why would I need to re-implement what is already there?
Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.
Did you consider parameterized packages? The idea is you can declare a set of related objects/types/methods as well as have concrete type specific initialization. E.g. package stack[t] type Type []t func New() Type { return Type{} } ... Then it can be used so: import s “stack”[int] var s1 = s.New()
Earlier quoted context omitted.
Interesting, you have a point actually. I would have thought that the performance cost of calling through an interface would be negligible, but I'm wrong about that: https://github.com/golang/go/issues/20116 The issues linked at the end there are interesting reads, and maybe they'll do something about this by Go 1.11. Having said all that, will an implementation of your code with generics be all that much faster? Or…
> Having said all that, will an implementation of your code with generics be all that much faster? Likely yes. If generics are implemented via monomorphization, then you can avoid the overhead of virtual calls necessitated by interfaces. It is possible that the compiler could become smart enough to devirtualize calls through interfaces.
Earlier quoted context omitted.
Did you consider parameterized packages? The idea is you can declare a set of related objects/types/methods as well as have concrete type specific initialization. E.g. package stack[t] type Type []t func New() Type { return Type{} } ... Then it can be used so: import s “stack”[int] var s1 = s.New()
I’ve seen this in ocaml and always thought it strange. I think it’s useful, but binding it to a package seems odd since packages are units of code distribution or some such.
Earlier quoted context omitted.
Image allows you to do this more or less. The problem to be solved here is that if you write the resize logic just once, you are accessing pixels from the image via the interface in a tight loop, and most of the time taken by your image resizer is the overhead of that access.
Interesting, you have a point actually. I would have thought that the performance cost of calling through an interface would be negligible, but I'm wrong about that: https://github.com/golang/go/issues/20116 The issues linked at the end there are interesting reads, and maybe they'll do something about this by Go 1.11. Having said all that, will an implementation of your code with generics be all that much faster? Or…
Earlier quoted context omitted.
And I've read about many people using Go and wishing for generics from day one.
It's mostly a "day 1" concern, is all. Once you get over it you find that you can do whatever you need.
Should be called mofo.
Earlier quoted context omitted.
Did you consider parameterized packages? The idea is you can declare a set of related objects/types/methods as well as have concrete type specific initialization. E.g. package stack[t] type Type []t func New() Type { return Type{} } ... Then it can be used so: import s “stack”[int] var s1 = s.New()
I’ve seen this in ocaml and always thought it strange. I think it’s useful, but binding it to a package seems odd since packages are units of code distribution or some such.
Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.
Did you consider parameterized packages? The idea is you can declare a set of related objects/types/methods as well as have concrete type specific initialization. E.g. package stack[t] type Type []t func New() Type { return Type{} } ... Then it can be used so: import s “stack”[int] var s1 = s.New()
I made gotemplate to explore that idea
https://github.com/ncw/gotemplate
This requires a round of `go generate` for the actual code generation, but otherwise quite a similar experience.
Having it built in would be great!
Earlier quoted context omitted.
> Having said all that, will an implementation of your code with generics be all that much faster? Likely yes. If generics are implemented via monomorphization, then you can avoid the overhead of virtual calls necessitated by interfaces. It is possible that the compiler could become smart enough to devirtualize calls through interfaces.
Pretty sure devirtualization is a whole program optimization in the general case, and I don’t see the Go dev team Pershing that in the next couple of years.
Agreed. But if I didn't mention it, I'm sure someone would have felt obligated to respond with a "well actually..."