4 ms·

Except what does Go get for ditching the REPL? It already has a substantial runtime (the usual pain of an REPL)

randomdata 3y ago
What would it gain? REPLs make perfect sense for scripting problems, but when you would you ever use it for systems problems?
- dekhn 3y ago
  often when I am developing systems code or RPC client code, I sit in a REPL and make repeated ad-hoc calls to various functions, building up various bits of state (I started using python long before Jupyter). I find this much more intuitive than writing code, compiling it, executing it, going back to the editor, changing the code, re-running it with something that loads a bunch of data, just so I can answer a question about the runtime behavior of the system I'm working with.
  - randomdata 3y ago
    There is certainly something to be said about being able to answer questions about another system by poking at it, but that is a scripting task. You would be better served by a scripting language. And, as it happens, most scripting languages come with REPLs. That is a solved problem that was solved long before Go was ever imagined. Just because you are building a particular systems program does not mean everything you do has to be a systems problem. And, really, if you don't exactly know what you're building, it is probably too soon to consider any of it a systems problem.
- Guvante 3y ago
  You say systems problems like Go is for embedded work. 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...
  - randomdata 3y ago
    > 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!
ncruces 3y ago
Not being able to create new code at runtime is a pretty huge freepass for the compiler to implement stuff a certain way. You can bet the Go compiler and runtime leverage that assumption.
- Guvante 3y ago
  Even without optimizations?
  - ncruces 3y ago
    Yes. There are long standing feature requests for (e.g.) the reflect package that simply don't get done because they'd break this assumption and/or force further indirection in hot paths to support "no code generation at runtime, ever". Packages like Yaegi (that offers an interpreted Go REPL) have "know limitations, won't be addressed" also because of these assumptions. https://github.com/golang/go/issues/4146 https://github.com/golang/go/issues/4146 https://github.com/golang/go/issues/16522 https://github.com/golang/go/issues/16522 https://github.com/traefik/yaegi?tab=readme-ov-file#limitations https://github.com/traefik/yaegi?tab=readme-ov-file#limitati...
    - Guvante 3y ago
      If they wanted an REPL having an interpreted Go compiler isn't unheard of in the space. It isn't like a hypothetical C++ REPL would use unmodified LLM under the hood after all.
      - deleted 3y ago
        [deleted]
      - ncruces 3y ago
        Then just use Yaegi, which I linked to above. It has the limitations mentioned, which are necessary to make duck-typed interface calls reasonably efficient, if you assume no code generation at runtime, ever. There's really no other way. If you don't know before hand all the interfaces that might exist, and/or all the types that might implement them, interface method calls would necessarily either need to be JIT generated, or a string based hash map lookup (runtime reflection, which exists, but is slow). Go avoids both by knowing statically at compile time the list of all interface and the list of all types that can ever possibly implement them and building vtables for those.

What would it gain? REPLs make perfect sense for scripting problems, but when you would you ever use it for systems problems?

dekhn 3y ago
often when I am developing systems code or RPC client code, I sit in a REPL and make repeated ad-hoc calls to various functions, building up various bits of state (I started using python long before Jupyter). I find this much more intuitive than writing code, compiling it, executing it, going back to the editor, changing the code, re-running it with something that loads a bunch of data, just so I can answer a question about the runtime behavior of the system I'm working with.
- randomdata 3y ago
  There is certainly something to be said about being able to answer questions about another system by poking at it, but that is a scripting task. You would be better served by a scripting language. And, as it happens, most scripting languages come with REPLs. That is a solved problem that was solved long before Go was ever imagined. Just because you are building a particular systems program does not mean everything you do has to be a systems problem. And, really, if you don't exactly know what you're building, it is probably too soon to consider any of it a systems problem.
Guvante 3y ago
You say systems problems like Go is for embedded work. 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...
- randomdata 3y ago
  > 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!

ncruces 3y ago

Not being able to create new code at runtime is a pretty huge freepass for the compiler to implement stuff a certain way. You can bet the Go compiler and runtime leverage that assumption.

Guvante 3y ago
Even without optimizations?
- ncruces 3y ago
  Yes. There are long standing feature requests for (e.g.) the reflect package that simply don't get done because they'd break this assumption and/or force further indirection in hot paths to support "no code generation at runtime, ever". Packages like Yaegi (that offers an interpreted Go REPL) have "know limitations, won't be addressed" also because of these assumptions. https://github.com/golang/go/issues/4146 https://github.com/golang/go/issues/4146 https://github.com/golang/go/issues/16522 https://github.com/golang/go/issues/16522 https://github.com/traefik/yaegi?tab=readme-ov-file#limitations https://github.com/traefik/yaegi?tab=readme-ov-file#limitati...
  - Guvante 3y ago
    If they wanted an REPL having an interpreted Go compiler isn't unheard of in the space. It isn't like a hypothetical C++ REPL would use unmodified LLM under the hood after all.
    - deleted 3y ago
      [deleted]
    - ncruces 3y ago
      Then just use Yaegi, which I linked to above. It has the limitations mentioned, which are necessary to make duck-typed interface calls reasonably efficient, if you assume no code generation at runtime, ever. There's really no other way. If you don't know before hand all the interfaces that might exist, and/or all the types that might implement them, interface method calls would necessarily either need to be JIT generated, or a string based hash map lookup (runtime reflection, which exists, but is slow). Go avoids both by knowing statically at compile time the list of all interface and the list of all types that can ever possibly implement them and building vtables for those.