OTP 23 • Hacker News Board

Re: OTP 23

#101

Post by eru » Thu, May 14, 2020, 2:32 PM UTC

pdimitar wrote: post #98

eru wrote: post #95

Earlier quoted context omitted.

No, in an actor based model the mutable parts that the comment you replied to mentioned are surfaced to the user. It's not about how the Erlang VM is implemented. You could implement it in pure Haskell and compile it so some hypothetical pure CPU. Wouldn't change that part of how you interact with it that is stateful as described. (And I liked programming in Erlang.)

And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects. But maybe we'll talk the same language if you…

As far as I can tell, that's not what the great-grand parent comment was about.

Have you ever programmed in Erlang?

About your first paragraph: not all databases should be append only, but it would be a good idea to make append-only the default and only deviate for a good reason. (Instead of making mutable the default, and only weirdos go for append-only.)

Re: OTP 23

#102

Post by eru » Thu, May 14, 2020, 2:33 PM UTC

pdimitar wrote: post #97

eru wrote: post #94

Earlier quoted context omitted.

You can write great and useful software in non-composable languages. People write good stuff in C or Go. But if you have the choice, composability always seems much nicer to me and stops me wanting to tear my hair out.

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.

Re: OTP 23

#103

Post by pdimitar » Thu, May 14, 2020, 2:40 PM UTC

eru wrote: post #101

pdimitar wrote: post #98

Earlier quoted context omitted.

And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects. But maybe we'll talk the same language if you…

As far as I can tell, that's not what the great-grand parent comment was about. Have you ever programmed in Erlang? About your first paragraph: not all databases should be append only, but it would be a good idea to make append-only the default and only deviate for a good reason. (Instead of making mutable the default, and only weirdos go for append-only.)

I work almost exclusively with Elixir for 3.5 years and love it. But I am not seeing that poster's point still.

Re: OTP 23

#104

Post by anthony_doan » Thu, May 14, 2020, 3:14 PM UTC

micmus wrote: post #21

macintux wrote: post #17

Earlier quoted context omitted.

I’ve been out of the Erlang world for a few years now, but it doesn’t seem like a great fit for serverless. The VM has a non-trivial overhead, and the language (and VM) design is optimized for long-running, high availability services.

I would say it's mostly that nobody optimized it (perhaps yet) for that environment. There's generally nothing inherently slow in the VM boot sequence - it's just that this was not a priority, so it's slow. There are some attributes suggesting it could be a good fit for that environment, for example, the VM is generally very small - you can get a full system in ~20MB - and that again wasn't something that was heavily…

There was Erlang on Xen using LingVM awhile back.

Re: OTP 23

#105

Post by TeMPOraL » Thu, May 14, 2020, 3:26 PM UTC

pdimitar wrote: post #103

eru wrote: post #101

Earlier quoted context omitted.

As far as I can tell, that's not what the great-grand parent comment was about. Have you ever programmed in Erlang? About your first paragraph: not all databases should be append only, but it would be a good idea to make append-only the default and only deviate for a good reason. (Instead of making mutable the default, and only weirdos go for append-only.)

I work almost exclusively with Elixir for 3.5 years and love it. But I am not seeing that poster's point still.

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 reflected in function signatures.

Re: OTP 23

#106

Post by pythonaut_16 » Thu, May 14, 2020, 3:29 PM UTC

pmontra wrote: post #80

pera wrote: post #63

Earlier quoted context omitted.

> I mean, unlike in typical hard FP languages like Haskell or Elm What is a "typical" FP language? Are Scheme, Common Lisp, OCaml, SML, atypical? > mutable state is rampant in your average Elixir app I don't think this is generally true, or at least not on my experience, but I guess it may depend on what would one consider rampant.

Well, my main Elixir project is the backend of a web service. The input is JSON from the frontend and JSON or XML from a number of third party APIs. We process it, hit the db with select, update, insert and usually return a value. The same function with the same inputs usually returns different values because the db is stateful. What I like of Elixir is not functional programming, it's the extensive use of pattern ma…

I think you are misunderstanding what GenServers are and are for.

GenServers do have their own state, but they are used for way more than just storing state. It's probably best to literally think of it as a server in your running application, analogous to a server running on a network.

If storing state is all you're trying to do you might want to look at Agent or possibly ETS.

Further, GenServers come from Erlang, not Elixir. They're intended to model all sorts of runtime properties of code.

Re: OTP 23

#107

Post by senderista » Thu, May 14, 2020, 4:06 PM UTC

pdimitar wrote: post #98

eru wrote: post #95

Earlier quoted context omitted.

No, in an actor based model the mutable parts that the comment you replied to mentioned are surfaced to the user. It's not about how the Erlang VM is implemented. You could implement it in pure Haskell and compile it so some hypothetical pure CPU. Wouldn't change that part of how you interact with it that is stateful as described. (And I liked programming in Erlang.)

And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects. But maybe we'll talk the same language if you…

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.

Re: OTP 23

#108

Post by pdimitar » Thu, May 14, 2020, 4:18 PM UTC

senderista wrote: post #107

pdimitar wrote: post #98

Earlier quoted context omitted.

And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects. But maybe we'll talk the same language if you…

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.

Re: OTP 23

#109

Post by pdimitar » Thu, May 14, 2020, 4:20 PM UTC

TeMPOraL wrote: post #105

pdimitar wrote: post #103

Earlier quoted context omitted.

I work almost exclusively with Elixir for 3.5 years and love it. But I am not seeing that poster's point still.

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

Re: OTP 23

#110

Post by wtetzner » Thu, May 14, 2020, 4:33 PM UTC

brudgers wrote: post #25

organicfigs wrote: post #16

Earlier quoted context omitted.

I've wanted to work with Elixir for 5 years now. I attempted to go through The Pragmatic Programmer's Elixir textbook and couldn't make it through. This comment applies solely to me, I feel I didn't have the aptitude to pick up functional programming (and that's coming from someone who graduated in CS from a T3, had years of experience, and starting med school next month).

Since it's already been five years, it might be worth considering Erlang instead of Elixr. I'd recommend Programming Erlang: Software for a Concurrent World . It was written by Joe Armstrong who designed Erlang and "sold" it internally across Ericsson to people who were not programmers. They were people who were using Erlang to solve some other problem. The paradigm of Erlang is message passing. The primary idiom is…

> It is a procedural programming abstraction layer.

Is it? When I looked at it, it just seemed to be a Ruby-ish syntax on top of Erlang. It still felt very functional.