The Neko Virtual Machine | Hacker News Reader

The Neko Virtual Machine

nekovm.org

131 pointsazhenley28 comments

Neko has been around for 10+ years and is being replaced progressively by HL (HashLink, [1]), from the same creator.

I mainly know Neko as one of many transpiling targets for Haxe programming language [2] (10+ targets including JS, PHP, C++), and have used it many years ago for all my backend stuff.

[1]: https://hashlink.haxe.org/ [2]: https://haxe.org/

I'm also surprised that Neko has been posted here rather than HashLink, which is much more impressive:

- unlike Neko, the bytecode is strictly typed, allowing it to be much faster

- there are two different ways to use it:

  - HL/JIT, compiling to bytecode and using the VM

  - HL/C, compiling to raw C code to gain an extra bit of performance and allow it to run on devices that don't allow JIT (mobile / consoles)

- the successful indie games Northgard (by the Haxe / HashLink creator himself) and Dead Cells use HashLink as their runtime

- there is a VSCode breakpoint debugger for it (https://marketplace.visualstudio.com/items?itemName=HaxeFoun...)

- in the future, support for hot-reloading bytecode is coming (https://github.com/HaxeFoundation/hashlink/issues/145)

Sorry, I found Neko for the first time and didn't see any mention of HL on the Neko website. HashLink does look very impressive so thanks for the details. I'm looking into it now.

That is a good point, a mention on the Neko website would make sense.

So how much faster is HashLink than Neko?

Are there any benchmarks somewhere?

Edit: It's significantly faster then Neko and about as fast as HXCPP target.

https://twitter.com/jdbaudi/status/789231337467174912

I thought the vscode debugger is for the JavaScript target, not the hashlink target (but it's been a while since I last looked, so I would be glad to be wrong).

There's actually VSCode debuggers for a lot of Haxe targets by now: HashLink, JavaScript [1], C++ (HXCPP), Eval (the compiler's macro interpreter) and Flash. See https://github.com/vshaxe/vshaxe/wiki/Debugging.

[1] Though in JavaScript's case, there isn't really anything Haxe-specific about it, it just uses sourcemaps generated by the compiler like other languages compiling to JS.

wow, that's pretty cool. I m really glad that vscode introduced the language server and debugging procotol.

Differences between Neko and Hashlink, why a new VM: https://haxe.org/blog/hashlink-indepth/

[edited after reading FAQ]

Minor criticism: It would be helpful to see some code so you can tell what you're going to have to be generating to use the VM. Especially since it's not bytecode or abstract machine instructions so it's hard to know what to expect.

Otherwise, this is an incredibly cool project, which I'm definitely going to check out more in the future. Out of curiosity, how does its performance and memory usage compare versus the JVM or even LLVM (for the standalone compiler)? It's a super cool idea to have a lightweight standardized VM to program for, but I think generating bytecode or LLVM IR would be easier to design a programming language atop, at least because it'd be less likely to be a leaky abstraction like JS transpilers. So it'd be nice to know if any more technical benefits.

One technical question, (forgive me I don't know what I'm talking about) why have a bytecode at all, since no users of the languages based on Neko VM will touch Neko PL themselves (usually), why can't Neko PL act as a bytecode?

Neko isn't that fast, since the bytecode is dynamically typed. That combined with the fact that it's not really actively developed anymore, you'd probably be better off checking out its successor called "HashLink" instead (see comment thread above).

Btw, a JVM target (generating JVM bytecode directly) was recently merged into the Haxe compiler. Previously there was already a target that generates Java source code, but that had some issues like slowing down compile times with the native Java compilation step that needed to be done.

Yeah I was concerned reading that, about boxing everything due to dynamic types.

Why would types speed up the code?

Without types everything is a pointer (boxing), and when you actually need the value you need to resolve (dereference).

This is almost always cache miss.

If the collection is polymorphic it's even worse because you dereference to access the dispatch table which then redirects you to the real value.

Furthermore, each variable will need heap allocation and tracking, stressing the garbage collector and the underlying allocator (unless you preallocate big chunks like Java).

Static types avoid the cost of runtime type checks and dynamic dispatch.

Also they permit more inlining opportunities, allow eliminating more dead code, and more. Types almost always improve program performance.

The "HashLink in-depth" blog post talks about this, an excerpt:

> [...] Neko is very slow. The main reason for this is that it's dynamically typed. So every "value" in the VM can be either an Int, a Float, a Bool, some Bytes, an Array, a Function or Object, etc. And because this value needs to be recognized at run-time, its type together with its data need to be stored in the memory. [...]

https://haxe.org/blog/hashlink-indepth/

I don't completely understand the background of this project, but I think this is supposed to be a scripting language that compiles down to bytecode, which lets you embed the interpreter (à la Lua) or VM into your application depending on what you want.

I’ve only ever heard of Neko in the context of Haxe, a scripting language created by the same people that make Neko. Never did look really closely into either of them though.

I found the following three resources helpful in getting a bit of an idea about what Neko really is beyond being a target VM of Haxe.

Neko C FFI - https://nekovm.org/doc/ffi/

A comparison of Neko and Lua - https://nekovm.org/doc/lua/

Language Interoperability - https://nekovm.org/doc/multilang/

Haxe is hardly a "scripting language", at least according to my definition of that term. It's a strictly typed high-level language with a proper optimizing compiler. Depending on the target it produces either bytecode (Neko, HashLink, Flash and recently JVM) or source code (C++, JavaScript, Python, Lua, C#, Java, PHP).

See https://haxe.org/documentation/introduction/compiler-targets... for a full list of targets.

Yeah sorry, like I said, never did look closely into either of them before. Knew that Haxe had multiple targets but aside from Neko and Flash and JavaScript I didn’t remember the others. Should’ve checked the Haxe website also.

No worries, just wanted to clear up the misconception. :)

I always used Neko as the default VM to run Haxe code. I used it the same way most people now use NodeJS: tooling, simple webserver, quick prototype.

These days, I start new projects in NodeJS because teams don't know about Neko. Which is a shame because Neko and the Haxe language solve most critisism of NodeJS and JS in general.

Haxe's JavaScript target works great in combination with Node as well though. :) (https://github.com/HaxeFoundation/hxnodejs)

For instance, the Haxe VSCode extension itself is a Node project written in Haxe.

A long time ago I used HaXe to create a flash based magazine DVD without having to install windows [1]. I'm glad to see that HaXe is stil around, I enjoyed using it!

[1]: http://www.thebacklog.net/2008/11/12/open-source-flash-workf...

Without attribution, it's pretty unclear where these quotes are coming from. Are they just made up? If so... those aren't quotes =/

Looks awesome! Do you have any code samples/examples?

Neko is indeed amazing. But is pretty much dead. Check its successor: https://hashlink.haxe.org/.

Reply on news.ycombinator.com