This article, while very interesting, completely ommitted .NET CLR. Does anyone know how does the CLR compare to JVM, especially the new CoreCLR? How maturę is it in terms of using the best of breed JIT optimizations?
Graal and Truffle could accelerate programming language design
101–110 of 204 posts
Re: Graal and Truffle could accelerate programming language design
#102> 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 bee…
Some languages are better than others at certain things. By default, C is better than anything at low-level systems programming. Fortran can crunch numbers like nothing else. COBOL and BASIC are easy for novices, and BASIC is relatively simple to implement on low-end hardware, making it a natural choice for the early micros. Java is better than anything else at... well, no, Java sucks. And XML is even worse. Steve Yegge once noted that somehow, Ant and Jelly were less verbose than Java. And honestly, I'd believe it.
Re: Graal and Truffle could accelerate programming language design
#103Judging by LuaTruffle, the Lua example, then this framework is useless. LuaTruffle appears to implement the syntax of Lua but none of the semantics. For example, no metatables and no coroutines. Lua is unparalleled in its support of coroutines, and metatables are what make optimizing Lua _difficult_. Without implementing either of those things you've neither demonstrated the ability of the framework to implement nove…
LuaTruffle has a few hours work by an casual non-expert external person. If you want to know about how well we can implement the semantics of an existing language then look at JRuby+Truffle - it passes more Ruby language tests than any other alternative Ruby implementation. The only stumbling block is co-routines as the JVM doesn't have these and they're hard to implement efficiently with other constructs.
Oh, only co-routines? So you've implemented callcc already?
Re: Graal and Truffle could accelerate programming language design
#104Earlier quoted context omitted.
Right, and my point is that the reason people continue to use C++ or Rust over JVM languages is because there are some use-cases where the JVM's decision about how to map the logical layout onto physical memory causes unacceptably high memory usage and/or cache misses, or prevents them from taking advantage of clever serialization formats (Cap'n Proto, for example, loses much of its performance benefits on the JVM wi…
The default when running static languages like C++ or Rust or Go via Sulong is to stick to the memory layout chosen by the programmer. There is no conversion to typical JVM memory layouts. Nor does running on the JVM has major restrictions for the framework (we are working on a version that does not run on the JVM in the SubstrateVM project). What Graal+Truffle allows is for library writers and language designers to…
Interesting. So, if I'm understanding this correctly - Truffle allows a language designer to specify a certain logical layout for data structures, along with hints for how this will get converted to a physical memory layout. Language implementors also get the full power of Graal for lowering their AST to machine code and other compiler tasks. On cross-language boundaries, it generates automatic accessors for other languages to access that data, using the logical layout to identify how particular fields need to be pulled out and manipulated, but not requiring that the full data structure be converted across the foreign-call boundary. One consequence of this is that nesting & embedding of data structures may require an explicit conversion, since if an object is a hashtable in Javascript but a packed series of fields in C, it's obviously not going to fit.
Sorta like SWIG++? If you could do SWIG but never require that an end-user write a typemap or debug a crash themself, there'd probably be a big market for that.
Re: Graal and Truffle could accelerate programming language design
#105Before anyone gets too excited, make sure you look at what a compiler using Truffle actually looks like, and remember that Java is far from an ideal language for writing a compiler. I'll use their SimpleLanguage (their primary tutorial lang) as an example. Parser [1] shows how lack of sum types makes code messy. Lots of "factory.createStringLiteral" kind of calls. At least Java has a mature parser generator. Implemen…
Urrgh. This just reminds me of why I gave up on android app development, and the JVM ecosystem as a whole: it tests my ability to put up with bullshit.
Re: Graal and Truffle could accelerate programming language design
#106Before anyone gets too excited, make sure you look at what a compiler using Truffle actually looks like, and remember that Java is far from an ideal language for writing a compiler. I'll use their SimpleLanguage (their primary tutorial lang) as an example. Parser [1] shows how lack of sum types makes code messy. Lots of "factory.createStringLiteral" kind of calls. At least Java has a mature parser generator. Implemen…
Partial Evaluation requires very precise knowledge of the bytecodes which are feeded into it. Having eg. Scala abstractions showing up suddenly would be quite annoying. Java is closest to bytecodes thats why we use it for Truffle interpreters.
Re: Graal and Truffle could accelerate programming language design
#107Earlier quoted context omitted.
if the industry were really striving for perfection, there would be no COBOL or BASIC, for instance. COBOL was a huge improvement at the time, an innovation in readability. BASIC is a good demonstration of why the platonic ideal language is wrong: it was designed for beginners (that's what the acronym stands for), and it did a reasonably good job at that. Beginners might be overwhelmed by OOP, multiple dispatch and a…
> BASIC is a good demonstration of why the platonic ideal language is wrong That's often my point when people bring up arguments against a language that seems a bit more complex (Perl), or for language simplicity (Python). Some complexity falls into a sliding scale where there is more cognitive load while learning, but it pays of in the every day usage. The siple example of an extreme end of this is APL. If you can i…
> If you can internalize and understand the extremely concise and powerful syntax and semantics of the language (I haven't), you can do amazing things very quickly
Not to mention figuring out how to type APL -- that's where I got stuck.
Re: Graal and Truffle could accelerate programming language design
#108Judging by LuaTruffle, the Lua example, then this framework is useless. LuaTruffle appears to implement the syntax of Lua but none of the semantics. For example, no metatables and no coroutines. Lua is unparalleled in its support of coroutines, and metatables are what make optimizing Lua _difficult_. Without implementing either of those things you've neither demonstrated the ability of the framework to implement nove…
LuaTruffle has a few hours work by an casual non-expert external person. If you want to know about how well we can implement the semantics of an existing language then look at JRuby+Truffle - it passes more Ruby language tests than any other alternative Ruby implementation. The only stumbling block is co-routines as the JVM doesn't have these and they're hard to implement efficiently with other constructs.
Does that kinda throw off the whole concept about pushing language design if you can't do coroutines?
That's a pretty critical feature of Lua that somewhat defines it(along with it's low overhead + embeddability, both of with you won't get with the JVM).
It seems like engineers always want to build One Tool to Solve Them All(tm) and yet there are always tradeoffs to be made. The reason 90% of this industry is still employed is because we don't have these one size fits all problems that we'd so love to solve.
Re: Graal and Truffle could accelerate programming language design
#109The 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…
I think we should start to see post-Java9 a less resource intensive JVM, even more so with Java10. The problem boils down to if there exists an alternative ecosystem that is going to be as featureful and as powerful in the meantime. I am bullish on Oracle here, as much as I hate to say it
yeah java9/10/11 stuff is probably a little bit late.
Re: Graal and Truffle could accelerate programming language design
#110Earlier quoted context omitted.
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/
Neat, I missed this when originally posted. Sadly, it falls apart on the "cross-platform" requirement (does not appear to support Windows).
[deleted]