So what? What's wrong with using software like redis for cache, for a very small (but important) part of your business? I bet java apps use redis as well, and redis isn't written in java. So?
Erlang/Elixir have built-in caches that respond in the matter of 30-150 nanoseconds.
Why would you need an external service for that? It's adding complexity -- and likely hosting costs.
Isn't it self-evident to you that adding Redis as a caching layer to your stack is a bandaid to a deeper problem?
You're quite right: people using it as a mere cache don't get most of its benefits.
We're also dependent on mysql, are you gonna implement that in Elixir as well? Redis is a great piece of software, and it's a real SHARED cache, so it could work for sessions or other small state management you sometimes want to remember for example. What you described won't work for that.
Sessions work quite fine in Elixir's local cache as well. :)
This seems to suggest otherwise https://hex.pm/packages/redix, Why is the redis client is so popular in Elixir world? For such a small community 3+ million downloads is huge.
What's the name of the concept and where in the typical stack does it fit? Is this https://blog.appsignal.com/2019/11/12/caching-with-elixir-an... or something else? Care to share a few link to docs/articles? Thanks.
There are libraries that combine Erlang/Elixir's caching mechanisms in an attempt to achieve the best performance for most scenarios[1] as well.
Technically, ETS is not perfect because it copies data from its mutable cache to the process that requests it. But it's still orders of magnitude faster than outsourcing that to Redis.
I read in http://erlang.org/doc/man/ets.html that "Each table is created by a process. When the process terminates, the table is automatically destroyed. Every table has access rights set at creation."
-> So, caching is local to each worker node/process? Do nodes/processes communicate between them to synchronize their respective caches, or is it local by design?
If local by design, that wouldn't exactly cover the use case of "Redis in front of an army of $other_language workers", correct? And I guess it's accepted as costing slightly more cache misses, but with the benefit of more decentralization / node independence / resiliency, right?
It’s not a “problem”, but if you’re going to talk about large companies scaling something you need to understand that they’re likely scaling it in spite of limitations.
Largely, some systems don’t scale too well (latency on network accessible cache, throughput in persistence layers such as databases) so a lot of application layers will lean on those things heavily and they are exclusively written in relatively “faster” languages.
