> When prototyping with Go, I constantly have to move back and forth between the type definition and the places I'm using the type.
I do the same but I don't feel slower doing it. I mean I have to move around between function bodies and callers, for example, when I'm hacking in python, so the two don't feel that different to me (moving between a user and a provider or definition of something when hacking on code).
But what does feel different to me is if I hack up some go and get a compile error, that feels MUCH faster and nicer to me than hacking up some python, running for a minute, and half way through hitting a runtime type error.
There's at least some speed up when prototyping - think having n functions, and wanting to do some sort of refactoring. You might want to iterate on some refactoring idea, and test it out on the most problematic of those n functions. Dynamic typing gives you the possibility to avoid refactoring the whole codebase (the parts touched by your refactoring, I mean) and test out the refactoring idea on just that function.
I'm not sure I'm convinced, though the idea is interesting.
I feel like if I was refactoring a function and that refactor had a small ripple effect - say I didn't have to change any data structures outside the function and didn't have to change many other functions (callers or callers) - then I don't think there will be much speed up.
And if this was a small refactor on a larger function, or a larger refactor which included changing data types used in other places, then I want to be sure everything I'm about to run as part of my experimental partial refactor was updated.
Sure, if the type system complains about some unrelated function which no longer compiles then I might lose some time commenting out that function or fixing it up, but also the type system may point out a spot I didn't think was part of my experiment but which really was, and I'll save time on runtime errors or debugging. Or it may point out an issue in unrelated code that I didn't think about but which may make the refactor infeasible.
In my experience this kind of thing is a wash, but I would not be surprised if other people's experiences differ.
I do the same but I don't feel slower doing it. I mean I have to move around between function bodies and callers, for example, when I'm hacking in python, so the two don't feel that different to me (moving between a user and a provider or definition of something when hacking on code).
But what does feel different to me is if I hack up some go and get a compile error, that feels MUCH faster and nicer to me than hacking up some python, running for a minute, and half way through hitting a runtime type error.