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

The Neko Virtual Machine

nekovm.org

Post reply on HN
Print view View original

11–20 of 29 posts

Re: The Neko Virtual Machine

#11

Post by Gama11 »

k_ wrote: post #7

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)

Re: The Neko Virtual Machine

#12

Post by Gama11 »

logicprog wrote: post #2

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

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.

Re: The Neko Virtual Machine

#13

Post by Gama11 »

neals wrote: post #8

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.

Re: The Neko Virtual Machine

#14

Post by Gama11 »

codetrotter wrote: post #4
saagarjha wrote: post #3

Earlier quoted context omitted.

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

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.

Re: The Neko Virtual Machine

#15

Post by chii »

Gama11 wrote: post #11
k_ wrote: post #7

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

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).

Re: The Neko Virtual Machine

#16

Post by johnday »

Gama11 wrote: post #12
logicprog wrote: post #2

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

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, bu…

Why would types speed up the code?

Re: The Neko Virtual Machine

#17

Post by Gama11 »

chii wrote: post #15
Gama11 wrote: post #11

Earlier quoted context omitted.

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

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.

Re: The Neko Virtual Machine

#18

Post by cygx »

johnday wrote: post #16
Gama11 wrote: post #12

Earlier quoted context omitted.

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, bu…

Why would types speed up the code?

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

Re: The Neko Virtual Machine

#19

Post by Gama11 »

johnday wrote: post #16
Gama11 wrote: post #12

Earlier quoted context omitted.

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, bu…

Why would types speed up the code?

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/

Re: The Neko Virtual Machine

#20

Post by chii »

Gama11 wrote: post #17
chii wrote: post #15

Earlier quoted context omitted.

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.
Post reply on HN