4 ms·

> The hardest thing to grok with FP is immutable data. A lack of understanding how concurrency works can really screw you up in Elixir. > Task.start(...) I a

> The hardest thing to grok with FP is immutable data. A lack of understanding how concurrency works can really screw you up in Elixir. > Task.start(...) I almost never use task, because I like certainty. I've been bitten too badly by people using it who didn't understand it. I don't like having to explain `Enum.each(tasks, &Task.start/1 )` is going to screw up your order of operations to someone who doesn't get it. > Basically eliminate Redis or caching. It's easy to start off thinking that, but then you can end up spending a lot of time maintaining subpar libraries you've written in-house that don't have the nicer features of the thing you replaced. Also, caching can turn into quite the memory hog. > Run jobs across a cluster sanely with a good job library that only needs Postgresql. It's all fun & games until you have to undo everything so you can containerize the apps. > If you're wild eyed you can use Mnesia without the databases. I've used DETS & hate it quite a bit, I really don't want to be married to Mnesia. > New projects should be started with Elixir. I love Elixir, but I wouldn't use it for everything, and it's got a lot of sharp edges that can get you into a lot of trouble.

rkangel 5y ago
>> Task.start(...) > I almost never use task, because I like certainty. I've been bitten too badly by people using it who didn't understand it. I don't like having to explain `Enum.each(tasks, &Task.start/1 )` is going to screw up your order of operations to someone who doesn't get it. I don't understand this. In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. That's a useful capability and developers should understand it. If you don't know Elixir then you need to learn what Task does, but that's true in any language.
- valenterry 5y ago
  > In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. No, that's not true. Think javascript (and I hate javascript): you can do concurrency even though you literally don't have a way to spin up a thread in the browser.
  - devoutsalsa 5y ago
    Erlang was originally designed to have a great concurrency model that ran on a single core CPU! Preemptive scheduling is super cool!
  - ksbrooksjr 5y ago
    You actually can spin up a background thread in the browser now using web workers[0]. Although, like you mentioned, you don't actually need threads for concurrency. The event loop handles concurrency even in a single threaded environment. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
pdimitar 5y ago
> Task.start(...) Uhhh, `Task.async_stream` is much superior in almost any way -- you can specify maximum concurrency, timeout and if you want the results in the original order. You only have to append `Stream.run()` at the end and boom, you got parallel work's results handed to you in a variable assignment. Using naked `Task.start` is only marginally better than spawning raw OS threads and I avoid it like the plague. Thought this was common wisdom but apparently it isn't. > It's easy to start off thinking that, but then you can end up spending a lot of time maintaining subpar libraries you've written in-house that don't have the nicer features of the thing you replaced. Also, caching can turn into quite the memory hog. All true, although `cachex` and `ane` are extremely well-done libraries that have carried me a long way. I only gave up on them when we had to integrate the Elixir server app with apps written in another languages at which point we started (ab)using Redis' streams and normal caching abilities. > It's all fun & games until you have to undo everything so you can containerize the apps. Also true but that depends on your app and DevOps requirements. A lot of businesses don't need auto-scaling of their Elixir apps. They just conservatively buy a good enough static hosting and it serves them extremely fine. For 5 years working with Elixir I have never seen hosting that was bogged down by Elixir CPU constraints. 98% of the time it waits on I/O, be it disk or network. > I've used DETS & hate it quite a bit, I really don't want to be married to Mnesia. Agreed. This was a good idea 20 years ago, nowadays I'll reach for PostgreSQL or sqlite3 without a second thought. No need to reach for a homegrown half-database where scaling and actual querying become a problem the moment you reach out of hobbyist app territory. > I love Elixir, but I wouldn't use it for everything, and it's got a lot of sharp edges that can get you into a lot of trouble. Sadly I'll agree with this as well. I love Elixir and it will have a special place in my heart all the way to retirement, but I am seeing its downsides and I am not religiously advocating for it. Nowadays it's much more likely for me to reach for Rust for new projects, especially if the project isn't a web app (and even there `actix_web` 3.X and `rocket` 0.5 are super solid and fast as well).

rkangel 5y ago

>> Task.start(...) > I almost never use task, because I like certainty. I've been bitten too badly by people using it who didn't understand it. I don't like having to explain `Enum.each(tasks, &Task.start/1 )` is going to screw up your order of operations to someone who doesn't get it. I don't understand this. In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. That's a useful capability and developers should understand it. If you don't know Elixir then you need to learn what Task does, but that's true in any language.

valenterry 5y ago
> In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. No, that's not true. Think javascript (and I hate javascript): you can do concurrency even though you literally don't have a way to spin up a thread in the browser.
- devoutsalsa 5y ago
  Erlang was originally designed to have a great concurrency model that ran on a single core CPU! Preemptive scheduling is super cool!
- ksbrooksjr 5y ago
  You actually can spin up a background thread in the browser now using web workers[0]. Although, like you mentioned, you don't actually need threads for concurrency. The event loop handles concurrency even in a single threaded environment. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

pdimitar 5y ago

> Task.start(...) Uhhh, `Task.async_stream` is much superior in almost any way -- you can specify maximum concurrency, timeout and if you want the results in the original order. You only have to append `Stream.run()` at the end and boom, you got parallel work's results handed to you in a variable assignment. Using naked `Task.start` is only marginally better than spawning raw OS threads and I avoid it like the plague. Thought this was common wisdom but apparently it isn't. > It's easy to start off thinking that, but then you can end up spending a lot of time maintaining subpar libraries you've written in-house that don't have the nicer features of the thing you replaced. Also, caching can turn into quite the memory hog. All true, although `cachex` and `ane` are extremely well-done libraries that have carried me a long way. I only gave up on them when we had to integrate the Elixir server app with apps written in another languages at which point we started (ab)using Redis' streams and normal caching abilities. > It's all fun & games until you have to undo everything so you can containerize the apps. Also true but that depends on your app and DevOps requirements. A lot of businesses don't need auto-scaling of their Elixir apps. They just conservatively buy a good enough static hosting and it serves them extremely fine. For 5 years working with Elixir I have never seen hosting that was bogged down by Elixir CPU constraints. 98% of the time it waits on I/O, be it disk or network. > I've used DETS & hate it quite a bit, I really don't want to be married to Mnesia. Agreed. This was a good idea 20 years ago, nowadays I'll reach for PostgreSQL or sqlite3 without a second thought. No need to reach for a homegrown half-database where scaling and actual querying become a problem the moment you reach out of hobbyist app territory. > I love Elixir, but I wouldn't use it for everything, and it's got a lot of sharp edges that can get you into a lot of trouble. Sadly I'll agree with this as well. I love Elixir and it will have a special place in my heart all the way to retirement, but I am seeing its downsides and I am not religiously advocating for it. Nowadays it's much more likely for me to reach for Rust for new projects, especially if the project isn't a web app (and even there `actix_web` 3.X and `rocket` 0.5 are super solid and fast as well).