News for hackers. Stuff that matters.
Re:The Next Step for Generics by kortex on Tuesday June 16, 2020 @10:05PM (#23546912)
Were you using an IDE? For me, yeah go has a lot of boilerplate, but with autocomplete, because the type system is so simple, the autocomplete is super savvy and code just flies onto the screen. Still a fair amount of plumbing, but it's easy plumbing.

I can easily see it being tedious if you have to type every character.

Re:The Next Step for Generics by erik_seaberg on Wednesday June 17, 2020 @12:29AM (#23547793)
The trouble with boilerplate is that we have tools that write it for you but almost nothing that reads it for you, much less reviews it for manual edits. Anything that can be generated from a high level description and then thrown away, should be.
Re:The Next Step for Generics by tsimionescu on Wednesday June 17, 2020 @02:33AM (#23548428)
The IDE side is in my experience the worse part for Go (unless you pay for JetBrains GoLand).

Code navigation is extremely basic (can only find references in the same package!), often breaks, and can't handle stuff like finding all interfaces that a type implements, or finding all implementations of an interface.

Re:The Next Step for Generics by throwaway894345 on Wednesday June 17, 2020 @11:22AM (#23552509)
It used to be really good across the board, but I think modules broke a lot of things and they never fully repaired? I'm not sure, but I get the feeling that the quality of these editor integrations dropped a year or two ago.
Re:The Next Step for Generics by tsimionescu on Wednesday June 17, 2020 @02:35PM (#23554981)
As far as I can tell, they never had support for finding usages across packages, never had support for finding implementations of an interface, never had support for finding what interfaces a certain type matches/implements. These are basic features in any IDE for a language that has packages and interfaces.

Really good IDE support would include refactoring (more than renaming a local variable/struct field, e.g. Extract Function, extract parameter), advanced navigation/analysis (analyze data flow to/from variable, find call stack etc).

Go is somewhat decent in the tooling area, and you can get your job done with it, but it really doesn't have anything I would call good support in any area of tooling except the compiler (not code analysis, not debugging, not monitoring, not profiling, not package management).

Re:The Next Step for Generics by throwaway894345 on Wednesday June 17, 2020 @03:16PM (#23555512)
> As far as I can tell, they never had support for finding usages across packages, never had support for finding implementations of an interface, never had support for finding what interfaces a certain type matches/implements. These are basic features in any IDE for a language that has packages and interfaces.

I suppose it depends on what you're used to. I've never found myself wanting to do these things, but I'm also strictly from a Python and C++ background so my standards are admittedly lower than Java and C# people. Hopefully gopls solves for these problems.

Re:The Next Step for Generics by tsimionescu on Wednesday June 17, 2020 @03:46PM (#23555854)
In C++, you have never tried to go to the definition vs declaration of a function? Or find calls to your class through a superclass?
Re:The Next Step for Generics by justinclift on Wednesday June 17, 2020 @04:01AM (#23548982)
Which Go IDE's have you tried?
Re:The Next Step for Generics by tsimionescu on Wednesday June 17, 2020 @09:32AM (#23551149)
I tried GoLand, which was great.

Then, I tried VSCode with the Go plugin, both the default version and the go pls based one; and Emacs with the LSP package and go pls.

Re:The Next Step for Generics by qtplatypus on Wednesday June 17, 2020 @01:25AM (#23548112)
The boilerplate still has to be read and so the boilerplate still gets in the way of understanding "What is this supposed to do"