Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ready for use ? #90

Open
markusmoenig opened this issue Sep 2, 2022 · 6 comments
Open

Ready for use ? #90

markusmoenig opened this issue Sep 2, 2022 · 6 comments

Comments

@markusmoenig
Copy link

Hi,

I am working on a classical RPG Creator in Rust at https://github.com/markusmoenig/Eldiron. I am currently using Rhai for scripting but it's slow, I cannot use Lua etc. because it does not compile to WASM (I mean you can compile it to WASM but you cannot communicate with it).

I like Mica, do you think it is ready for production ? I am half-way through my project so if I would want to switch it is now :)

Cheers

@markusmoenig
Copy link
Author

And one question. The way my engine works is that I have nodes, and each node parameter is a script. So I have a lot of scripts which I precompile. Reading the docs of Mica it looks like I can only have one script per engine at a time.

I would need to have one engine per script than ? That would probably be hundreds.

@liquidev
Copy link
Member

liquidev commented Sep 3, 2022

Hey. Glad to see someone's interested in the project!

Currently I wouldn't call Mica production-ready. There will most likely be breaking changes in the mica-hl API to make it more ergonomic to use. Notably, currently it's impossible to pass arguments by reference - this is something that requires GATs but I haven't experimented with them yet.

IIRC compiling to WebAssembly requires #![no_std], and Mica doesn't support it yet (although it could pretty easily - just a matter of changing all imports from std to core and alloc.)

I have stress tested the VM a bit so it should be pretty robust, but do note that Mica doesn't shy away from using unsafe code to achieve its performance, so you may run into correctness bugs in more complex programs.

Also do note that the language still lacks a few features that would make it feel ergonomic:

  • for loops
  • traits (needed for for loops)
  • string concatenation operator (or interpolation)
  • rich standard library
    • this includes the ability to iterate through Dicts! which is blocked by for loops.

You may (will, even) run into these. Especially for loops. Technically they can be imitated using a Ruby-like approach:

impl struct Range
  func new(min, max) constructor = do
    @min = min
    @max = max
  end

  func min() = @min
  func max() = @max

  func each(then) = do
    i = @min
    result = nil
    while i < @max do
      result = then(i)
      i = i + 1
    end
    result
  end
end

Range.new(1, 10).each(func (i) = do
  print("Hello".cat(i.to_string))
end)

but it doesn't support breaking out of the loop.

Regarding engines, yes, you can only have one active script per engine. This is a limitation imposed for correctness reasons. If you look at the source code, an Engine is primarily a wrapper around an Environment (compile-time stuff), and Globals + a Memory (runtime stuff). The problem is that a compiled script can only ever work with the Environment it's been compiled with, so it has to store a reference to the Environment inside of itself. I currently don't know of any other solution that would prevent running scripts in incompatible environments during compilation. Maybe the solution would be to split the Environment into multiple parts - an engine environment (containing global declarations) and a script environment (containing bytecode), but this hasn't been implemented yet.

I'll open an issue about this, and will take a look once I'm done with 0.5.0.

@liquidev liquidev pinned this issue Sep 3, 2022
@markusmoenig
Copy link
Author

Hi, thanks for the answer. Yes, I think there is a market for a performant scripting language written in Rust and obviously it can only be performant if it is written in unsafe mode which is fine for me. I used to like Lua and hope Mica can be the future Lua for Rust. Right now the scripting languages are mostly ASTs. And most of the promising ones are discontinued and not supported.

It sounds like Mica in the current stage is not a good fit for Eldiron, so I will continue using Rhai for now. As I mostly use expressions plus Rust function calls, performance is not too bad (I mean I don't calculate Fibonacci numbers in Rhai) but it adds up if you have hundreds of characters....

I like the syntax of Mica, I will play with it more, I have a procedural 2D and 3D rendering project which I just started at https://github.com/markusmoenig/RPU and Mica could be a great option for having performant programmable software shaders. But for loops would be nice to have :)

Thanks again and I will watch your progress closely. Let me know if I can help somehow.

Cheers.

@liquidev
Copy link
Member

liquidev commented Sep 4, 2022

I think the main way you could help right now is by either contributing ideas/opinions in Issues, and poking at the implementation through smaller projects. I'm still figuring out the fundamentals of the language so if you want to contribute more closely please drop me a line on Twitter; right now there are no easy issues to close, sadly.

@liquidev liquidev removed this from Mica 1.0 Sep 10, 2022
@liquidev
Copy link
Member

liquidev commented Sep 10, 2022

Hey. I spent a little time to create a roadmap for making Mica ready for production use: https://github.com/orgs/mica-lang/projects/2/views/2

Note that by production use I mean, as ergonomic as I envision it being (both on the language side and on the Rust API side), and well-tested by fuzzing and an extensive test suite. Thus you do not need to wait for 1.0 to try Mica out; I think once 0.6.0 is ready it could be considered Good Enough for general use, but there will be breaking Rust API changes afterwards. If that's not something you wanna deal with, you'll just have to find an alternative. 👈 EDIT 31st Oct 2022: This sentence aged poorly.

I expect that 0.6.0 should be out by the end of the year, but with a full-time job it might take me a while, so please be patient! :) I have a major part of traits already implemented for 0.5.0, hopefully I can deliver them within a few weeks.

@markusmoenig
Copy link
Author

Looking good. Sure, I will give it a try!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants