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

Package with mutable APIs #664

Open
emil14 opened this issue May 31, 2024 · 0 comments
Open

Package with mutable APIs #664

emil14 opened this issue May 31, 2024 · 0 comments

Comments

@emil14
Copy link
Collaborator

emil14 commented May 31, 2024

Just an idea to speculate about. We must not merge something like this without being super careful. Usecases must be clearly understood first. Design must be clearly figured out as well!

Also, this must not be obvious way of solving problems in Nevalang. One should feel like immutability, streaming and other dataflow features are what comes to mind first. What we talking about here must be considered as some kind of black magic.

Okay, now after boring disclaimer lets get to the point.

Neva is an immutable language. There's no way (must not be at least except there's a bug) to mutate message. It means each time we need to update something we have to create a copy. One way of living with this is some kind of smart and complex optimization like Haskell/Clojure.

However, there's another, dirty solution. And I personally like that.

The idea is to provide a package that will expose mutable APIs. Names could be something like this:

  • mut
  • mutate
  • mutable
  • mutation
  • mutations

One question is whether we want to use sync.Mutex. Other question (they both related probably) is what could be design of such package. Another (and the most important) is how the API should look.

To understand all these what we need is:

  1. Take some program doesn't perform well because of the immutability. Perfectly it would be some idiomatic Nevalang program to demonstrate how a bottle-neck could be fixed
  2. Write several pseudocode examples of how that could look with mutable APIs
  3. Write some (simple) benchmark
  4. Implement some prototype
  5. Prove that it's simnifically faster
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant