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

61–70 of 121 posts

Re: OTP 23

#61

Post by pdimitar »

gmfawcett wrote: post #45
derefr wrote: post #41

Earlier quoted context omitted.

I mean, yes? OTP is a framework—a paradigm for writing your code in, essentially—but it's an optional one. That's why it's split out from Erlang itself. You can write Erlang however you like. Most people choose to write it in the OTP paradigm. But sometimes that's not the best choice (e.g. the type of code that leex/yecc generates, does not obey OTP principles, nor would it help it in any way if it did.)

Fair point. Big frameworks and dogma go hand in hand, and I suppose Erlang without OTP is at least as practical as any other language. I wonder though if Erlang might have been a footnote in programming history if it weren't for the mindshare that OTP generated. "Simple functional language" is attractive, but "simple functional language with world-class platform" turned out to be a game-changer.

> I wonder though if Erlang might have been a footnote in programming history if it weren't for the mindshare that OTP generated.

It absolutely would be. There's plenty of "simple FP languages" out there. OTP is very definitely the main selling point of Erlang, and nowadays of Elixir as well.

Re: OTP 23

#62

Post by pdimitar »

nurettin wrote: post #38
skrebbel wrote: post #27

Earlier quoted context omitted.

I never understood why people rave so much about functional programming wrt Erlang/Elixir, when its functional programming is clearly only a means to an end (fast and safe message passing requires immutable data, which requires FP) and not a driving design goal in its own right. I mean, unlike in typical hard FP languages like Haskell or Elm, mutable state is rampant in your average Elixir app, it's just spread out a…

I have a prototype system where I am passing over 100k msg/sec between a dozen backend services written in python (asyncio+redis) and I keep on wondering when my bottleneck will become functional programming and safe message passing by making copies. When will the madness end?

Tradeoffs. In the setup you describe I'd pick correctness over performance any day.

If you hit a performance bottleneck you might as well just use RabbitMQ or Kafka to queue up stuff and process it as it comes along. Or apply back-pressure if your current code allows for it.

Re: OTP 23

#63

Post by pera »

skrebbel wrote: post #27
moviedo wrote: post #5

I'm currently learning erlang/elixir and I'm really enjoying the language constructs. I had originally taken a Programming Language Paradigms class in college with racket, and I really didn't appreciate functional ideas(i.e. syntax is my excuse). I'm now a really big fan of functional language idioms. Anyone interested should try the futurelearn class, https://www.futurelearn.com/courses/functional-programming-e... .

I never understood why people rave so much about functional programming wrt Erlang/Elixir, when its functional programming is clearly only a means to an end (fast and safe message passing requires immutable data, which requires FP) and not a driving design goal in its own right. I mean, unlike in typical hard FP languages like Haskell or Elm, mutable state is rampant in your average Elixir app, it's just spread out a…

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

Re: OTP 23

#64

Post by toast0 »

bsaul wrote: post #55
toast0 wrote: post #52

Earlier quoted context omitted.

I've used Erlang/OTP only on stateful servers, and observed its use in semi-stateless containerized deployment (but in that case, we were generating the containers to have a fictional state; we always had nodeX@hostnameY even if the container being that node moved around). However, OTP ships with a diskless mode, where all of the code and config, other than BEAM and modules critical to starting dist come from dist.

Stateful servers seems like an atrocious point of failure nowadays (except if it's a DB server, or a persistent queue). And i barely see it anymore, now that everything seems to be running on containers or VM that are supposed to be destroyable at any time. That's why the value of OTP seems to be less obvious at the moment (from the point of view of someone who doesn't use it). But there's surely something i'm missin…

Decently built servers don't fail that often. If you're going to run a couple thousand servers, you'll want them to be bare metal, because VM overhead is real.

If your system is designed properly, it's not unreasonable to have a node out of service for a couple hours while it's repaired. Nodes which don't have database state can often wait until business hours to be repaired, if there are enough nodes that you can have a few down.

Re: OTP 23

#65

Post by pdimitar »

morty_s wrote: post #50
moviedo wrote: post #5

I'm currently learning erlang/elixir and I'm really enjoying the language constructs. I had originally taken a Programming Language Paradigms class in college with racket, and I really didn't appreciate functional ideas(i.e. syntax is my excuse). I'm now a really big fan of functional language idioms. Anyone interested should try the futurelearn class, https://www.futurelearn.com/courses/functional-programming-e... .

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 this has to be the case but plenty of people have been adamant about this without giving an explanation).

I've only become a better programmer since I adopted Elixir but I never stopped using other languages.

All of that plus what PG calls "the middlebrow dismissal" are the main reasons IMO. People are just too set in their ways.

Re: OTP 23

#66

Post by pdimitar »

zeroc8 wrote: post #35
brudgers wrote: post #25

Earlier quoted context omitted.

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…

I've tried learning both and Erlang seems to be less magical and more consistent. That said, I wouldn't dare to start an important project in either language for the fear of getting stuck somewhere along the way. With Go, there are no such concerns, even though the language itself is by far less elegant.

A valid concern but you should have in mind that ElixirForum is one of the friendliest and most helpful programming communities that you will find out there. And that's not coming from me or Elixir veterans but from a ton of newbies, regularly.

Re: OTP 23

#67

Post by senderista »

pdimitar wrote: post #59
skrebbel wrote: post #27

Earlier quoted context omitted.

I never understood why people rave so much about functional programming wrt Erlang/Elixir, when its functional programming is clearly only a means to an end (fast and safe message passing requires immutable data, which requires FP) and not a driving design goal in its own right. I mean, unlike in typical hard FP languages like Haskell or Elm, mutable state is rampant in your average Elixir app, it's just spread out a…

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

Re: OTP 23

#68

Post by nurettin »

pdimitar wrote: post #62
nurettin wrote: post #38

Earlier quoted context omitted.

I have a prototype system where I am passing over 100k msg/sec between a dozen backend services written in python (asyncio+redis) and I keep on wondering when my bottleneck will become functional programming and safe message passing by making copies. When will the madness end?

Tradeoffs. In the setup you describe I'd pick correctness over performance any day. If you hit a performance bottleneck you might as well just use RabbitMQ or Kafka to queue up stuff and process it as it comes along. Or apply back-pressure if your current code allows for it.

I actually use redis hashsets to queue stuff when I need correctness. Much more performant than rmq's mnesia

Re: OTP 23

#69

Post by nurettin »

bsaul wrote: post #42
nurettin wrote: post #38

Earlier quoted context omitted.

I have a prototype system where I am passing over 100k msg/sec between a dozen backend services written in python (asyncio+redis) and I keep on wondering when my bottleneck will become functional programming and safe message passing by making copies. When will the madness end?

i don't think erlang is requiring FP + immutable + message passing for performance, but rather for correctness. Making copies is actually more expensive in terms of perf.

me too, and I have no clue as to how changing language can increase correctness in my case. I can think of other use cases where in-process concurrency and mutating data structures could cause problems, but I avoid those scenarios entirely anyway.

Re: OTP 23

#70

Post by pdimitar »

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.

Sure. That's absolutely unavoidable in any FP language. All their compilers invisibly produce a lower-level code that's intrinsically using the mutable paradigm. It's how our hardware works currently.
Post reply on HN