
An obscure research project could accelerate innovation in language design - phreeza
https://blog.plan99.net/graal-truffle-134d8f28fb69#.2j7ev3wf6
======
Athas
When I think of "innovation in language design", I don't really think of JIT-
compiling highly dynamic behaviour. I think of inventing languages with
programming models that can be used for programming the heterogeneous hardware
of the future (and, well, present). For example, massive parallelism is needed
for both GPUs, FPGAs, clusters, and other more exotic systems, and the trick
becomes how to translate portable and high-level problem descriptions to, say,
highly vectorised code for GPUs, deep FPGA pipelines, or asynchronous message-
passing cluster code.

You can't solve that with JITs. From what I have seen, JITs are very useful
for taking away the overhead of indirect calls and similar dynamic behaviour,
but I don't think that's going to be the primary language design challenge of
the future. No compiler can (usefully) extract significant amounts of
parallelism from an algorithm which has none, and current programming models
are not particularly convenient for expressing parallel algorithms. While
current languages allow you to express parallelism by using low-level
features, the resulting program will invariably be non-portable. High-level
parallel languages (or maybe libraries) are the only solution I can see.

~~~
goatlover
Why do you need that outside of gaming and numerical computing? Most software
above the system level doesn't need to be super performant, or highly
parallel. It's fast enough. We got by with far less resources a decade ago,
and still ran a lot of the same software. Why would we need to port all that
over to GPUs, etc?

~~~
Athas
Numerical computing is important for science in general, and really hard. But
if you're perfectly fine with the current state of software, then sure,
there's no need to change anything. Future CPUs will gain an increasing amount
of their performance from parallelism - both coarse- (more cores) and fine-
grained (better vector units), but there is no _reason_ we have to exploit it.
I suspect many people will want to, however, and they will likely find current
programming models somewhat awkward.

------
chubot
Nice article, especially the section on downsides at the end.

A lot of VM design is at the expense of memory consumption over speed. Not
just the JVM, but I think v8 memory usage got out of control recently and they
had to go back to an interpreter in some cases.

VMs in the future should probably be optimized for power. More memory usage
means more power usage. It matters both on mobile devices and in data centers.

The startup time issue is annoying as well. I like the general idea, but
making startup time even worse than the JVM itself makes it unattractive.

~~~
chrisseaton
If you want to reduce the time required to handle an individual request in a
given program that you already have there's not much you can do automatically.
You can't use a processor that's twice as fast because if you are already
using a modern system we don't have one of those. You can't use two processors
as we don't really know how to parallelise effectively enough in general
cases. But you can double the RAM in a system with reasonable effort and cost.

The startup time issue is being solved with ah ahead-of-time Java compiler
with whole-world analysis that we are developing. It runs hello-world in our
Ruby implementation in about 100ms, which is an order of magnitude faster than
the normal JVM.

~~~
chubot
OK, if those are your design constraints, then that's fair. I'm just
questioning how widely those constraints will apply in the future.

I'm pretty sure the v8 changes were motivated by phones, so maybe there is
room for another project like Graal and Truffle with a different set of
constraints.

Also, for web services in particular (not sure if that is a major use case), I
would question the view of making individual requests faster. I recall Steve
Souders said he was a back end guy at Yahoo working on latency, and then he
switched to front end performance because he found that the front end was
eating up all the time.

In my experience this is too true. In other words, if you had a server where
requests were taking 100 ms, and you made them take 50 ms through VM design,
you would be a hero! But somehow front end engineers are still constructing
pages with 10 - 30 full seconds of latency (especially on mobile) out of back
end requests that take 100ms. There's just a lot more room to optimize there,
whereas sometimes I feel like VMs are trying to squeeze blood out of a stone.

And I agree that there will be demand for such a "black box" approach, where
you just take an arbitrary program and make it faster. But I'm interested in
overall system performance, and in that case, a little bit of application
knowledge can work wonders. One of my pet peeves is that often performance
tools like time and space profilers are sort of an afterthought that
programmers use only when they have problems. They write this huge spagehetti
of allocation, and then 2 years later they start tuning the GC.

This is partly the fault of programmers and partly the fault of the language
ecosystem. It would be nicer if the language exposed integrated tools. I dont'
know that much about the JVM ecosystem, but they always feel like a "separate
thing" you have to go research and choose and download and install. I think
Go's tooling is a good example here.

Anyway, I think this is an interesting project. In particular I think the
focus on polyglot programming is fantastic. I too feel the pain of enormous
amounts of duplicated work -- e.g. even at say Google with a relatively small
set of languages like C++, Java, and Python, there were still all these
separate "worlds" and gradually engineers became sequestered in their own
world. IMO Go made things worse and not better -- it was yet another native
runtime that didn't even interoperate all that well with C++, let alone Java
or Python!!!

------
hacker_9
" _Graal is designed from the start as a multi-language compiler, but its set
of optimisation techniques is especially well suited to compiling programs
with high levels of abstraction and dynamism. It runs Java as fast as the
existing JVM compilers do, but when applied to Scala programs it runs them
about 20% faster. Ruby programs get 400% faster than the best alternative
runtime (i.e. not MRI)._ "

Pretty amazing claims being made here, but I do like the idea of it. Build up
your language grammar, then get a compiler, debugger and runtime for basically
free. Definitely will have to play around with this soon.

------
lilott8
JetBrains has something that is similar to this: MetaProgramming System
(MPS)([https://www.jetbrains.com/mps/](https://www.jetbrains.com/mps/)). It
resides exclusively within the context of Java (so DSL) -- so it's not as,
shall we say, far reaching as Graal and Truffle claim to be?

It works really well though; abstract the complexities of the AST through the
use of various different methodologies so that designers can do what they do
best, design. The shortcomings, I'd imagine, are the same with MPS in-so-much
that the limitations imposed are defined by the system. And when you run into
those boundaries, they are hard and unforgiving -- much like trying to use
Python in a non-pythonic manner.

~~~
mike_hearn
MPS is rather different. I've played with that too, perhaps it should be the
topic of another essay.

MPS is fascinating because it lets you create non-text based programming
languages and have them actually interop with text based programming in a
useful way.

------
fritzo
Another perspective is that Graal & Truffle prove that a large swath of
programming language space is semantically equivalent, suggesting that we
shift focus of innovation elsewhere.

------
gwenzek
The question is can you create a language like Scala with it? Ie with complex
type inference? Or Haskell? Because if it constrains you to Java like
languages, I don't see this as "innovation in language design".

~~~
jerven
This is the execution layer, i.e. how is that Scala program turned into
machine code. You can make a Haskell implemented using Truffle. Or Rust etc...
Haskell, defines the semantics of a program, while truffle turns that
semantics into executable code.

------
JackC
Previous discussion of this article when it was hosted at Medium:
[https://news.ycombinator.com/item?id=12122557](https://news.ycombinator.com/item?id=12122557)

~~~
mike_hearn
It's actually still hosted by Medium, I just got around to setting up a custom
domain as I noticed a few people saying they've learned to associate the
medium.com domain with low quality writing. That's a pity, but at least it's
easier to move off Medium now when something better comes along (or they go
bankrupt).

------
nottorp
[quote]

Graal & Truffle are a product of Oracle Labs, the part of the Java team which
does VM and compiler research.

[/quote]

So if a language using this becomes successful, Oracle will hit you with an
intellectual property lawsuit?

~~~
mike_hearn
It's mostly under open source licenses, and such licenses tend to discuss
patents don't they.

The Google lawsuit was partly because they didn't use the actual Java source
code so they didn't benefit from those open source licenses. But bear in mind:

• Google won, Oracle lost, multiple times. I'm guessing they won't try that
again.

• Google has since switched _to_ the OpenJDK source code, not away from it.
They are now actually working _more_ closely with Oracle, not less.

Weird I know, but that's how it's played out.

~~~
nottorp
Actually no, most open source licenses have no mention of patents.

If you're smaller than Google, dealing with Oracle might be outside your
budget. Safer not to.

~~~
jerven
If its patents you are worried about, not dealing with someone won't protect
you from their lawyers.

~~~
nottorp
It's Oracle's general attitude. While not going anywhere near their products
won't protect you from a patent lawsuit, it _is_ some protection. They can't
sneak in some commercial components and bill you later, for example.

