Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Managing mutable data in Elixir with Rust

lambdafunctions.com

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Managing mutable data in Elixir with Rust

#21

Post by WolfeReader »

wredue wrote: post #13
WolfeReader wrote: post #11

Earlier quoted context omitted.

I'm not sure Joe Armstrong would agree with your comment.

I don’t really care what people making claims say when they make claims without evidence. ”Who” makes a claim has no bearing on its truth. Immutability is a tool, not a rule, and I am free to reject any assertion otherwise when those assertions provide no evidence, or shitty anecdotes. Prove your claims. Certainly, immutability is a foundation for performance problems. Another provable rule in computing is that more…

You begin with "I don’t really care what people making claims say when they make claims without evidence". May I hold you to your own standards?

Because the rest of your post is pretty LOL-worthy in light of your opening sentence.

Re: Managing mutable data in Elixir with Rust

#22

Post by wredue »

dimitrios1 wrote: post #16
wredue wrote: post #13

Earlier quoted context omitted.

I don’t really care what people making claims say when they make claims without evidence. ”Who” makes a claim has no bearing on its truth. Immutability is a tool, not a rule, and I am free to reject any assertion otherwise when those assertions provide no evidence, or shitty anecdotes. Prove your claims. Certainly, immutability is a foundation for performance problems. Another provable rule in computing is that more…

There isn't some universe where there exists a list of axiomatic, unfalisifable proofs for what or what doesn't constitute the foundations of scalability and robustness, rather, you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives, and Joe Armstrong was someone who trailblazed that tradition in blood sweat and tears so to speak, as w…

The author claimed that immutability is a foundation for scalability and robustness.

I reject that claim.

In this comment, you simultaneously agree and disagree with me.

I don’t give a shit what Joe Armstrong says about immutability because the facts are the facts:

1) immutability cause performance problems

2) immutability significantly limits how you can manage data, which is counter to what computers are meant to do

3) immutability measurably does not reduce bugs in programs

I am not dismissing off the cuff. I am dismissing them because their claim does not align with metrics you expect to improve as a result of their claim.

>it doesn’t have to be a scientific claim

When you are telling people to “make immutability a foundation of their programming”, you 100% are opening yourself to scientific scrutiny. If you cannot back up this claim with actual metrics, and you’re just going to say “hurr durr, just let me make claims without calling me out to providing evidence please”, why should anyone believe you?

Re: Managing mutable data in Elixir with Rust

#23

Post by HexDecOctBin »

dimitrios1 wrote: post #16
wredue wrote: post #13

Earlier quoted context omitted.

I don’t really care what people making claims say when they make claims without evidence. ”Who” makes a claim has no bearing on its truth. Immutability is a tool, not a rule, and I am free to reject any assertion otherwise when those assertions provide no evidence, or shitty anecdotes. Prove your claims. Certainly, immutability is a foundation for performance problems. Another provable rule in computing is that more…

There isn't some universe where there exists a list of axiomatic, unfalisifable proofs for what or what doesn't constitute the foundations of scalability and robustness, rather, you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives, and Joe Armstrong was someone who trailblazed that tradition in blood sweat and tears so to speak, as w…

> you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives

I'm not GP, but these traditions are usually not backed by any evidence but by cargo-culting and cult-of-personalities. Not to mention people who over-hype their favourite technologies to high heavens, poisoning the well for everyone else (no, most telecom industry doesn't run Erlang, Naughty Dog didn't ship Lisp on PlayStation 2, and Prolog didn't lead to fifth-generation computing).

Re: Managing mutable data in Elixir with Rust

#24

Post by ch4s3 »

wredue wrote: post #22
dimitrios1 wrote: post #16

Earlier quoted context omitted.

There isn't some universe where there exists a list of axiomatic, unfalisifable proofs for what or what doesn't constitute the foundations of scalability and robustness, rather, you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives, and Joe Armstrong was someone who trailblazed that tradition in blood sweat and tears so to speak, as w…

The author claimed that immutability is a foundation for scalability and robustness. I reject that claim. In this comment, you simultaneously agree and disagree with me. I don’t give a shit what Joe Armstrong says about immutability because the facts are the facts: 1) immutability cause performance problems 2) immutability significantly limits how you can manage data, which is counter to what computers are meant to d…

> 3) immutability measurably does not reduce bugs in programs

I'd be curious to see how you back this claim up. Are you referring to something published that we can all go and read?

Re: Managing mutable data in Elixir with Rust

#25

Post by mgdev »

Rustler is great. Though this gets me thinking about how you can maintain as many Elixir invariants and conventions as possible, even while escaping them under the covers. Being able to call FeGraph.set/2 and have db actually be mutated violates Elixir's common call patterns, even if it's technically allowed.

For example: I wonder if it wouldn't be more "erlangy"/"elixiry" to model the mutable ops behind a genserver that you send messages to. In the Elixir world it's perfectly normal to make GenServer.call/3 and expect the target PID to change its internal state in a non-deterministic way. It's one of the only APIs that explicitly blesses this. The ETS API is another.

Alternatively, you could have the ref store both a DB sequence and a ref ID (set to the last DB sequence), and compare them on operations. If you call FeGraph.set/2 with the same db ref two times, you compare the ref ID to the sequence and panic if they aren't equal. They always need to operate with the latest ref. Then at last the local semantics are maintained.

Maybe this is less relevant for the FeGraph example, since Elixir libs dealing with data are more willing to treat the DB as a mutable thing (ETS, Digraph). But the it's not universal. Postgrex, for example, follows the DB-as-PID convention. Defaulting to an Elixiry pattern by default for Rustler implementation is probably a good practice.

Re: Managing mutable data in Elixir with Rust

#26

Post by mjhay »

wredue wrote: post #22
dimitrios1 wrote: post #16

Earlier quoted context omitted.

There isn't some universe where there exists a list of axiomatic, unfalisifable proofs for what or what doesn't constitute the foundations of scalability and robustness, rather, you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives, and Joe Armstrong was someone who trailblazed that tradition in blood sweat and tears so to speak, as w…

The author claimed that immutability is a foundation for scalability and robustness. I reject that claim. In this comment, you simultaneously agree and disagree with me. I don’t give a shit what Joe Armstrong says about immutability because the facts are the facts: 1) immutability cause performance problems 2) immutability significantly limits how you can manage data, which is counter to what computers are meant to d…

A bit of the pot calling the kettle black here. You still aren't providing evidence yourself while making strong claims.

For your points:

1) Yes, immutability can cause performance problems in some contexts. However, it can also help in the whole. Mutability in concurrent systems requires all sorts of complications such as mutexes that slow things down considerably. In even single-threaded systems, mutability leads to defensive copying in practice. Furthermore, persistent data structures[0] exist for lists, dictionaries, etc., that achieve very good space and time performance by mutating internally while exposing an immutable interface.

At any rate, even if it is slower, most of the time the performance difference just doesn't matter.

2) How does it limit how you can manage data? It's still possible to mix immutable and mutable data if necessary, but immutable data can be transformed just as mutable data can.

3) You say it measurably does not reduce bugs in programs, again with no evidence. Immutability eliminates entire classes of commonly-encountered bugs, including many pernicious ones related to concurrency. These are bugs that happen commonly with mutable data, but simply don't for immutable data.

In addition, there is some limited empirical evidence to the contrary, which is rare for this kind of thing. Immutable-first Clojure had the lowest proportion of Github issues labeled as bugs, even beating out static languages. [1]

[0] https://en.wikipedia.org/wiki/Persistent_data_structure

[1] https://dl.acm.org/doi/10.1145/2635868.2635922

Re: Managing mutable data in Elixir with Rust

#27

Post by clarkema »

mgdev wrote: post #25

Rustler is great. Though this gets me thinking about how you can maintain as many Elixir invariants and conventions as possible, even while escaping them under the covers. Being able to call FeGraph.set/2 and have db actually be mutated violates Elixir's common call patterns, even if it's technically allowed. For example: I wonder if it wouldn't be more "erlangy"/"elixiry" to model the mutable ops behind a genserver…

That's an interesting point that I should perhaps have covered in the original article.

The real code that this is based on is in fact hidden behind a GenServer for this exact reason -- to maintain the expectations of other Elixir code that has to interact with it. The advantage of the escape hatch, as another commenter mentions, is allowing efficient sparse mutations of a large chunk of data, without having to pay a copy penalty every time. I definitely wouldn't recommend sharing the db handle widely.

Re: Managing mutable data in Elixir with Rust

#28

Post by lvass »

clarkema wrote: post #27
mgdev wrote: post #25

Rustler is great. Though this gets me thinking about how you can maintain as many Elixir invariants and conventions as possible, even while escaping them under the covers. Being able to call FeGraph.set/2 and have db actually be mutated violates Elixir's common call patterns, even if it's technically allowed. For example: I wonder if it wouldn't be more "erlangy"/"elixiry" to model the mutable ops behind a genserver…

That's an interesting point that I should perhaps have covered in the original article. The real code that this is based on is in fact hidden behind a GenServer for this exact reason -- to maintain the expectations of other Elixir code that has to interact with it. The advantage of the escape hatch, as another commenter mentions, is allowing efficient sparse mutations of a large chunk of data, without having to pay a…

Have you measured performance? If mutating from Elixir like this can bring serious benefits, maybe there's a place for mutable versions of libraries like Explorer and Nx.

Re: Managing mutable data in Elixir with Rust

#29

Post by galaxyLogic »

unoti wrote: post #17
wredue wrote: post #10

Immutable data is not a “foundation of scalability and robustness”.

> Immutable data is not a “foundation of scalability and robustness”. It may not be the only way to get to scalability and robustness. But it certainly is the cornerstone of how Erlang gets there. 1. First, the way Erlang treats data ensures that every piece of data can be sent over the wire by default. This helps pave the way for another amazing characteristic of Erlang, and that is when you refer to and use an obje…

> you instantiate it you communicate with it by sending it messages

Does this mean a web-endpoint has to be immutable? If you send it the same parameters multiple times, is it required to respond with the same response every time? If not, does that not mean it is in fact mutable?

I read elsewhere that in Elixir programs, there is no difference in messaging a local "agent" or a remote one? The caller does not know whether the other party is remote or not. Is it still guaranteed to be immutable?

Just asking since I don't know much about Elixir.

Re: Managing mutable data in Elixir with Rust

#30

Post by mrkeen »

wredue wrote: post #13
WolfeReader wrote: post #11

Earlier quoted context omitted.

I'm not sure Joe Armstrong would agree with your comment.

I don’t really care what people making claims say when they make claims without evidence. ”Who” makes a claim has no bearing on its truth. Immutability is a tool, not a rule, and I am free to reject any assertion otherwise when those assertions provide no evidence, or shitty anecdotes. Prove your claims. Certainly, immutability is a foundation for performance problems. Another provable rule in computing is that more…

> Another demonstrable fact is that Haskell based programs have just as many bugs as any other programming language whether you have immutability or not. Therefore, immutability is not a bastion of robustness.

Bugs happen when you think you can program something correctly, but can't.

If you look at the implementations of transactions in any other language... Oh wait there aren't any!

People keep trying to implement it in their own languages, figure out it's a non-starter (because of uncontrolled mutation), and give up.

Post reply on HN