4 ms·

I work at Oracle Labs where GraalVM (graalvm.org) is being developed. I think this is one of the most exciting places to be right now for compiler engineers, an

I work at Oracle Labs where GraalVM (graalvm.org) is being developed. I think this is one of the most exciting places to be right now for compiler engineers, and people with the right skills are certainly in demand. Some things that came out of this: partial escape analysis, the Graal JIT compiler, SubstrateVM, native-image, several Truffle language implementations (JS, Ruby, Python, LLVM), IGV for visualizing different layers of IRs, integrating GraalVM in the Oracle Database (MLE).

exikyut 7y ago
Basic/naive/stupid question that I've been genuinely curious about for a little while now: What are the real-world motivations behind reimplementing the noted languages on top of Truffle? These projects are frankly incredible - hundreds (thousands) of total man-years of work - and all to _re_build something that already exists. I'm missing context that I don't know where to look for. Is there anywhere I might look online to immerse myself in the relevant discussion of the business use cases that drive these types of huge projects?
- gravypod 7y ago
  Communicating or interfacing massive legacy code bases together. You can write python code and call it from Ruby code in a slightly, but livable, way. Also eventually I'm assuming there's some plans to compile these other languages with native-image. In my eyes native-image is Java's response to golang: reasonably sized small binaries that are perfect for containerization and quick to elastically scale up/down (startup time).
- thu2111 7y ago
  Truffle languages don't require hundreds or thousands of man years of work. That's the point of them: implementing a language on Truffle is very easy compared to writing something like V8. You "just" write an interpreter and then extra code after that is about performance. Most of the Truffle languages have small teams, like 2-3 engineers tops, and that's sufficient to catch up with and then keep pace with even a well funded ecosystem like JavaScript. For instance the GraalJS team keep adding proposed JS language features that aren't even fully rolled out yet. As for why, well, Truffle languages have a bunch of advantages over implementing engines in other ways: - They all interop with each other, with JVM bytecode languages, with anything that compiles to LLVM, and anything that runs on WebAssembly. All in the same VM with the same heap (i.e. they can all use pointers to each others constructs). - You get access to HotSpot and in particular its state of the art GCs. - Graal is an excellent compiler. V8 is better but only for JavaScript and only in warmup time; once code is warmed up (for servers) GraalJS produces code just as good as V8. - You get a lot of sophisticated visualisation and debugging tools, both to help you develop and optimise the language (IGV) but also to analyse programs in production (VisualVM, JFR). - You can support native extensions using [Safe] Sulong. - You get debugger support for free, because Truffle languages all support the Chrome DevTools debugger protocol. - They just added support for the language server protocol so you get some automatic support for IDEs. - You get a consistent sandboxing API for free. - Probably a lot of other things I forgot. So you get a better engine than most languages can afford, for way less cost, with way more features and access to a huge ecosystem of libraries from all the different languages. Pretty snazzy.

exikyut 7y ago

Basic/naive/stupid question that I've been genuinely curious about for a little while now: What are the real-world motivations behind reimplementing the noted languages on top of Truffle? These projects are frankly incredible - hundreds (thousands) of total man-years of work - and all to _re_build something that already exists. I'm missing context that I don't know where to look for. Is there anywhere I might look online to immerse myself in the relevant discussion of the business use cases that drive these types of huge projects?

gravypod 7y ago
Communicating or interfacing massive legacy code bases together. You can write python code and call it from Ruby code in a slightly, but livable, way. Also eventually I'm assuming there's some plans to compile these other languages with native-image. In my eyes native-image is Java's response to golang: reasonably sized small binaries that are perfect for containerization and quick to elastically scale up/down (startup time).
thu2111 7y ago
Truffle languages don't require hundreds or thousands of man years of work. That's the point of them: implementing a language on Truffle is very easy compared to writing something like V8. You "just" write an interpreter and then extra code after that is about performance. Most of the Truffle languages have small teams, like 2-3 engineers tops, and that's sufficient to catch up with and then keep pace with even a well funded ecosystem like JavaScript. For instance the GraalJS team keep adding proposed JS language features that aren't even fully rolled out yet. As for why, well, Truffle languages have a bunch of advantages over implementing engines in other ways: - They all interop with each other, with JVM bytecode languages, with anything that compiles to LLVM, and anything that runs on WebAssembly. All in the same VM with the same heap (i.e. they can all use pointers to each others constructs). - You get access to HotSpot and in particular its state of the art GCs. - Graal is an excellent compiler. V8 is better but only for JavaScript and only in warmup time; once code is warmed up (for servers) GraalJS produces code just as good as V8. - You get a lot of sophisticated visualisation and debugging tools, both to help you develop and optimise the language (IGV) but also to analyse programs in production (VisualVM, JFR). - You can support native extensions using [Safe] Sulong. - You get debugger support for free, because Truffle languages all support the Chrome DevTools debugger protocol. - They just added support for the language server protocol so you get some automatic support for IDEs. - You get a consistent sandboxing API for free. - Probably a lot of other things I forgot. So you get a better engine than most languages can afford, for way less cost, with way more features and access to a huge ecosystem of libraries from all the different languages. Pretty snazzy.