Live data from Hacker News

Unpacking Elixir: Concurrency

underjord.io

121–130 of 138 posts

Re: Unpacking Elixir: Concurrency

#121
post #14

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

Another thing with numeric maps is how insert would work. Swapping elements is trivial, but inserting a new one would require rewriting every subsequent entry.

Re: Unpacking Elixir: Concurrency

#123
post #60
post #45

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

Elixir builds types out of maps (using the struct) and you can build multiple dispatch operations over types using Protocol. If you want to pretty print your user types, you can implement the Inspect protocol.

Re: Unpacking Elixir: Concurrency

#124
post #92

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

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

#125
post #93
post #91

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

Yeah, but Clojure vectors are actually trees built to be persistent based on ideas from Bagwell's hash array mapped tries (what Clojure maps are), so they're not technically O(1).

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

#126
post #51
post #39

Disckaimer: 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…

"just plain old kubernetes" is an oxymoron, at best.

Re: Unpacking Elixir: Concurrency

#127
post #92

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

Good for you but why do all mainstream languages, including Clojure, have them?

Re: Unpacking Elixir: Concurrency

#128

Earlier 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…

I find that pure functional loops with reduce or fold often get a lot harder to read/write as soon as you have more than one variable to keep track of. Imperative loops don't really have this problem.

Re: Unpacking Elixir: Concurrency

#129
post #65

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

Where kafka comes in though is no-code db following. These are super handy when you want to be informed of changes to a table, but don't know which "micro-service" is changing the data. KafkaConnect is very handy.

Though I will concede, it's a bit of a bazooka for a mosquito, sort of thing.

Re: Unpacking Elixir: Concurrency

#130
post #65

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

After using NATS I don't think I'll ever want to use redis pubsub again.
Post reply on HN