Now, i don’t want to go into the details if this is a good thing or not. Let’s say its understandable that this unfolds as it does. But for me, with projects that rely heavily on actors in applications both for the JVM an JS these are not the best of circumstances.
Besides that, the current incarnation of Actors by Akka is really vast, my application probably only uses 10% of all the features.
I am curious if there is any interest in a revived, lightweight version of Scala Actors that would run on all platforms. It would be nice if it is typed, but for example remote functionality could be absent as far as i am concerned. Sometimes less is really more.
I’m not sure what you mean by this? The aim seems pretty clear to me – to continue the traditional free, open-source implementation that Akka used to be.
I disagree with the idea here, I’m afraid. Especially in the current more-FP-centric world, splitting the limited attention of the folks who are willing to work on Actor frameworks seems counter-productive.
And IMO it never belonged in the Scala stdlib in the first place, which is part of why the original relatively-weak implementation went away in favor of library implementations. Conceptually it belongs in libraries, not baked into the Scala core.
Incredible! How i could i have missed this? I will certainly give this a try. Thanks for the link. This project also indicates that there are at least a few people with the same needs as i have.
Well, it could be just an open source continuation of 2.6 software stack. It could become more. Maybe they will extend to other platforms, maybe not. Without a roadmap, its hard to say. Interesting project though.
Conceptually it belongs in libraries, not baked into the Scala core.
But core support in the language to build them (and other related things), e.g. in the form of a high-performance std. API around platform specific even-loop powered I/O would be really nice to have.
The std. Lib should provide basic common building blocks and standardized, platform agnostic APIs for higher-level abstractions. Event-loop based I/O and / or co-routines look imho much like such building block.
Hmm. Maybe, but that isn’t obvious to me. What benefits do you see in those capabilities coming from stdlib, rather than from ecosystem libraries? I mean, I’m not directly involved with the cats-effect effort, but my impression has been that it’s been somewhat helpful (especially in terms of performance) that they’ve been able to control the details deeply, and evolve the low levels quickly.
I could believe that there are some common abstractions that are so universal that they belong in stdlib, but I wouldn’t take that for granted. And they would be so low-level that they would probably be extremely performance-critical – I worry about making compromises in the name of generality that wind up hurting performance.
So – maybe, but it would be more convincing with concrete use cases across a variety of implementations (both a variety of Scala ecosystems, and a variety of compile targets) to show how things would be shared, and be able to really probe into the details of how that would work.
Yes, indeed. One such existing abstraction is ExecutionContext, for submitting tasks to some sort of executor (typically a threadpool).
Where we are currently lacking an abstraction is something for scheduling timers. The JDK offers ScheduledExecutorServce, but it is heavy-weight and not cross-platform (see also Scala ExecutionContext vs JDK ExecutorService).
So instead in Cats Effect we have the simpler Scheduler, which is sufficient and can be implemented on all platforms. It would be excellent to see an abstraction like this in the Scala stdlib, alongside ExecutionContext. Moreover, just as many libraries today are configurable via an implicit ec: ExecutionContext parameter, they should also expose an implicit sched: Scheduler if they need timer capabilities.
Besides the ability to submit tasks and schedule timers, an event loop should also offer some capability to poll for I/O-readiness. While an abstraction in this space would also be valuable, it’s not yet clear what exactly this should look like. This is what we are currently working on in Cats Effect. Wider participation is very welcome! Kind of difficult to design “shared” abstractions all on your own
I agree in general, but I’m remembering a proposal that would have made actor-like systems more performant, by introducing a new type of PartialFunction that could do a first-level triage on a scrutinee’s runtime type without having to call the generated isDefinedAt method… In my memory it was called “transparent functions” but that’s not turning up any useful results.
Edit: aha, it was Translucent Functions. Sadly much of the LAMP web space has bitrotted, but this was part of the effort:
Great to hear, thanks for your support! @bishabosha also expressed interest in upstreaming some of the I/O work we are doing in Cats Effect.
I am eagerly watching SIP-51, which I hope will lower the adoption barrier for these sorts of additions. (Alas, 2.12 will continue to get in the way, but we’ll manage ).
).