A REPL only gives you instant feedback on code that you type into the REPL. If you make some changes to three modules and you want to find out the effect of those changes then you need to...recompile the modules. Having a REPL doesn't help.
I don't find that a REPL really gives me anything that I don't get from tests in Go. The only difference in practice is that I type the code into a text editor rather than into a REPL prompt (which is actually a better experience). On top of that, it's usually good to have that kind of code saved somewhere rather than existing ephemerally in a REPL session.
Depends on how the language you use works. Golang is not made for repl usage so of course you don't really get the full power. Compare with something like Clojure where redefining a function in a repl, makes every function using that function also use the new definition. Start treating functions as just functions without any implicit state, and you can start to overwrite things in the program on the fly. Super valuable when debugging and otherwise also when creating code as you can much easier test ideas.
I don't know if it has a different word, but a repl for Clojure using a repl-workflow is very different from a repl for Golang with the normal "save -> compile -> run" workflow you have with Go.
For example, using a repl-workflow in Clojure doesn't mean you don't write code in your editor. I use vim + vim-fireplace to write my code, then highlight the parts I want to evaluate. So I get both in one. The repl is running in the background, and vim-fireplace communicates with it. Combine this with a SPA and I can have something like `(.alert js/window @username)`, highlight it and evaluate, then have an alert prompt in my browser window, which is next to my editor. Saves me a ton of time.
Yes, I've used Clojure and other Lisps before. The thing is, I don't want to overwrite function definitions in a REPL, because I then lose track of what code I'm actually running. It's much more effective just to make changes in a text editor and track your state using version control. In a language that compiles quickly, a REPL just adds an additional layer of complexity for no benefit. In a language that doesn't compile quickly, redefining functions on the fly in a REPL is a useful hack that lessens the pain somewhat.
>I use vim + vim-fireplace to write my code, then highlight the parts I want to evaluate. So I get both in one.
Sure, and with Go in VSCode, I just click 'run' above the test I just wrote. It isn't any more difficult.
> much more effective just to make changes in a text editor and track your state using version control
Statements like this makes it seem like while you probably have dabbled in Clojure and other lisps, you haven't used them substantially, as if you're using Clojure, you still make your changes in your favorite editor and code is still tracked in version control. It's not REPL _or_ code editor, it's code editor + repl backing.
Redefining functions on the fly is not a hack to lessen the pain, it's a defined workflow that makes you be able to work faster. If you're using it and it feels like something to lessen the pain, you're using it wrong.
> Sure, and with Go in VSCode, I just click 'run' above the test I just wrote. It isn't any more difficult.
This assumes a lot of things around the code that you're executing. First, you've already setup a test and it's already isolated enough. With a powerful repl + idioms, you don't need to do that, as you can execute parts of a function just to introspect that part, kind of like a debugger but works anywhere automatically.
In the end, I'm not gonna try to convince you to try something if you don't want to try it. But if you're anything like me, finding more productive ways of working is always interesting, even if they end up not being as productive as we first thought. With that in mind, since you seem to not have super much experience with a powerful repl, if you try it I'm sure you'll find what I say to be helping you be a better programmer.
>you still make your changes in your favorite editor and code is still tracked in version control.
Version control does not track which sequence of code snippets you have (re)-evaluated to get to your current repl state. I'm fully aware of how editor integration with a Lisp repl works in Emacs and (to a lesser extent) Vim.
>have dabbled...In the end, I'm not gonna try to convince you to try something...seem not to have super much experience with a powerful repl...etc.
As with most Lisp advocates, you seem unable to a accept that I have tried it and didn't like it. Please stop throwing shade.
> This assumes a lot of things around the code that you're executing. First, you've already setup a test and it's already isolated enough
A test in Go is just a function, so no set up is required. A test is more isolated than an expression evaluated in a repl.
It seems to me that you don't have much experience of writing tests in a modern development environment, and this is why manually recompiling parts of your codebase using Vim hotkeys strikes you as a good idea :)
I don't find that a REPL really gives me anything that I don't get from tests in Go. The only difference in practice is that I type the code into a text editor rather than into a REPL prompt (which is actually a better experience). On top of that, it's usually good to have that kind of code saved somewhere rather than existing ephemerally in a REPL session.