111–120 of 135 posts
I would name the "distributed" actor and func keyword "remote" instead. It's shorter and more understandable.
Even in traditional Actor model systems processes aren’t remote by default. They just allow you to reason about remote concurrency the same way you reason about it generally.
computer boundaries.
So wasn't this part of the original dream for Smalltalk? Then this would seem to be coming full circle: Smalltalk, Objective C, Swift and back. I know some of you are Alan Kay fans so maybe you can comment on that aspect.
"Writing Concurrent Object-Oriented Programs using Smalltalk-80"
http://www.wolczko.com/mushroom/compj.pdf
"Actra = A Multitasking / Multiprocessing Smalltalk"
https://dl.acm.org/doi/10.1145/67387.67409
Actra -- an industrial strength concurrent object-oriented programming system
Question for folks: where do server-side Swift folks hang out? I've been writing server-side / enterprise code in Swift for about a year now, and the language has really grown on me. But it's a small community, and IBM's & Google's departures were a big blow to the feeling of inevitable growth to it. I'd love to find a watering hole to chat with others in the same small niche.
So Swift is pretty much dead in the backend space and somehow they're pushing actors in the language? I just don't understand the vision.
Why do you think it is dead? I have always thought that it is incomplete as a language, just give it time. Swift seems to be my cup of tea after years of Java and Typescript. I would really like to learn about these new features and apply them in a backend scenario. Julia is another language that did not catch up as people expected (especially the data science community) but I enjoy using it for my personal projects,…
Wait what? Julia has been growing very consistently for years now. I don’t think anyone with a reasonably informed opinion thought Julia was going to take over the whole world in the blink of an eye.
It seems to be going right along the lines that most people I know in the community expected.
Earlier quoted context omitted.
They are adding features they 'took' to put it kindly from other existing, mature implementations without giving any credit or acknowledgement. Not only that, they expect people to test their beta grade software because they keep releasing it half baked ever since the release of Swift itself. It's embarrassing and it also angers me because these companies have wall gardened their ecosystems to proprietary languages a…
This blog post is an announcement for a wide audience. In the proposal[1], which gives detail on motivations and implementation, there is an "Acknowledgements & Prior Art" section that mentions Akka, Orleans, Erlang, and Elixir. [1]: https://github.com/ktoso/swift-evolution/blob/distributed-re...
Thank you. That really changes things.
Earlier quoted context omitted.
I skimmed through the blog post, and it seems to me that they are not claiming they invented something new, just that they are adding this to Swift language. (Distributed) actor model is nothing new, but I definitely wouldn't classify it as something that's common in other languages. To my knowledge Erlang/OTP is the only mainstream language where this is part of the standard library. There are implementations for ot…
They are adding features they 'took' to put it kindly from other existing, mature implementations without giving any credit or acknowledgement. Not only that, they expect people to test their beta grade software because they keep releasing it half baked ever since the release of Swift itself. It's embarrassing and it also angers me because these companies have wall gardened their ecosystems to proprietary languages a…
Kotlin's roadmap... Copy Gosu and Groovy
Java's roadmap... Make Gosu, Groovy and Kotlin redundant by supporting the idioms of Gosu and Kotlin eventually and force those languages to 'nativize' their underlying implementations.
Manifold's roadmap... Ditch Gosu on the JVM and make a java library, copy all the stuff Java doesn't' have a plan for like .Net's (and by extension Gosu's) class extensions and java 8 to 9 workarounds
We could go on and on. Nothing new under the sun. Great minds think alike and at the end of the day the value of delivering a product is what matters in the end.
Earlier quoted context omitted.
They are adding features they 'took' to put it kindly from other existing, mature implementations without giving any credit or acknowledgement. Not only that, they expect people to test their beta grade software because they keep releasing it half baked ever since the release of Swift itself. It's embarrassing and it also angers me because these companies have wall gardened their ecosystems to proprietary languages a…
Gosu's roadmap... copy .NET and Groovy Kotlin's roadmap... Copy Gosu and Groovy Java's roadmap... Make Gosu, Groovy and Kotlin redundant by supporting the idioms of Gosu and Kotlin eventually and force those languages to 'nativize' their underlying implementations. Manifold's roadmap... Ditch Gosu on the JVM and make a java library, copy all the stuff Java doesn't' have a plan for like .Net's (and by extension Gosu's…
Their argument was so compelling that we decided to keep having slaves.
Earlier quoted context omitted.
Anything concurrent and distributed you want supported by your runtime a la Erlang. The reason is: you want certain guarantees. For example, in Erlang you can set up a monitor on a process, and when that process exits for any reason , you get a notification, {EXIT, Reason}. Even if that reason was a catastrophic failure of some sort. If this is implemented as a library, then the runtime can kill your code at any time…
Erlang has absolutely no security :-(
Earlier quoted context omitted.
Anything concurrent and distributed you want supported by your runtime a la Erlang. The reason is: you want certain guarantees. For example, in Erlang you can set up a monitor on a process, and when that process exits for any reason , you get a notification, {EXIT, Reason}. Even if that reason was a catastrophic failure of some sort. If this is implemented as a library, then the runtime can kill your code at any time…
I don't know if that's true. In the Scala and Java worlds, a library called Akka provides distributed actors as a library. As far as I know, what you describe isn't a limitation. See https://doc.akka.io/docs/akka/2.5.32/general/supervision.htm...
Compare Erlang's error handling and monitors: https://erlang.org/doc/reference_manual/processes.html#error...
Earlier quoted context omitted.
I’m the pessimistic opposite here; I’m a little shocked to see this largely failed idea be dragged back out of the history books again , a good decade-plus after the last major failed attempt. We’ve gone through this so many times, and — outside the very specialized Erlang — the result is always the same. It doesn’t work. OO Actors are a terrible concurrency model, and an even worse networking, protocol definition, a…
I've used Akka extensively and beg to differ. It's such a clean departure from traditional concurrent programming and the "let it fail" mentality around it is real. The distributed features work as intended to great effect with only certain edge cases (split brain for example) that need to have care but at that point in scale, you're already leveraging all the best parts.
I'd like to propose an actually dead idea: calling ideas dead. That we fail with tech ideas & abstractions is 99.%%% of the time not really reflective of the idea itself. There's survivorship bias- well, I think we need a term for the opposite: didn't work bias. A lot of technologies are dogged by image problems from less than successful pasts. Too often we pop culturally & en-masse accept that specific failures imply general unsuitability, and become fixed, hostile, & negative towards ideas. We should label this phenomenon & understand it better. "Didn't Work Bias" doesn't quite feel like the best fit or reciprocal to Survivorship Bias but it's a start at capturing these prevalent anti-idea sentimentalities.