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:
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
Write several pseudocode examples of how that could look with mutable APIs
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
boringdisclaimer 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,
dirtysolution. And I personally like that.The idea is to provide a package that will expose mutable APIs. Names could be something like this:
mutmutatemutablemutationmutationsOne 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: