Comment by wahern | Hacker News Reader

Comment by wahern | Hacker News Reader

Parent Full thread

Judging 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 novel control-flow semantics (asymmetric coroutines that can yield across multiple, unadorned function invocation) nor performance capabilities (JIT-optimizing Lua tables is non-trivial).

I'm not even sure LuaTruffle implements Lua's lexical closures or tail call optimization, both critical to Lua's ability to support functional programming patterns.

Of course, it definitely doesn't implement the Lua C API, which is part-and-parcel of what makes Lua preferable as an extension and glue language. But I was willing to overlook that if it could easily implement the former.

The beauty of a good DSL isn't the syntax (I know, hard to believe!), but in novel approaches to code flow execution and other deep semantics. Golang's goroutines are beautiful. Rust's ownership analyzer and prover are what _defines_ the language. Haskell's lazy evaluation open up whole new dimensions for problem solving (and headaches). If your language framework doesn't at least preserve the ability to implement those things cleanly and performantly, it's not adding much value and is basically a toy. It's not like writing a lexer for a DSL is a serious impediment. (Using Lua's LPeg, for example, you can write parsers and build an AST for most major languages in a few hundred lines of code.)

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.

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.

400 KB is a very aggressive target. I don't think anything in SubstrateVM would absolutely prohibit that, but currently our images are larger.

Some of this is just simply a design trade-off. E.g., in JRuby+Truffle, we've implemented much of the core library in Ruby. This has allowed us to achieve a high level of language compatibility in a fairly short period of time -- implementing 3,000 core library methods in Java would be quite the undertaking. As a consequence, the static binary must include those full Ruby sources (compressed, but they're not in an optimized bytecode format).

Having said that, if we wanted to optimize for size over a restricted subset of the language (think mruby), that would be straightforward to do.

Oh, only co-routines? So you've implemented callcc already?

Truffle+Graal could actually easily implement all of those things, LuaTruffle is just one of the less developed ports. JRuby+Truffle has highly efficient analogues of most of the things you mention.

Reply on news.ycombinator.com