A VM for crystal

[faustinoaq]

Hi @KCreate I know this project isn't maintained anymore, but I want to ask you something,

Do you think would be possible to write a VM machine for crystal?

Ref: https://gitter.im/crystal-lang/crystal?at=5ab0150635dd17022e79c5fe

The idea is to create an interpreted, slow crystal-vm in aims for fast development, interpreted bytecde execution and live in-debugger. Keeping crystal compiler for production release executables (slow compilation, but fast execution and stand-alone binaries)

WDYT?

BTW, you charly-vm in C++ looks pretty nice :+1:

[faustinoaq]

Also we don't have to rewrite all, we can reuse the current lexer, parser and std-lib, just replacing the code-gen by a custom VM (I have no idea how to do it :sweat_smile: )

[KCreate]

Hey,

It would be definitely possible. The tricky parts would be C-interoperability and basically all the parts which use some form of assembly.

Anyway, are slow compilation times really a problem with Crystal? Recompiling Charly takes about 1.3 seconds for me (unoptimized build), which is extremely fast in my opinion.

I don't really see a need for an interpreted version of Crystal, but if there is a strong desire from the community for such a project to be developed, I'd love to help out wherever I can!

Are there other people who want this, maybe even from the core-team?

[faustinoaq]

It would be definitely possible.

Oh, great! :tada:

The tricky parts would be C-interoperability and basically all the parts which use some form of assembly.

Maybe we can add some warning for this, saying something like: if you want to use this feature you should use crystal build instead or maybe using JIT compiling or similar for this. (I guess Julia lang does something similar)

@KCreate I had the idea because I was asking for a true REPL for crystal, and I got a very interesting response from @RX14 :

the problem was never being compiled nobody ever said that the problem has and has always been the type system

Then he wrote some nice comments:

Since you can reuse the existing compiler What you'd do is pass the whole program through most of the existing crystal compiler And instead of Codegen use the existing AST in a vm It'd be slow as shit but who cares Every time you make an update youd reconstruct the AST for the whole program again Making an interpreter with no checking (its already been done by the compiler) is far easier than making one from scratch

So, the problem is not because crystal slow compilation (sometimes is very slow, though), but because the type system.

my observation is that the compiler isn't actually that slow and the compiler being slow isn't the problem you just run "half" the compiler even for a moderately sized application you should be able to do hot reload with this icr is uselss to me what I want is the ability to use it as an in-program debugger and possibly for hot-reload

Ref: https://gitter.im/crystal-lang/crystal?at=5ab00ef5f3f6d24c689220d7

[faustinoaq]

Also, There is Myst a nice dynamic, interpreted, functional language made with crystal by @faultyserver

Maybe he can share his opinions about a VM for crystal as well

[faultyserver]

Hello!

I'm basically in full agreement with what RX14 has said. I really don't know enough about the internals of the Crystal compiler to know what is and isn't possible (e.g., with templating, open types, etc.), but the idea of using the same front-end and just swapping the codegen for an interpreter sounds like the right direction.

I have a lot of questions I'd have to work through to really get an idea of what's possible here, but I'd definitely be willing to help out/continue discussions/etc.

[faustinoaq]

Interesting post here: https://www.reddit.com/r/crystal_programming/comments/91r8im/crystal_has_a_compilation_issue/