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

71–80 of 121 posts

Re: OTP 23

#71

Post by lawik »

bsaul wrote: post #49
lawik wrote: post #46

Earlier quoted context omitted.

I think I understand your concern as the foundation is arguably old. But as someone actively following Erlang and Elixir the sentiment feels absurd. Elixir is very recent, very modern and Erlang/OTP has a very strong track record. There are drawbacks of course but having worked with Python, PHP and JS. I haven't seen any real drawbacks. I wouldn't choose it for minimal overhead or the fastest compute maybe.. Edit: ty…

Are you "following" or are you actually using it in production for a real service ? I'm asking, because to my knowledge, the only "huge number of users" recent success story is whatsapp, and after having viewed all the talks about their stack and experience, it seems that the team was so extremely talented that they probably would have made something good with any tech.

I'm not using it in huge scale. But I've worked with companies that run it in production, yes.

There are a lot of Elixir products and systems out there and before those there were quite a few in Erlang. I don't have a sufficient sample size from my own experience but it is hardly old and disused or too new to be sure.

Changelog podcast runs on it. Dockyard build with it. It seems the new default for many previously Rails shops.

Re: OTP 23

#72

Post by tandr »

hinkley wrote: post #37
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?

Erlang may be the sturgeon of the software world. It has survived since the Triassic and yet is somehow prized for specific use cases and discerning tastes. It is nowhere near as ancient as sharks, nor as vicious, but it employs some new physiology, and can survive just as long. But that was a very different world and it sticks out like an outsider, when really it's been there the whole time. (sorry, this analogy got…

This is beautiful, and quite precise (imho). Thank you!

Re: OTP 23

#73

Post by liveoneggs »

hinkley wrote: post #37
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?

Erlang may be the sturgeon of the software world. It has survived since the Triassic and yet is somehow prized for specific use cases and discerning tastes. It is nowhere near as ancient as sharks, nor as vicious, but it employs some new physiology, and can survive just as long. But that was a very different world and it sticks out like an outsider, when really it's been there the whole time. (sorry, this analogy got…

the story I like to use is -- "imagine a world where java never happened, where servers were abstracted into HA clusters automatically by your programming language, and where horizontal scaling was automatic and free"

Re: OTP 23

#75

Post by lawik »

macintux wrote: post #17
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.

Sounds about right. With wasm being relevant for edge computing and serverless I'm keeping a close eye on the Lumen project compiler as I expect that to be more feasible for this sort of work. The advantages for OTP remain mostly in long-running services. But for Lumen that might be a more open question.

Re: OTP 23

#76

Post by RcouF1uZ4gsC »

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

One of the really nice things about shared-nothing concurrency is that it scales to multiple machines. The same code that works locally will work across a data center. Along the same lines, shared-nothing tends to scale better as you add cores. With lock based programming, as you add cores, many times your contention increases minimizing the benefits of the additional cores.

Re: OTP 23

#77

Post by querulous »

brokencode wrote: post #29
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…

If you look closely enough at Haskell, you’ll realize that it also can have a lot of mutable state. Haskell just puts state into various monads and STM to make its functions pure. You can even spawn numerous isolated threads, all with their own state, and have them communicate with one another like you do in Elixir. It does provide a lot of structure and guarantees compared to your standard imperative language, but I…

a process is a singleton even tho the code it runs is reused

Re: OTP 23

#78

Post by brokencode »

querulous wrote: post #77
brokencode wrote: post #29

Earlier quoted context omitted.

If you look closely enough at Haskell, you’ll realize that it also can have a lot of mutable state. Haskell just puts state into various monads and STM to make its functions pure. You can even spawn numerous isolated threads, all with their own state, and have them communicate with one another like you do in Elixir. It does provide a lot of structure and guarantees compared to your standard imperative language, but I…

a process is a singleton even tho the code it runs is reused

I’m not sure what you mean. A singleton is something your program only has one of. You can have any number of processes. By your logic, every object in an object-oriented language is also a singleton.

Re: OTP 23

#79

Post by bcrosby95 »

liveoneggs wrote: post #73
hinkley wrote: post #37

Earlier quoted context omitted.

Erlang may be the sturgeon of the software world. It has survived since the Triassic and yet is somehow prized for specific use cases and discerning tastes. It is nowhere near as ancient as sharks, nor as vicious, but it employs some new physiology, and can survive just as long. But that was a very different world and it sticks out like an outsider, when really it's been there the whole time. (sorry, this analogy got…

the story I like to use is -- "imagine a world where java never happened, where servers were abstracted into HA clusters automatically by your programming language, and where horizontal scaling was automatic and free"

I usually blame nodejs. It came around and pushed out what little traction Erlang was gaining in the late 00s.

Re: OTP 23

#80

Post by pmontra »

pera wrote: post #63
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 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 matching. What I like less is the convoluted syntax of GenServer with all those handle_cast/calls that obfuscate the real code. As a GenServer is usually a way to store a state, they should have had the courage of calling them objects and give them an object like syntax. After all they initially sold Elixir to developers coming from OO languages. If they had given it a Java like syntax maybe it would be 10 or 100 times as big by now.

Post reply on HN