Earlier quoted context omitted.
What would be the difference between a "real vector" and a Map with numeric keys?
> What would be the difference between a "real vector" and a Map with numeric keys? Access in O(1) instead of O(nlogn).
Unpacking Elixir: Concurrency
121–130 of 138 posts
Re: Unpacking Elixir: Concurrency
#122I like this Underjord guy. I've watched some of his YouTube content on Elixir. He's good at explaining concepts, has a natural teaching ability.
Re: Unpacking Elixir: Concurrency
#123Earlier quoted context omitted.
Note that Erlang has maps since OTP 17, which I believe are implemented more efficiently than dicts.
Good point, though I think my point about user types still holds. It is very difficult to create any efficient user types of your own with the primitives Beam provides.
Re: Unpacking Elixir: Concurrency
#124Earlier quoted context omitted.
So what do you use real arrays for? For 80% of programming lists are just fine. Are you doing cpu-bound numerical calculations?
Same things arrays are used for in all mainstream languages ie. index-based access.
Re: Unpacking Elixir: Concurrency
#125Earlier quoted context omitted.
Data is immutable in Erlang. How do you know the runtime does not optimize Maps with numeric keys into arrays?
Data is also immutable in Clojure but it still has vectors.
Both maps and vectors in Clojure are trees, albeit very shallow trees (32-way branching). The difference lies in the interfaces and the lookup methods. (Maps hash keys and use bits to know which subtree to descend, while vectors use index bits.)
Re: Unpacking Elixir: Concurrency
#126Disckaimer: I have never used Elixir in any serious capacity, but I have done a good chunk of Erlang. Concurrency in Erlang sort of frustrates me...not because it's bad, but because when I use it I start getting pissed at how annoying concurrency is in nearly every other language. So much of distributed systems tooling in 2023 is basically just there to port over Erlang constructs to more mainstream languages. Obviou…
This is coming from someone who likes Elixir. Not much for its distributed systems features, but mostly because of the language design. I keep hearing everyone talk about how Erlang/Elixir gives everything out of the box and you don't need to worry about Queues, RPC or whatever... But in reality, people don't really recommend using Distributed Erlang that much, on most Elixir gigs I worked, they didn't use Distribute…
Re: Unpacking Elixir: Concurrency
#127Earlier quoted context omitted.
Same things arrays are used for in all mainstream languages ie. index-based access.
That's not answering the question. I've written many thousands of lines of elixir and never used index based access.
Re: Unpacking Elixir: Concurrency
#128Earlier quoted context omitted.
I love elixir and am very comfortable with functional programming and generally prefer it. But being told you have to write a state machine instead of just += a var is an excellent experience in believing elixir is harder than python.
Of course you example is hyperbole and I certainly understand what you are saying. But the attitude that many programmers take when learning a new language that something is "harder" when it's just different than what they are used to bothers me (to be clear, I'm not directing that at you). But comparing: i = 0 for x in [1, 2, 3, 4]: i += x vs i = Enum.reduce([1, 2, 3, 4], fn x, i -> i + x end) There is nothing inher…
Re: Unpacking Elixir: Concurrency
#129Earlier quoted context omitted.
>those other ecosystems still need Kubernetes, Kafka, Redis and GRPC, to get by And what makes Elixir not need Kafka, Redis or GRPC? Instead of Redis, you could use ETS for caching. But once you have 2+ instances of your app, you will need to have a centralized caching mechanism, otherwise, each instance will have its own ETS with its own memory, not sharing anything. Unless you decide to use Distributed Erlang and c…
I think Elixir/Erlang + Redis pub-sub + PostgreSQL is the sane minimal subset for distributed and scalable systems. Just say no to Kafka.
Though I will concede, it's a bit of a bazooka for a mosquito, sort of thing.
Re: Unpacking Elixir: Concurrency
#130Earlier quoted context omitted.
>those other ecosystems still need Kubernetes, Kafka, Redis and GRPC, to get by And what makes Elixir not need Kafka, Redis or GRPC? Instead of Redis, you could use ETS for caching. But once you have 2+ instances of your app, you will need to have a centralized caching mechanism, otherwise, each instance will have its own ETS with its own memory, not sharing anything. Unless you decide to use Distributed Erlang and c…
I think Elixir/Erlang + Redis pub-sub + PostgreSQL is the sane minimal subset for distributed and scalable systems. Just say no to Kafka.