5 ms·

My experience with Go was bizarre -- I loved programming in it, but I don't understand why! For example, Go has no REPL. (It's difficult for statically-typed

My experience with Go was bizarre -- I loved programming in it, but I don't understand why! For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem to agree that it's always superior to have a REPL than to be forced to live without. Lots of people love programming in Golang (I especially love to write distributed systems with it!) yet it probably won't ever offer us a REPL. That must mean one of two possibilities are true, both of which are bizarre: either 1) we love Go in spite of being limited by not having a REPL, or 2) having a REPL isn't as big of a deal as everyone thought. So I'd like to ask all of you: Do we love Go in spite of being held back by it? If so, then what are the factors that cause us to decide that using Go is worth giving up programming power? After all, each of us are choosing to use Go in lieu of more powerful languages. So why do we choose to give up programming power? Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? That seems plausible. It's at least as plausible as "it's a good idea to give up REPLs for static typing." Go is wonderful to work with. But I'm so confused why it feels wonderful to me. I know I love programming in it, but once I start thinking about the implications, I start to wonder: Isn't giving up power a bad thing, and therefore choosing to use Go == choosing to be forever held back by its deficits, and therefore it's a bad decision? Or is it true that having every possible language feature available to you ("maximum potential programming power," i.e. as far above Blub as possible) isn't as big a deal as we all thought? This pg essay talks about why it's worthwhile to have as much power as possible: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html (search for Blub Paradox) .... So either he's wrong, or we're ignoring him even though he's right. Which is it? EDIT: There are other limitations besides lacking a REPL, e.g. there's no dynamic typing. It seems like we should try to figure out why it's a good idea to give up any programming power at all.

genwin 13y ago
Less is often more! I prefer the Go Playground over a REPL, especially since I can easily see others' code snippets running using the Playground's Share feature. My 2nd favorite thing about Go (after its runtime speed) is its compiler and excellent error messages that let me quickly realize what mistake I made.
throwaway344 13y ago
Statically typed languages don't necessarily not have a REPL, most functional languages are statically typed and yet they general have a REPL. OCaml, Haskell, F# and the like.
- adriaanm 13y ago
  Another example would be Scala. It has a command-line REPL and the IDE has a worksheet[1]. I find both tremendously useful. [1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-Started https://github.com/scala-ide/scala-worksheet/wiki/Getting-St...
benatkin 13y ago
Perl and PHP are also open source languages were people don't use repls often. Java and C# don't have repls either. I don't think everyone has ever thought they needed a REPL for any reasonable definition of everyone.
- jodrellblank 13y ago
  C# from Microsoft doesn't have a REPL, but C# with Mono does: http://www.mono-project.com/CsharpRepl http://www.mono-project.com/CsharpRepl
- Tobu 13y ago
  re.pl is invaluable to the modern Perl programmer (as is cpanm).
  - benatkin 13y ago
    I don't think it's invaluable to the modern perl developer. I don't know whether I disagree with your concept of invaluable or your concept of modern perl developer or both. I tried searching "perl repl" on twitter and google to see if there's much talk about it and there doesn't seem to be much. AFAICT it just isn't a big part of the perl workflow, modern or not. Most of the people who like it could manage just fine without it. I don't think the same is the case with python or ruby. Some pythonistas and rubyists use the repl for everything. I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.
    - draegtun 13y ago
      The best place to search (for Perl REPL's) is on CPAN - https://metacpan.org/search?q=repl https://metacpan.org/search?q=repl The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL https://metacpan.org/release/Devel-REPL The new kid on the block is Reply - https://metacpan.org/release/Reply https://metacpan.org/release/Reply PS. I do find using a Perl REPL invaluable for me.
danenania 13y ago
I see go as essentially a polished and robust glue language. It's not particularly well suited to data processing because its lack of functional constructs and generics makes transforming lists verbose, but it's perfect for wiring up databases, apis, system calls, sockets, queues, and the like in a way that's safe, performant, and concurrent by default. Given this focus, it sort of makes sense why you might not miss a repl as much in go (though personally I do still miss it). Repls are most useful for exploring and experimenting with complex data, while I think go's focus is more on streamlining and bulletproofing all the machinery surrounding the data than doing a whole lot with the data itself. I don't mean this as a criticism and I'm not trying to say that you can't do serious data processing in go, just that it's not a core strength like it is in functional languages. I think the majority of applications out there actually have fairly light data processing needs and heavy glue needs, so go's set of tradeoffs make it a great candidate for tons of projects.
pcwalton 13y ago
> It's difficult for statically-typed languages to provide one. No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages. > there's no dynamic typing Yes, there is, through `interface{}`.
- JulianMorrison 13y ago
  The main thing stopping Go having a REPL (when there are ones for C, for example) is that Go can't yet compile to, or load, dynamic libraries. This stops each bit of REPL being compiled up and executed, which would otherwise be simple.
  - pjmlp 13y ago
    And most likely never will, given the Go's team stance on dynamic linking.
tptacek 13y ago
Golang is like a touring car. It's fast, but doesn't have the fastest engine. It's got some nice features, and it's comfortable (at least for the driver), but it doesn't have every bell and whistle. But: the handling is amazing; it's a monster in the corners. You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that car. Same with Golang. They did an extraordinary job balancing the language, especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.
- girvo 13y ago
  Normally, if I see a car analogy applied to programming languages (which hackers seem to do a lot), I instantly brace myself for petty debate on the semantics of the analogy itself (which hackers seem to do a lot). This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).
- asdasf 13y ago
  >especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance. Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.
  - tptacek 13y ago
    This is more "Internet article of faith" than actual fact; it's something people say because it was said in some blog post once. For whatever it's worth to you, I've been a systems programmer since ~1995. The lingua franca of systems programming is C; Golang's type system is strictly superior to C.
    - asdasf 13y ago
      It is more "direct observation" than "internet article of faith". I know one person who likes C and go. Every other go convert I know came from a scripting language. Golang's type system is strictly inferior to D.
laureny 13y ago
> Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages). There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's just not that useful when you have powerful IDE's at your disposal. Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.
- tensor 13y ago
  I routinely initialize quite complex states in the repl during development. If anything, it's even more important in that situation since it can often take a long time to get to that state-point in the program.
- bad_user 13y ago
  The REPL and IDEs are somewhat orthogonal. IDEs are extremely limited in fact, as they can only rely on static-type info to infer meaningful stuff about how your software will behave. A REPL on the other hand is a runtime instance of your software that you can touch and interact with. Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context. In Ruby it's as easy as: require 'ruby-debug'; debugger In Python it's as easy as the following (add IPython to the mix for extra awesomeness): import pdb; pdb.set_trace() I'm working with Scala lately and doing the above is a little painful, but I still work with the REPL a lot, in spite of also using IntelliJ IDEA as an IDE. It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).
  - ryanjshaw 13y ago
    Huh. The Visual Studio Immediate window [1] has existed since the days of Visual Basic [2]. What are you guys seeing as a REPL that I'm not? [1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as... [2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).aspx http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...
cmccabe 13y ago
You don't really need a REPL when compiles take literally only a second or two. It's only the fact that C++ had a static type system where programs took (literally) hours to compile that made dynamic typing look so great in comparison. "Poorly designed static type systems drive people to dynamic typing," as Rob Pike said.
- stass 13y ago
  Dynamic typing has nothing to do with compilation speed. Furthermore, static typing is not orthogonal to dynamic; rather static type system is just another utility language on top of the actual language which helps to prove the correctness of the program. Such type systems can event be optional, see e.g. Clojure or Erlang.
- stass 13y ago
  And yes, REPL is still helpful even if the compilation is fast; amusingly most languages that have REPL features fast compilation (at least those not based on JVM). The benefit of REPL is that it preserves state which one can experiment on, and sometimes that state can be cumbersome/take long to acquire.
  - cmccabe 13y ago
    Most languages that have "traditionally" shipped with a REPL don't feature compilation at all. So yeah-- I guess that's fast? (Before you start, I'm not interested in pedantic arguments about how any language can be compiled. I know.) If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.
    - stass 13y ago
      One of the languages that originally featured REPL, Lisp, was always compiled, both to machine code or byte code. Ditto smalltalk. I am not even sure which "traditional" languages you are talking about. When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.
mseepgood 13y ago
> It's commonly believed that a REPL is valuable and increases productivity A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.
- girvo 13y ago
  Depends on the language and the programmer. I find a properly configured REPL amazingly productive at nearly any point in a development life cycle.
- simonw 13y ago
  I do almost all of my most productive programming in a REPL (Python/JavaScript programmer here) and I have done for nearly 10 years now.
- asdasf 13y ago
  You may not find it useful, but that doesn't mean it is a universal truth. I always have ghci open.
shurcooL 13y ago
Go makes it very easy to create tools on top of it. And its fast compiler enables doing things almost as if it's a dynamic language. I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use). There are other REPL-like tools like [2] and [3]. [1] https://github.com/shurcooL/Conception#demonstration https://github.com/shurcooL/Conception#demonstration [2] https://github.com/sriram-srinivasan/gore https://github.com/sriram-srinivasan/gore [3] https://github.com/shurcooL/goe#examples https://github.com/shurcooL/goe#examples

genwin 13y ago

Less is often more! I prefer the Go Playground over a REPL, especially since I can easily see others' code snippets running using the Playground's Share feature. My 2nd favorite thing about Go (after its runtime speed) is its compiler and excellent error messages that let me quickly realize what mistake I made.

throwaway344 13y ago

Statically typed languages don't necessarily not have a REPL, most functional languages are statically typed and yet they general have a REPL. OCaml, Haskell, F# and the like.

adriaanm 13y ago
Another example would be Scala. It has a command-line REPL and the IDE has a worksheet[1]. I find both tremendously useful. [1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-Started https://github.com/scala-ide/scala-worksheet/wiki/Getting-St...

benatkin 13y ago

Perl and PHP are also open source languages were people don't use repls often. Java and C# don't have repls either. I don't think everyone has ever thought they needed a REPL for any reasonable definition of everyone.

jodrellblank 13y ago
C# from Microsoft doesn't have a REPL, but C# with Mono does: http://www.mono-project.com/CsharpRepl http://www.mono-project.com/CsharpRepl
Tobu 13y ago
re.pl is invaluable to the modern Perl programmer (as is cpanm).
- benatkin 13y ago
  I don't think it's invaluable to the modern perl developer. I don't know whether I disagree with your concept of invaluable or your concept of modern perl developer or both. I tried searching "perl repl" on twitter and google to see if there's much talk about it and there doesn't seem to be much. AFAICT it just isn't a big part of the perl workflow, modern or not. Most of the people who like it could manage just fine without it. I don't think the same is the case with python or ruby. Some pythonistas and rubyists use the repl for everything. I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.
  - draegtun 13y ago
    The best place to search (for Perl REPL's) is on CPAN - https://metacpan.org/search?q=repl https://metacpan.org/search?q=repl The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL https://metacpan.org/release/Devel-REPL The new kid on the block is Reply - https://metacpan.org/release/Reply https://metacpan.org/release/Reply PS. I do find using a Perl REPL invaluable for me.

danenania 13y ago

I see go as essentially a polished and robust glue language. It's not particularly well suited to data processing because its lack of functional constructs and generics makes transforming lists verbose, but it's perfect for wiring up databases, apis, system calls, sockets, queues, and the like in a way that's safe, performant, and concurrent by default. Given this focus, it sort of makes sense why you might not miss a repl as much in go (though personally I do still miss it). Repls are most useful for exploring and experimenting with complex data, while I think go's focus is more on streamlining and bulletproofing all the machinery surrounding the data than doing a whole lot with the data itself. I don't mean this as a criticism and I'm not trying to say that you can't do serious data processing in go, just that it's not a core strength like it is in functional languages. I think the majority of applications out there actually have fairly light data processing needs and heavy glue needs, so go's set of tradeoffs make it a great candidate for tons of projects.

pcwalton 13y ago

> It's difficult for statically-typed languages to provide one. No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages. > there's no dynamic typing Yes, there is, through `interface{}`.

JulianMorrison 13y ago
The main thing stopping Go having a REPL (when there are ones for C, for example) is that Go can't yet compile to, or load, dynamic libraries. This stops each bit of REPL being compiled up and executed, which would otherwise be simple.
- pjmlp 13y ago
  And most likely never will, given the Go's team stance on dynamic linking.

tptacek 13y ago

Golang is like a touring car. It's fast, but doesn't have the fastest engine. It's got some nice features, and it's comfortable (at least for the driver), but it doesn't have every bell and whistle. But: the handling is amazing; it's a monster in the corners. You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that car. Same with Golang. They did an extraordinary job balancing the language, especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.

girvo 13y ago
Normally, if I see a car analogy applied to programming languages (which hackers seem to do a lot), I instantly brace myself for petty debate on the semantics of the analogy itself (which hackers seem to do a lot). This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).
asdasf 13y ago
>especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance. Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.
- tptacek 13y ago
  This is more "Internet article of faith" than actual fact; it's something people say because it was said in some blog post once. For whatever it's worth to you, I've been a systems programmer since ~1995. The lingua franca of systems programming is C; Golang's type system is strictly superior to C.
  - asdasf 13y ago
    It is more "direct observation" than "internet article of faith". I know one person who likes C and go. Every other go convert I know came from a scripting language. Golang's type system is strictly inferior to D.

laureny 13y ago

> Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages). There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's just not that useful when you have powerful IDE's at your disposal. Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.

tensor 13y ago
I routinely initialize quite complex states in the repl during development. If anything, it's even more important in that situation since it can often take a long time to get to that state-point in the program.
bad_user 13y ago
The REPL and IDEs are somewhat orthogonal. IDEs are extremely limited in fact, as they can only rely on static-type info to infer meaningful stuff about how your software will behave. A REPL on the other hand is a runtime instance of your software that you can touch and interact with. Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context. In Ruby it's as easy as: require 'ruby-debug'; debugger In Python it's as easy as the following (add IPython to the mix for extra awesomeness): import pdb; pdb.set_trace() I'm working with Scala lately and doing the above is a little painful, but I still work with the REPL a lot, in spite of also using IntelliJ IDEA as an IDE. It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).
- ryanjshaw 13y ago
  Huh. The Visual Studio Immediate window [1] has existed since the days of Visual Basic [2]. What are you guys seeing as a REPL that I'm not? [1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as... [2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).aspx http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...

cmccabe 13y ago

You don't really need a REPL when compiles take literally only a second or two. It's only the fact that C++ had a static type system where programs took (literally) hours to compile that made dynamic typing look so great in comparison. "Poorly designed static type systems drive people to dynamic typing," as Rob Pike said.

stass 13y ago
Dynamic typing has nothing to do with compilation speed. Furthermore, static typing is not orthogonal to dynamic; rather static type system is just another utility language on top of the actual language which helps to prove the correctness of the program. Such type systems can event be optional, see e.g. Clojure or Erlang.
stass 13y ago
And yes, REPL is still helpful even if the compilation is fast; amusingly most languages that have REPL features fast compilation (at least those not based on JVM). The benefit of REPL is that it preserves state which one can experiment on, and sometimes that state can be cumbersome/take long to acquire.
- cmccabe 13y ago
  Most languages that have "traditionally" shipped with a REPL don't feature compilation at all. So yeah-- I guess that's fast? (Before you start, I'm not interested in pedantic arguments about how any language can be compiled. I know.) If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.
  - stass 13y ago
    One of the languages that originally featured REPL, Lisp, was always compiled, both to machine code or byte code. Ditto smalltalk. I am not even sure which "traditional" languages you are talking about. When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.

mseepgood 13y ago

> It's commonly believed that a REPL is valuable and increases productivity A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.

girvo 13y ago
Depends on the language and the programmer. I find a properly configured REPL amazingly productive at nearly any point in a development life cycle.
simonw 13y ago
I do almost all of my most productive programming in a REPL (Python/JavaScript programmer here) and I have done for nearly 10 years now.
asdasf 13y ago
You may not find it useful, but that doesn't mean it is a universal truth. I always have ghci open.

shurcooL 13y ago

Go makes it very easy to create tools on top of it. And its fast compiler enables doing things almost as if it's a dynamic language. I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use). There are other REPL-like tools like [2] and [3]. [1] https://github.com/shurcooL/Conception#demonstration https://github.com/shurcooL/Conception#demonstration [2] https://github.com/sriram-srinivasan/gore https://github.com/sriram-srinivasan/gore [3] https://github.com/shurcooL/goe#examples https://github.com/shurcooL/goe#examples