Fork me on GitHub

Just curious, could one build his own 'Erlang platform' (with similar guarantees) with core.async? I am aware that CSP and actors are supposed to be different things, but could one stretch core.async enough to behave like Erlang?


apples vs oranges


otp does a lot more, ex supervision, distributed processes etc


then they have specifics that are deeply rooted in the underlying vm (beam vs jvm) that makes it quite difficult to emulate otp on the jvm without shooting yourself in the foot

👍 4

but sure, you can build something that would feel like it on the surface, but it would be brittle imho


> otp does a lot more, ex supervision, distributed processes etc Yeah I was wondering if this part could be reasonably implemented in Clojure


it could. but that's a lot of work, likely to spawn bugs here and there. otp has 20 years under its belt and some super heavy duty operation

👍 4

Thanks for the answer!


Nice! I'll have to watch the EuroClojure talk


@U45T93RA6 @U7PBP4UVA otplike has some really strange design decisions though


That's right, getting too many messages will crash the receiver. This makes no sense (aside from being a way to get around lack of necessary features in core.async).


But that's not a construct I'd want in my applications. That's something akin to the mail service demolishing the homes of people who don't read their mail fast enough. Drop the message, return it to sender, but don't crash the receiver simply because someone sent them messages too quickly

😂 8

Yeah sounds weird, either writes could block, or messages slide/drop? Classic core.async style


I think the reason is that core.async doesn't have a way to crash processes. Infact processes aren't a thing in core.async. Everything is a callback. So the only way to monitor something, or to stop it, is to send it a message.


Even if you used a true actor model though that still wouldn't fix all t he problems, since in the JVM there's no reliable way to terminate a thread.


Hence the best doc string in any language, hands-down: clojure.core/future-cancel "Cancels the future, if possible."

😂 4

yeah that's a weird design


that said erlang/otp mailboxes are "unbounded" (well until oom), so one could argue there is a limit there too. Since there's no "automatic" backpressure/flow control in otp you have to build it yourself (rate limiting or credit-based flow etc etc), which is not too complicated but it's a common thing for newcomers to overlook


core.async is way easier to use in that regard, but that's also a lot more limited in scope/feature


in short: there is no silver bullet, both require the user to take care of backpressure in some way when needed, it's just a different way to approach the way to signal/handle it

👍 4

here's a weird problem. I have a native installer app that gets built once, then it's served on many hosts. When a person downloads the installer it needs to call "home", that is, it needs to know which host to query over HTTP (the host it was downloaded from). How can I achieve this without making that many executables, each with a different home host baked in?


create a .zip with a folder, which contains the installer + a .host file?