Hacker News Reader

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.

> 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{}`.

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.

And most likely never will, given the Go's team stance on dynamic linking.

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.

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).

>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.

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.

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.

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

[2] https://github.com/sriram-srinivasan/gore

[3] https://github.com/shurcooL/goe#examples

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.

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-St...

> 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.

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.

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).

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).as...

[2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...

Well, it's difficult to see what a REPL is or does, if you're calling Visual Studio's "Immediate Mode" a REPL. It's not. It can evaluate simple expressions, but you can't type arbitrary code in it and hence you can't do arbitrary development in it, so it's not a REPL.

The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.

> The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.

So what?! Languages and implementations are not the same thing.

Err, what?

So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.

Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's the community's culture like?

Lately I've been learning some Clojure. I'm fascinated by how Clojure developers work with the source-code. Emacs is an extremely capable editor, but for Clojure it's a full-fledged IDE and a shell for the REPL and it can do anything you'd expect from an IDE. And the whole workflow is basically typing code, sending that piece of code for evaluation in the REPL, typing in the REPL some quick invocations to see how it works, rinse and repeat. The learning experience is also completely awesome, as for some reason you end up reading a lot of the standard library's implementation - coupled with the REPL on the other side in which to quickly type what you read - the workflow is amazing (though Smalltalk developers are probably laughing at me right now).

> So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.

Reference implementations only define languages that lack a proper ANSI/ISO/ECMA standard.

> though Smalltalk developers are probably laughing at me right now

Yes we are. :)

Emacs is a light version of a Lisp Machine. Now imagine how would your OS be, if everything would be as customizable as Emacs.

Sadly, Lisp machines and Smalltalk environments died on the mainstream.

LinqPad isn't bad.

There is a c/c++ repl http://root.cern.ch/drupal/content/cling .

For java there is bean shell/groovysh which isn't quite as good.

There is a mono repl and there is linqpad for c#. Ive used linqpad and it is very usefull.

scala worksheets are also very cool.

> 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.

This is why we Lisp developers have networked REPLs -- I can start up a remote JVM, in communication with other services, connected to my local vim session. I can dynamically load code into it, start and stop my application, etc, all from my editor.

https://github.com/clojure/tools.nrepl

> Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages).

C# ==> http://www.mono-project.com/CsharpRepl

C++ ==> http://root.cern.ch/drupal/content/cint

C ==> http://www.softintegration.com/demos/chstandard/interactiveC...

Java ==> http://www.javarepl.com/console.html

People, please pay attention in compiler design classes and don't mix languages with implementations.

Also, the "Display" tab in Eclipse lets you execute random code while you are attached to a JVM via debugging, in the current breakpoint context - that is like 95% of a repl, imho. Many people don't know this one, and its very useful.

> The importance of REPL is very exaggerated.

I constantly use REPLs to experiment, verify output of functions, etc. In the case of Go I open the Go Playground at least once a day, often much more.

That's a very large blanket statement right there. I code in five main languages Objective-C, Java, Python, Ruby, and a bit of Javascript. I do back-end web system type of dev work (Python, Ruby, JavaScript, Java) and front end UI (iOS, Android, and JavaScript (Backbone, Angular, Ember). I use Intellij and sublime as my ide/code editor. The most productive, easiest to use, and for me most fun to develop in environments are Django, Rails, Node, and front-end JavaScript. That is almost completely because of the application aware REPL. Django's manage.py shell command, Rails rails console command, and Chrome's dev tools are three of the most important developer tools I've ever discovered. I'd LOVE to find an iOS tool with the same power.

Like another commenter posted, REPLs are best suited for exploration. When you've got data and you're not quite sure what to make of it, or you want to do with it yet. IDEs, while also having their place, do not really fill that gap in any way.

I often find myself exploring in a language with a good REPL and then implementing the findings in a language that does not.

> 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.

Depends on the language and the programmer. I find a properly configured REPL amazingly productive at nearly any point in a development life cycle.

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.

You may not find it useful, but that doesn't mean it is a universal truth. I always have ghci open.

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.

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.

C# from Microsoft doesn't have a REPL, but C# with Mono does: http://www.mono-project.com/CsharpRepl

re.pl is invaluable to the modern Perl programmer (as is cpanm).

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.

The best place to search (for Perl REPL's) is on CPAN - https://metacpan.org/search?q=repl

The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL

The new kid on the block is Reply - https://metacpan.org/release/Reply

PS. I do find using a Perl REPL invaluable for me.

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.

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.

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.

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.

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.