4 ms·
> You can create an exported version of the function These are the kinds of hacks that show that golang wasn't really designed for "programming in the large",
by apta 6y ago
> You can create an exported version of the function
These are the kinds of hacks that show that golang wasn't really designed for "programming in the large", despite their claims.
I've used goland, and the actual renaming is generally fine (it means it works correctly when needed). However, that doesn't mean that there isn't a lot of friction
- cpuguy83 6y agoI don't agree with the term "hack" here. Different is not "hack". I maintain some very large codebases. This has never been an issue. If one decides to export a function, the only callers of that function will be from within the package it was defined in already. Even within a package, how many call sites will there actually be and do they need to use the exported version of the function? I'm not saying it's good, or bad, just that in my (fairly extensive) experience it has not been a problem. I do recognize that some people may have problems with it, though.
- apta 6y agoMy experience has been otherwise, it's been extremely friction-inducing and I had to go out of my way to split up diffs into smaller ones in order to make it clear what was going on. A language like Java or C# would have just had a single line difference (`-private +public`) and be done.