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

OTP 23

erlang.org

Post reply on HN
Print view View original

111–120 of 121 posts

Re: OTP 23

#111

Post by [deleted] »

senderista wrote: post #67
pdimitar wrote: post #59

Earlier quoted context omitted.

> But I'll never understand that people like Elixir for being FP. To me the answer is: using mutable state is opt-in. I disagree that "mutable state is rampant". By opting in to the mutable state constructs you are basically saying "I know what I am doing, let me do my work" which is IMO quite fine because "pure" FP languages like Haskell can be a huge hassle when you actually need to deal with the real world. To me…

Mutable state is essential to the actor model. Local arguments to a tail-recursive message loop which change based on the last received message and the previous arguments, and determine behavior (i.e. messages sent and side effects), are equivalent to local mutable state. State machines are a lot better than unstructured, freely mutable global variables, but they are still mutable state.

[deleted]

Re: OTP 23

#112

Post by pbadenski »

A few random questions.. hopefully a person more knowledgable in the topic can help me out:

- from what I understand Akka (Scala) heavily borrows from Erlang/OTP - is this correct? What would be the biggest similarities/differences?

- to what extent OTP is unique to Erlang and to what extent it can be implemented in another language?

- any articles/materials out there showing the most valuable bits of OTP applied in JavaScript/NodeJS?

Re: OTP 23

#113

Post by dnautics »

pdimitar wrote: post #96
dnautics wrote: post #88

Earlier quoted context omitted.

Actor frameworks don't compose, because actors are an atomic compute unit. You can't really take a horse actor and a bird actor and turn them into a pegasus actor. There are non-trivial interactions between message handling logic that would prevent such a thing with some fairly trivial-to-generate breaking cases. Maybe composition for compositions' sake isn't that important?

> Maybe composition for compositions' sake isn't that important? Definitely. I was about to ask "but when did you actually need to compose actors and how does that even make sense?" -- and while I am sure there are people who would find a scenario I feel that would still be tarrying on minutiae. Obviously the actor model is not a panacea. But for my commercial work Elixir -- and thus Erlang's OTP -- has been a true b…

Yep I love Elixir too. Just, you know, I try to only sip the kool-aid.

Re: OTP 23

#114

Post by dnautics »

eru wrote: post #102
pdimitar wrote: post #97

Earlier quoted context omitted.

This is definitely true, I am just not sure how well it applies to actors. For all data-modelling scenarios and OOP/FP ways of doing polymorphism, composability is a life-saver though.

It's a good question. Let me meditate on actors and STM. Perhaps there's a way to get something like vectors that's composable.

The point of the actor model, at least in OTP, is not to have the actor model as a unit of computation (as was imagined by Hewitt, et, al) but as a failure domain. Erlang was not designed to be an actor system, it was designed to be a robust system and they later discovered that what they had built was more or less the actor model (if an impure version) and it was easy to communicate the architecture's computational capabilities and mental model as actors. Actually I think if anything it's led to a fair share of misunderstandings, and truly misses the important and unique aspects of Erlang processes.

In the sense of being failure domains, OTP "actors", or processes, ARE composable. With very little boilerplate, that is built in as primitive BIFs in the standard library, I can bundle failure domains together and orchestrate them using links, monitors, and supervision strategies, with the ultimate failure domain being a single erlang VM operating inside a cluster of erlang VMs, all supported without third party libraries as a part of the way of doing things.

Re: OTP 23

#115

Post by pdimitar »

dnautics wrote: post #113
pdimitar wrote: post #96

Earlier quoted context omitted.

> Maybe composition for compositions' sake isn't that important? Definitely. I was about to ask "but when did you actually need to compose actors and how does that even make sense?" -- and while I am sure there are people who would find a scenario I feel that would still be tarrying on minutiae. Obviously the actor model is not a panacea. But for my commercial work Elixir -- and thus Erlang's OTP -- has been a true b…

Yep I love Elixir too. Just, you know, I try to only sip the kool-aid.

Well, I am just now arguing with people in another thread that nobody claims that Elixir is an end-all be-all.

It's quite sad how fiercely the average HN audience is attacking people who are trying to show an alternative way of doing things.

Re: OTP 23

#116

Post by eru »

pdimitar wrote: post #108
senderista wrote: post #107

Earlier quoted context omitted.

My point was that the actor model has the semantics of local mutable state. The fact that an actor model language is compiled for a von Neumann machine is irrelevant to my point.

Okay, that's true, but especially in Erlang's BEAM VM the mutable state's access is serialized / centralized. An actor's state is not a globally modifiable volatile variable a la the C/C++ ones.

Yes.

Though I don't think anyone ever suggested the actor model (or Erlang) was doing C/C++ craziness.

Re: OTP 23

#117

Post by Multicomp »

I must admit, I have been watching erlang for a while trying to decide when to hop in, and I have increasingly come to the conclusion that I will not be learning erlang as such, although I will be buying the books and reading them, but I will be learning gleam, which is erlang with types.

I'm too used to the safety that rust or F# gives at compile time to give that up.

Re: OTP 23

#118

Post by rad_gruchalski »

pdimitar wrote: post #65
morty_s wrote: post #50

Earlier quoted context omitted.

Same. Or similar, it’s taken longer than it should for me to appreciate the functional paradigm. Rust and Scheme have been gateway drugs ha. I found I really like OCaml-y languages. Now, I’m very interested in Erlang (and to some degree elixir). I’m learning as much as I can about Erlang and the ecosystem; I’m trying to answer the question, “why isn’t Erlang more popular?” Any guesses? Reasons? (syntax aside)

I might sound bitter but after about 3.5 years with Elixir my answer is very simple and boils down to: Habit, confirmation bias, sunk cost fallacy. Namely: people have gotten a lot of battle scars by working with what pays their bills -- PHP, Ruby, Python, C#, Java -- and they refuse to look at an alternative because that would render their huge time and energy investment moot (in their eyes at least; I don't see why…

I've got those scars but I still find erlang refreshing when working with it. Unfortunately, as software engineers, we work in groups and there are many people having these scars. However, the erlang experience changes one forever.

Re: OTP 23

#119

Post by pdimitar »

rad_gruchalski wrote: post #118
pdimitar wrote: post #65

Earlier quoted context omitted.

I might sound bitter but after about 3.5 years with Elixir my answer is very simple and boils down to: Habit, confirmation bias, sunk cost fallacy. Namely: people have gotten a lot of battle scars by working with what pays their bills -- PHP, Ruby, Python, C#, Java -- and they refuse to look at an alternative because that would render their huge time and energy investment moot (in their eyes at least; I don't see why…

I've got those scars but I still find erlang refreshing when working with it. Unfortunately, as software engineers, we work in groups and there are many people having these scars. However, the erlang experience changes one forever.

As you said, unfortunately programming turned out to be quite the tribalistic activity indeed.

I got severely disheartened that 2-3 casual mentions of Elixir were enough for several people in this thread to attack and quickly stereotype me. I think I'll just keep quiet, or at least not mention what I work with. This seems to get the message across much better.

Re: OTP 23

#120

Post by eru »

pdimitar wrote: post #109
TeMPOraL wrote: post #105

Earlier quoted context omitted.

I understand the point as: being able to send a message to a particular actor, passing it a value that you can later retrieve by sending that same actor another message, is semantically exactly the same as calling a setter on an object reference, and later calling a getter to get the value back. In both cases you have a pocket of mutable state, potentially accessible by multiple unrelated places in code, that isn't r…

Mostly true, minus the fact that the mutable state's access is serialized / centralized due to the nature of Erlang's actors (lightweight threads; usually called fibers in other languages, and even that is not a good analogy since they are preemptive and not cooperative). So the semantics being similar is not strictly and 100% true. You can't do non-atomic volatile modification like you can in C/C++.

> You can't do non-atomic volatile modification like you can in C/C++.

Yes, exactly. No one was implying that Erlang's model is mimicking those particularly weird languages. The statement was much more narrow.

Post reply on HN