Hacker News Reader

Comment by kernyan | Hacker News Reader

>I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL.

I am most excited about this, where a language supports two modes 1) interpreter for development, and 2) compilation for performance. Never thought about this, but reading this, it makes perfect sense on large projects

View on HN

I'm a fan of Go's "go run". For example, you can do:

  go run main.go

or:

  go run ./cmd/server

When invoked this way, Go compiles your code behind the scenes, but you don't have to create a binary.

This means Go lends itself pretty well to ad-hoc scripting or writing small script-like tools.

Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can:

    #!/usr/bin/env gorun

    package main

    func main() {
      println("Hello world!")
    }

[1] https://github.com/erning/gorun

D's default package manager already allows you to write code like this which 1. runs the code like a script 2. downloads dependencies if they are required.

    #!/usr/bin/env dub
    /+ dub.sdl:
        name "allthepythons"
        dependency "d-glob" version="~>0.3.0"
    +/

    import std.stdio : stdout;
    import glob : glob;
    
    void main () {
        foreach (entry ; glob("/usr/local/bin/python*")) {
            stdout.writefln("%s", entry);
        }
    }

Dub's documentation should use some love...

D already works like this.

Scala (Ammonite) works like this.

The author isn't complaining about keystrokes; he wants the compile + run process to be faster. Using an interpreter instead of a compiler would make it faster.

Java has the same now (since Java 9 I think).

So you're saying it's as simple as:

java build ./app/ ./app

That's impressive if true as last I worked with Java it was a mess

Not quite. You can run `java Foo.java` and it will compile and execute the class file (and remove it when done).

D compilers do work as a shebang already.

I actually use this for all of my complicated build scripts and just use make to glue them together. For instance I have a stack name from computer,branch,sha,username that I calculate so I have a different stack per thing I'm working on. I tried getting that to work with awk fu but doesn't work the same on every platform, so instead "go run cmd/get_stack_name/main.go" instead. Fast and like it.

OCaml works like that

Haskell too.

Add Flutter to the bunch - having a fast interpreter is especially pleasing when the result is an instant visual change the app running on an emulated android phone.

Java can do this via AOT or partially also JIT compilation.

For AOT there is this JEP: https://openjdk.java.net/jeps/295 and a different project: the GraalVM

Java could do this always, as it's a compiled language (the important thing here is interactivity vs. compilation, not JVM vs. native).

So I'd say that Java can do "this" since recently (JDK 9 in 2017) via JShell (I wouldn't count BeanShell or Groovy), i.e. it always had the compiler part but added the interpreter.

Although its usage is still quite rare, whereas the blog post would suggest a different pattern.

As addendum, Java has had support for AOT since around 2000, the only caveat is that it has been a feature only available on third party commercial JDKs.

GCJ improved very slowly and around 2009 lost most of its developers with the release of OpenJDK.

JIT runtimes try to give you both.

It starts interpreted, but if you run for very long, it runs compiled.

But that costs memory and startup time.

Most JIT runtimes also can't produce a standalone binary

Pretty much all JITs have tools for standalone binaries.

People usually don't do it because JITs are heavy so they'd prefer to share them.

Reply on news.ycombinator.com