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

Io implementation in Rust #434

Open
ales-tsurko opened this issue Sep 11, 2020 · 9 comments
Open

Io implementation in Rust #434

ales-tsurko opened this issue Sep 11, 2020 · 9 comments

Comments

@ales-tsurko
Copy link
Member

I'm thinking of re-implementing Io in Rust. It's going to be a weekend side project, so the development is going to be slow. Some pros for motivation:

  • Rust is safer than C
  • better dependency management/compilation process for the project, less platform dependent issues (including for the new addons)
  • better source code documentation
  • possibly we would be able to go web
  • fewer bugs, I hope... I could possibly fix some old bugs during porting (but could introduce new ones 😅)
  • take attention of Rust community, maybe involving more developers

Are there any suggestions and wishes for this port?

@stevedekorte

@stevedekorte
Copy link
Member

This is exciting. Have you thought about how concurrency would work for a Rust implementation? Would you make an Io VM with it's own stacks?

@ales-tsurko
Copy link
Member Author

Have you thought about how concurrency would work for a Rust implementation?

I thought about using a library for this. There's a well known actix and other implementations of the actor model in the rust infra.

Would you make an Io VM with it's own stacks?

I'm really not sure about this for now. But I'll do research as there's no deadlines and I'm interested in this for educational purposes.

@zephyrtronium
Copy link

One thing I learned from my Go implementation: it's impossible to implement an Io scheduler that is itself concurrent and that provides worry-free consistency.

In order to achieve consistency with a goroutine per coroutine, without adding explicit synchronization mechanisms to Io, setSlot has to hold a mutex for that slot during the entire time it evaluates the assignment value. This means that any use of any slot on an object accessible to another coroutine can potentially deadlock. (It was very neat to optimize slot accesses under this approach, though.)

I've been busy with school and other projects, but when I eventually return to iolang, I plan to turn its scheduler into the same one-at-a-time model that Io uses, and make an addon for goroutine concurrency/parallelism.

As an unrelated note, my implementation does currently run in Wasm. Although, last I tried, it deadlocked during tests on futures.

@ales-tsurko
Copy link
Member Author

Thank you very much! I'll look into this issue first.

@stevedekorte @zephyrtronium
Is there anything you'd do differently if you were rewriting it from scratch?

@stevedekorte
Copy link
Member

stevedekorte commented Sep 11, 2020

Is there anything you'd do differently if you were rewriting it from scratch?

The things that come to mind are:

  • Using a VM to isolate Io's concurrency and garbage collection from the implementation's. This ensures we can have things like coroutines, weak references, dynamic compilation, and mobile actors and images, regardless of implementation language.

  • An integrated persistence system. Probably a low level image model as well as a high level model (a library) where there is more control over how and when persistence occurs

  • An abstraction for slots

  • A notification system built around the slot abstraction that can help with synchronization between UI, objects, and storage

  • some form of capabilities based security system

  • a protocol for a uniform introspection and interaction with abstract objects that allowed UIs and associated storage to be automatically generated/managed from models

@zephyrtronium
Copy link

If you mean "what would I do to have a better time writing Io," I'd implement coroutines early – maybe before even messages – instead of leaving them for almost last, and I'd care about the performance of message passing itself before implementing all the methods of Number and Sequence. Even with heavy optimization, my implementation is still about 8-10x slower than the original, and it took multiple rewrites to get it there from 20x.

I also think I'd use singleton globals and not bother supporting multiple interpreter instances per program. This is probably more relevant for Go with its unusual calling convention, but eliminating an argument from every function should give a reasonable performance improvement, and it would make writing CFunctions slightly more convenient. There are few use cases for multiple interpreters, especially now that web REPLs can use Wasm instead of server-side processes.

Alternatively, if you mean "what would I do if inventing Io," static typing.

@ales-tsurko
Copy link
Member Author

Thanks, guys! I need to return to Io and its sources after more than a year (or two?..) break. Then I'll research about everything you wrote. After that I'd write you personally if I had questions. Would you mind?

@stevedekorte
Copy link
Member

I'd be happy to talk more about your project.

@zephyrtronium
Copy link

I'm happy to answer questions as well. 🙂

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

3 participants