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

11–20 of 121 posts

Re: OTP 23

#11

Post by unvs »

Grimm1 wrote: post #9
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 was in the same boat until discovering elixir/erlang it has by far been the most approachable functional language for me and it has been a gateway drug of sorts into experimenting with ocaml and various lisps. I personally think elixir is really special and an amazing fit for any project that needs high IO concurrency.

Agreed! I found learning Elixir to be a great gateway to learn Erlang as well. When I first tried learning Erlang (before Elixir was released), it became a bit too much to wrap my head around. It was a lot easier when I had gotten the fundamentals of FP down through Elixir, though!

Re: OTP 23

#12

Post by dnautics »

Grimm1 wrote: post #9
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 was in the same boat until discovering elixir/erlang it has by far been the most approachable functional language for me and it has been a gateway drug of sorts into experimenting with ocaml and various lisps. I personally think elixir is really special and an amazing fit for any project that needs high IO concurrency.

IMO erlang (and arguably even more, elixir) is "functional for the working programmer". It doesn't drown itself in academic abstractions, uses functional programming as a tool to guardrail you from mistakes (in the same way that C guards the programmer from making asm mistakes), with escape hatches that are battle-tested and justified based on decades of experience.

I would say the only other functional language that has the same bent is Julia, which is "functional for the working scientist". It makes different choices about where to expose state, understandable, since scientific computing has different tradeoffs from systems programming.

Re: OTP 23

#13

Post by mcintyre1994 »

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

On the Elixir/OTP side I've really enjoyed this course too: https://pragmaticstudio.com/elixir They have a current discount code LIVEVIEW (not affiliate), which is advertised on their currently free early access Phoenix live view course.

Re: OTP 23

#14

Post by xutopia »

Though I am not working with Erlang or Elixir right now I am so pleased that this is seeing improvements. I had as much fun learning Elixir as I did learning Ruby ages ago. It's just a fun language with great construct!

Re: OTP 23

#15

Post by bicx »

mikece wrote: post #8

Does cloud-based serverless computing compete with or complement Erland/Elixir? As a dotNetCore developer who writes a lot of Lambda and Azure function code I am trying to understand how OTP relates to these paradigms or if they are apples and oranges.

It's apples and oranges.

OTP paradigms are definitely intended for a larger system that needs its own distribution schemes, handles its own internal process uptime and restarts, and for some use cases, hot code updates (running servers that update without restarting). OTP nodes can also easily and natively communicate between each other across the network, allowing for some pretty sophisticated distributed systems.

There are many solutions that could be more easily implemented on some sort of serverless architecture, but in cases where you want to maintain a service with a high degree of reliability and distributed capability, OTP is a good choice. After all, it was developed for the telecom industry to handle phone system communications loads.

Worth noting: there are other solutions (some of which are already in serverless environments) that solve the same problems of service uptime during code updates/deployment by keeping an older instance running until the new instance is ready to accept traffic. Services like Kubernetes also implement a lot of cluster management capabilities that solve the same problems OTP was attempting to solve, and you can use whatever language and engine/framework you want. Personally, I think if you wrote a service purely in Erlang/Elixir and directly applied all OTP solutions for uptime, process communication, and distribution, it would be faster and more efficient than a typical serverless or container-based system. But, it would also lock you into that system and make any non-OTP tech more difficult to integrate.

Re: OTP 23

#16

Post by organicfigs »

xutopia wrote: post #14

Though I am not working with Erlang or Elixir right now I am so pleased that this is seeing improvements. I had as much fun learning Elixir as I did learning Ruby ages ago. It's just a fun language with great construct!

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

Re: OTP 23

#17

Post by macintux »

mikece wrote: post #8

Does cloud-based serverless computing compete with or complement Erland/Elixir? As a dotNetCore developer who writes a lot of Lambda and Azure function code I am trying to understand how OTP relates to these paradigms or if they are apples and oranges.

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.

Re: OTP 23

#18

Post by brudgers »

mikece wrote: post #8

Does cloud-based serverless computing compete with or complement Erland/Elixir? As a dotNetCore developer who writes a lot of Lambda and Azure function code I am trying to understand how OTP relates to these paradigms or if they are apples and oranges.

Erlang is a message passing language for writing concurrent applications. Architecturally, Erlang programs share logical similarity with microservices. Architecturally, OTP shares some conceptual similarity with serverless frameworks.

Together, Erlang and OTP provide a batteries included environment for building and running scalable concurrent systems. Scalable down to any device that will run Linux, not just up into the cloud.

Re: OTP 23

#19

Post by dnautics »

ponyous wrote: post #4

Couple of times when somebody posted an OTP erlang update I had no clue what I was reading. Then I came back to HN and somebody broke down why some things are really useful/changed and it was mind blowing. Can some erlanger explain why you are excited about certain things from the update?

much of it is a lot of hard work getting to support TLS 1.3, which is nice. I have some TLS-dependent things in prod and let me say, it is really easy to do TLS in OTP. It's also easy to do TLS wrong in OTP, so I recommend watching all of Bram Verburg and Ingela Anderton Antin's videos first.

the socket library (if I am correct) is the beginning of redoing the entire network stack in a way that is more commensurate with the way that typical programmers expect (but with the right erlang-ey).

> Allow underscores in numeric literals to improve readability

This is great whenever a language does it.

> The embedded documentation is created as docchunks (EEP 48)

It looks like the erlang community is converging on the elixir strategy for documentation. This is fantastic, since elixir documentation is quite good, and it shows that the two languages are starting to put their friendly animosity aside and really working together.

> distributed named process groups is introduced

This is kind of huge. Sometimes you want a locking, fully consistent process management (so CRDTs are inappropriate), and you don't want a full raft/paxos under the hood.

Re: OTP 23

#20

Post by dnautics »

organicfigs wrote: post #16
xutopia wrote: post #14

Though I am not working with Erlang or Elixir right now I am so pleased that this is seeing improvements. I had as much fun learning Elixir as I did learning Ruby ages ago. It's just a fun language with great construct!

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

There's a reputation that functional programming is harder than object-oriented. I think this comes from the very difficult functional programming languages that exist out there. I think that can be an obstacle. People hear "fp" and think "hard".

I personally find Elixir's functional programming is easier, because there are fewer things you have to deal with than object oriented. There are basically no constructs in Elixir that you don't have out of the box in an OO language like Javascript or Python. You just have to deal with that you can't do things like assign variables in if statements (you just have to explicitly export them) and you don't have for loops.

Having said that, Enum.map and Enum.reduce are really hard to get used to and can be an obstacle in terms of "why can't I do this thing that is so easy in X".

In the long run, once you get used to reading them (which honestly took me about 4-5 months, I have like 20+ years of programming experience) I think they are easier because they are declarative -- you can see exactly what is happening to each piece of your list and in the case of reduce, what state is being passed through each iteration.

For loops are far more unstructured, literally anything in any of your parent scopes could be what you're keeping track of through iterations, which means, your mistake surface area is much much higher. The same goes for getting used to "if statements that export values" but, maybe, less dramatically.

I know this is difficult to hear since you gave up, but I promise you if you push through it, eventually it will feel like writing elixir is "programming with training wheels on" you can do crazy hard things without worrying about large classes of logical and structural programming errors. Hope you come back to it!

Post reply on HN