"No inheritance - no more digging through the massive world-tree of objects to find the code that actually does things."
You still have interface methods? I had problems navigating a new codebase and find the places "actually doing things". Some object was passed in somewhere which mysteriously implemented a one method interface defined on the spot in the other go file. I.e. the implementation had no relation to the interface which was obvious without a lot of searching and finding the right implementation.
Also passing in functions (callbacks?) all over the place is a little messy at least for a newbie. It was hard to find where the functions where called and at what point and how the program flowed.
(this is hard to explain but maybe somebody gets the point...)
edit: somebody else touched on what I also meant: " duck typing make refactoring and understanding new codebases error prone"
Also the modules and dependencies management surely is a joke? Pulling stuff from github willy-nilly? Quite bad in any case when compared to maven where you have a local repository with all the dependencies (so they don't change or disappear from the internet so that you can actually build your software 5 years later, exactly in the same way)
There are certainly ways to write confusing code in Go too, no inheritance is just one cause of confusion subtracted.
IMO interfaces are best used sparingly and in a minimalist way like io.Reader (but I prefer them to Java interfaces and have not found them confusing nor felt compelled to find all concrete types conforming), callbacks are best avoided if possible, and yes dependency management has only recently improved.
I really do think Go has a discovery problem. Function signatures don’t tell you hardly anything, does this need something deferred, what types does it implement, etc.
You still have interface methods? I had problems navigating a new codebase and find the places "actually doing things". Some object was passed in somewhere which mysteriously implemented a one method interface defined on the spot in the other go file. I.e. the implementation had no relation to the interface which was obvious without a lot of searching and finding the right implementation.
Also passing in functions (callbacks?) all over the place is a little messy at least for a newbie. It was hard to find where the functions where called and at what point and how the program flowed.
(this is hard to explain but maybe somebody gets the point...)
edit: somebody else touched on what I also meant: " duck typing make refactoring and understanding new codebases error prone"
Also the modules and dependencies management surely is a joke? Pulling stuff from github willy-nilly? Quite bad in any case when compared to maven where you have a local repository with all the dependencies (so they don't change or disappear from the internet so that you can actually build your software 5 years later, exactly in the same way)