Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graal and Truffle could accelerate programming language design

medium.com

Post reply on HN
Print view View original

121–130 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#121

Post by qwertyuiop924 »

dragonwriter wrote: post #117
qwertyuiop924 wrote: post #116

Earlier quoted context omitted.

Well, for regular macros, only if your C syntax was in a string. Otherwise, lisp would try to tokenize it, and choke. Heck, if your lisp of choice offers an eqivalent of TCL's uplevel, you wouldn't even need a macro, just a function.

> Well, for regular macros, only if your C syntax was in a string. Otherwise, lisp would try to tokenize it, and choke. Which is why I said normal (rather than reader) macros could do a "basically C-like syntax" but with Lisp tokenization rules.

What would that look like?

Re: Graal and Truffle could accelerate programming language design

#122

Post by grashalm »

vvanders wrote: post #108
chrisseaton wrote: post #92

Earlier quoted context omitted.

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 e…

There was a patch for coroutines on the JVM some time ago. Unfortunatly it did not make it into the platform. No reason why it could not be added to the JVM.

SubstrateVM solves the embeddability part.

Re: Graal and Truffle could accelerate programming language design

#123

Post by vvanders »

grashalm wrote: post #122
vvanders wrote: post #108

Earlier quoted context omitted.

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 e…

There was a patch for coroutines on the JVM some time ago. Unfortunatly it did not make it into the platform. No reason why it could not be added to the JVM. SubstrateVM solves the embeddability part.

Info out there on SubstrateVM looks a little sparse.

For context we use to run VM + tuneable data + game logic code in a 400kb block allocated to Lua on the PSP. I'd love to hear how SubstrateVM compares. Lua has a really rich history of being embedding in some pretty small targets.

Re: Graal and Truffle could accelerate programming language design

#124

Post by pjmlp »

bitmapbrother wrote: post #120
pjmlp wrote: post #82

Earlier quoted context omitted.

Measure Java performance by how Android works is not a good measure. Dalvik is well known on Java world for having a JIT and GC implementations that worse than what most commercial embedded JVM are capable of. Things have improved with ART, but even there there are quite a few performance improvements that Google could eventually do. Soft real time Java GCs for embedded devices are being used in ground station contro…

>Even Windows Phone has better support for it, and they do have WinRT and .NET on them. No they don't. Point me to one windows phone audio app that has low latency audio.

Well there are these sources from Microsoft:

https://blogs.windows.com/buildingapps/2014/05/15/real-time-...

https://rtaudiowsapps.codeplex.com/

https://channel9.msdn.com/Events/Build/2014/3-548

And I just found this, but not sure how good it fares.

https://www.microsoft.com/en-us/store/apps/audio-meter/9wzdn...

Re: Graal and Truffle could accelerate programming language design

#125

Post by thomaswue »

nostrademons wrote: post #104
thomaswue wrote: post #97

Earlier quoted context omitted.

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 la…

Yes, this is an excellent description.

Re: Graal and Truffle could accelerate programming language design

#126

Post by trishume »

chrisseaton wrote: post #95
ilostmykeys wrote: post #72

Funny, I posted this yesterday and got no up votes. Can you post a duplicate of some post and get up voted? I didn't realize that was possible.

Take a look at the Medium URLs and you'll see they have a fragment ID and so count as different submissions.

I wondered why this didn't get merged with my submission. Makes a neat example of how random getting on the HN front page is though. Although I'm sad that randomness chose to give the second posting karma instead of mine.

Re: Graal and Truffle could accelerate programming language design

#127

Post by kovrik »

qwertyuiop924 wrote: post #100

Okay, very cute, but what if you want your language to have significant semantic differences from C and the like? What if you want to write a Scheme interpreter, for instance? Can I have Continuations? Can I have Tail Call Optimization? I very much doubt it. If you want to write a language that is semantically like C for the most part, than go ahead and use Truffle, but that's not where interesting language design is…

Don't know why you get downvoted. That's exactly what I thought.

Java is my main lang and currently I'm working on my hobby project - implementing Scheme r5rs in Java. That is hard! And I doubt I'll be able to implement full r5rs even close.

I have no idea (yet) how to implement Continuations: In theory yes, you can implement Continuations in any lang which has Exceptions (the only way in Java to unwind a stack).

Like: https://www.politesi.polimi.it/bitstream/10589/108685/3/2015...

Proper TCO:

AFAIK it is impossible in general case in object-oriented lang. That is one of the reasons why Rich Hickey decided to have explicit recur in Clojure,

Yeah, you can implement your own stack and stop using Java's stack, but then you lose performance and interop: "Interop, speed, TCO -- Pick two." Rich Hickey

See https://news.ycombinator.com/item?id=4922848

Then Full Numeric Tower is hard! Mostly due to the fact that Java's type system is not strong enough.

I think Kawa is the best implementation of Scheme for JVM you can get now.

But even Kawa has some limitations (due to JVM limits): https://www.gnu.org/software/kawa/Compatibility.html

Re: Graal and Truffle could accelerate programming language design

#129

Post by pjmlp »

merb wrote: post #109
mahmoudimus wrote: post #19

Earlier quoted context omitted.

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.

Yeah, the problem is that it will only appear around 2020 and meanwhile the competion doesn't stand still.

Also we still have deployments using EOL Java versions that don't get upgraded, because IT doesn't want to change those servers.

Re: Graal and Truffle could accelerate programming language design

#130

Post by grashalm »

trishume wrote: post #126
chrisseaton wrote: post #95

Earlier quoted context omitted.

Take a look at the Medium URLs and you'll see they have a fragment ID and so count as different submissions.

I wondered why this didn't get merged with my submission. Makes a neat example of how random getting on the HN front page is though. Although I'm sad that randomness chose to give the second posting karma instead of mine.

What was your title? Without a good one, your post might have been just skipped by most.
Post reply on HN