6 ms·
>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 unitt
by kernyan 7y ago
>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
- karussell 7y agoJava can do this via AOT or partially also JIT compilation. For AOT there is this JEP: https://openjdk.java.net/jeps/295 https://openjdk.java.net/jeps/295 and a different project: the GraalVM
- pjmlp 7y agoAs 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.
- mhd 7y agoJava 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.
- scns 7y agoOCaml works like that
- buckminster 7y agoHaskell too.
- schwurb 7y agoAdd 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.
- atombender 7y agoI'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 https://github.com/erning/gorun
- floatboth 7y agoD compilers do work as a shebang already.
- paulddraper 7y agoD 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.
- apta 7y agoJava has the same now (since Java 9 I think).
- btbytes 7y agoD'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); } }
- paulddraper 7y agoJIT 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.
- zucker42 7y agoMost JIT runtimes also can't produce a standalone binary
- paulddraper 7y agoPretty 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.