[NateDad]

functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods.

I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.

[2_listerine_pls]

Yeah, I guess some need to review the definition of abstraction.

[sbov]

Sometimes I feel like the OO world has redefined abstraction to only mean an interface.

[pjmlp]

It was already known in the 90's as component based programming.

https://en.wikipedia.org/wiki/Component-based_software_engin...

https://www.amazon.com/Component-Software-Object-Oriented-Pr...

[kuschku]

And go can not write abstract functions and methods.

I can not write a function dealing with arbitrary values.

Somethind I’d do in Java with

    public static <T extends IIncrementable> T increment(T val) { val.increment(); return val; }

is impossible to do in Go.

You can not abstract over types, and write metric fucktons of duplicated code. I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times, once for every type. Fixing bugs became a nightmare.

[jy3]

> I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times

Who would have thought. Maybe a rewrite would have been more appropriate.

[kuschku]

Porting meant rewriting here.

But I still ended up with the same classes replicated hundreds of times.

Polymorphic code is not possible in any other way in go – you always have to duplicate the code.

[jy3]

I'm sorry it went badly then.

Your example intrigues me, isn't an interface enough?

Is what bother you that the return value won't be typed T but IIncrementable in go?

[kuschku]

Yes, exactly. This is an actual issue.

My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts.

So, the library now gets these functions, and does all the filtering on other threads.

So either I have to replicate the entire async code for every type, or I can’t keep type safety.

[rogpeppe1]

Don't keep type safety then. Think of Go as half-way between Python and Haskell in that respect. Types are great when they're useful, but they're not required.