4 ms·

MakeSureToGetItInPrint importantThing = new Namespace.MakeSureToGetItInPrint(one, two, three); Dependency management in my experience is not a problem at all i

MakeSureToGetItInPrint importantThing = new Namespace.MakeSureToGetItInPrint(one, two, three); Dependency management in my experience is not a problem at all in Go. Vendoring might be different but it's not complicated nor strictly worse. As for automated refactoring, what more would you like to see in the tooling compared to what you already have (renaming)? The death-by-thousand-file-splits that's recommended in Java and for which IDE help is useful, is not idiomatic in Go. The most code you have to write to split a file into two is the keyword `package` and the package name. The rest is just copy+paste and let `goimports` take care of doing the rest.

twic 10y ago
That's a funny example, because it's rare to qualify a type with a package in Java, whilst it's essentially universal in Go. Automatic refactorings i routinely use in Java are extracting variables, methods, constants, and fields (including automatically finding and extracting repetitions of the body); inlining the same; splitting and combining variable declaration and use (easier in Go, of course!), adding, removing, and reordering method parameters; correcting declared method return and parameter types based on actual use; extracting superclasses and moving methods up and down type hierarchies (again, not relevant in Go); moving methods to a receiver which was one of its parameters. All the stuff which is the bread and butter of reshaping code. All done in a keystroke or two. Not copying and pasting and then manually following through. Again, to be clear, i have done Go development. About three months of full-time Go with experienced colleagues. I know what state of the art Go development looks like. It's unambiguously slower than Java development. We'll have to agree to differ on dependency management.

4 ms·

MakeSureToGetItInPrint importantThing = new Namespace.MakeSureToGetItInPrint(one, two, three); Dependency management in my experience is not a problem at all i

by mixedCase 10y ago

twic 10y ago
That's a funny example, because it's rare to qualify a type with a package in Java, whilst it's essentially universal in Go. Automatic refactorings i routinely use in Java are extracting variables, methods, constants, and fields (including automatically finding and extracting repetitions of the body); inlining the same; splitting and combining variable declaration and use (easier in Go, of course!), adding, removing, and reordering method parameters; correcting declared method return and parameter types based on actual use; extracting superclasses and moving methods up and down type hierarchies (again, not relevant in Go); moving methods to a receiver which was one of its parameters. All the stuff which is the bread and butter of reshaping code. All done in a keystroke or two. Not copying and pasting and then manually following through. Again, to be clear, i have done Go development. About three months of full-time Go with experienced colleagues. I know what state of the art Go development looks like. It's unambiguously slower than Java development. We'll have to agree to differ on dependency management.