> You say systems problems like Go is for embedded work.
I'm not sure who is talking about embedded work. That didn't come from me. There is nothing in this thread about embedded. Did you accidentally press the wrong reply button?
I say that Go is for systems. Do you think Go is actually designed for scripting? If so, why?
> Half the things I have seen replaced Python scripts
Python is often used to build systems.
Python is a scripting language, yes, but that doesn't mean you can't build systems in it – just as you can build scripts in a systems language. But there are tradeoffs in crossing paths like that. Systems languages will be better for building systems, and scripting languages will be better for building scripts.
Perhaps the applications you speak of are actually systems and that is why developers saw reason to convert them into using a systems language?
> Seeing what your internal state is after taking X action is exactly what REPLs are good at...
Quite good. But that workload is not systems in nature, so why would you ever do that in a systems language? That is a scripting workload. Naturally you would use a scripting language. And, lucky for you, most scripting languages include REPLs out of the box!
Half the things I have seen replaced Python scripts. Seeing what your internal state is after taking X action is exactly what REPLs are good at...