Live data from Hacker News

Graal and Truffle could accelerate programming language design

medium.com

21–30 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#21

The Oracle flavors of the JVM/JDK probably scare too many away with regards to redistribution of their product. That coupled with the fact that things like the AOT engine is closed source and the weight of the JVM for anything besides daemons (both mentioned towards the end of the article) probably keep language designers away these days. I would love a lightweight toolkit that made for easy language development. VMK…

check out RPython.

I should have mentioned one of my wants was a pluggable type system. Maybe not a full type inferencing component (that would be nice!) but at least static typing at the IR level.

Re: Graal and Truffle could accelerate programming language design

#23
post #12
post #9

Earlier quoted context omitted.

I work with .NET, Java and C++ stacks. In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. The biggest issue is of course than one needs to learn how to optimize code, use the right algorithms and data structures in first place.

I agree mostly. Any Java application which does not need GUI other than web is just fine in most use cases.

UIs though...

I haven't worked with a single Java based GUI application that did feel smooth, fast and efficient.

I wonder why that is.

Re: Graal and Truffle could accelerate programming language design

#24

The Oracle flavors of the JVM/JDK probably scare too many away with regards to redistribution of their product. That coupled with the fact that things like the AOT engine is closed source and the weight of the JVM for anything besides daemons (both mentioned towards the end of the article) probably keep language designers away these days. I would love a lightweight toolkit that made for easy language development. VMK…

QBE[1] seems to be what you're looking for. It "aims to be a pure C embeddable backend that provides 70% of the performance of advanced compilers in 10% of the code".

Previous discussion on HN: https://news.ycombinator.com/item?id=11555527

[1]: http://c9x.me/compile/

Re: Graal and Truffle could accelerate programming language design

#25
post #16
post #10

Earlier quoted context omitted.

I believe those benchmarks are for throughput, though. JS VM startup times (including v8) are highly optimized, while Graal+Truffle run on the JVM which is more optimized for sustained speed. JS VMs also tend to have multiple tiers for that reason - interpreter, baseline, and full JIT, etc. - while AFAIK the Graal+Truffle/JVM approach has just 2 (which is optimal for Java, but not for startup times of JavaScript and…

Startup times are mostly important for scripting or running things in the browser. If you start applications once on the server or desktop and keep them running then steady-state performance is more important. There also are projects underway to bring AOT compilation / caching of compiled code to the JVM. Right now they're only available to commercial customers due to their experimental nature and the needed support…

True about AOT coming to the JVM, however, dynamic languages can't be AOT'd well in general, so that won't help Graal+Truffle languages much.

Instead, dynamic languages tend to do tiering, which in principle is something Graal+Truffle could do, but it might be a lot of work.

Re: Graal and Truffle could accelerate programming language design

#27
> Since the dawn of computing our industry has been engaged on a never ending quest to build the perfect language.

Except it really hasn't. The industry is going to use whatever language has the bare minimum feature set they value at the moment and no more.

Call me cynical but my point of view is: if the industry were really striving for perfection, there would be no COBOL or BASIC, for instance. Lisp had already been invented. Garbage collection was a thing already. We had macros. A REPL. A little later, OOP and multiple dispatch. The list goes on.

They had to ditch the (almost) perfect wheel for a cheaper square one. Fast forward a few years, and the square wheel is now polished but just as square, the insanely great wheel now just is as cheap as it is, but we won't use it, as the axles expect the square wheel.

And then we invent Java and XML...

Re: Graal and Truffle could accelerate programming language design

#28
post #22

> A way to create a new language in just a few weeks As a Lisp programmer, I regularly create new languages in a matter of hours.

Do you mean macros? Could you re-implement a language such as C as a macro? And have it be about as fast as GCC? I didn't think they were that sophisticated.

Re: Graal and Truffle could accelerate programming language design

#29
Ask HN via comment hijacking due to the Ask HN post also failing with various errors:

I want to submit a story about WhatsApp being blocked in Brazil, again.

My first attempts told me I was submitting too fast (but I didn't submitted anything in a LOOOONG time... I am slow-banned or something?)

Then I thought it was a bug due to me having a invalid character in the title, when I attempted to submit it again with the title fixed, it only upvoted another person submission... that had wrong title.

I tried to make a comment with the right title, I got a message: "You cannot comment here".

I then tried to load the comments page, and the submission was deleted :/

So I then tried to submit again, this time I got "already submitted".

So... what is going on HN, why I can't submit it?

EDIT: please don't downvote/flag before someoen reply... I couldn't find another way to get in contact.

EDIT2: Can some mod delete this post? I am getting downvoted a lot :(

Re: Graal and Truffle could accelerate programming language design

#30
post #22

> A way to create a new language in just a few weeks As a Lisp programmer, I regularly create new languages in a matter of hours.

I'm vaguely familiar with Lisp, but I'm not a Lisp programmer. Can you explain this comment?

Lisp languages are easy to build because of their simple syntax. It's also easy to use a Lisp to build a Lisp, since it is homoiconic (this is what you're doing with the macro system.)
Post reply on HN