Hacker News Reader

Comment by skrebbel | Hacker News Reader

You can't use those to cache requests.

You can store an Elixir task but you can only await it once. You can `.then` a JavaScript promise as often as you want which makes a promise an excellent primitive for caching things that take time (eg network requests) without triggering the same request twice.

View on HN

You can leave a process around as a cache, sending it messages when its values need to change. And if it dies for whatever reason, its supervisor can restart it to a known good state. You shouldn't concern yourself as the caller of how the cache updates itself, you should send it an explicit message like "the cache for X is out of date" and let that go and do its thing accordingly.

Yes and that's a lot of work for what would be a two-liner in JS.

Every time someone says "just make a process and a supervisor, put it elegantly in the supervisor tree, go think through the failure modes, ponder a bit about these 3 or 4 edge cases and potential race conditions, and you're done! hooray!" I get a bit grumpy.

Elixir is awesome, but there's a simplicity to a single-threaded execution model that takes away a lot of the things that make concurrency hard.

At the small prize of parallelism. And now that you are dealing with workers, task queues, etc. a native process + supervisor solution doesn't seem bad at all.

It's not a contest!

All I'm saying is that there are things that Elixir isn't the best at. Is that so weird? I feel like everybody responding to me has this strong emotional need to defend Elixir. Why? it's just a tool. Like any tool it has pros and cons.

Elixir is amazing at creating parrallelized network heavy iobound applications. obviously its going to be shit if you want to do machine learning or anything computationally bound. Thats why it has amazing first class integrations!

https://github.com/fazibear/export and https://github.com/hansihe/rustler

Reply on news.ycombinator.com