off-topic 2018-05-23 | Slack Archive

vemv07:05:13

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?

mpenet07:05:47

apples vs oranges

mpenet07:05:18

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

mpenet07:05:00

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

mpenet07:05:37

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

vemv07:05:12

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

mpenet07:05:47

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

vemv07:05:01

Thanks for the answer!

orestis07:05:49

vemv07:05:53

Nice! I'll have to watch the EuroClojure talk

tbaldridge10:05:34

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

tbaldridge10:05:52

For example: https://github.com/suprematic/otplike/blob/0bed411cd48a469c03d5f3f4fa392f726284202a/src/otplike/process.clj#L30-L33

tbaldridge10:05:53

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).

tbaldridge11:05:57

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

vemv11:05:15

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

tbaldridge11:05:33

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.

tbaldridge11:05:38

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.

tbaldridge11:05:20

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

😂 4

mpenet13:05:46

yeah that's a weird design

mpenet13:05:44

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

mpenet13:05:13

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

mpenet13:05:18

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

roklenarcic11:05:25

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?

vemv14:05:45

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

2018-05-23

Channels