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

Why Erlang Matters

sameroom.io

Post reply on HN
Print view View original

81–90 of 210 posts

Re: Why Erlang Matters

#81

Post by adrusi »

jerf wrote: post #6
jandrese wrote: post #2

I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such…

Erlang may be useful for coordinating computation tasks, but, yes, even with HIPE it is not a good numerical language on its own. It would be interest to re-engineer a language today that tries to fit into Erlang's niche but has a stronger performance focus. Rust, Cloud Haskell, and Go all sort of cluster in the area I'm thinking about, but none are quite what I'm thinking of. Cloud Haskell is probably closest but wr…

You can't really achieve Erlang's goals with a statically typed language, at least it would be very hard to make it easy to intuit whether a live reload will be sound.

A language that allows mutable state aside from at process scope is also a no-go. In Erlang you're not supposed to think about what code will be running on which machines as you write the business logic, so you have to assume that every process is running on a seperate machine with no shared memory, so no mutable state above the process level. And mutable state at local scope makes hot swapping code messier, although that's easier to work with than static typing.

Nothing about Erlang is inherently slow. Someone could hire a bunch of developers from v8 or Spidermonkey or maybe just Mike Pall to write a better Erlang runtime.

Re: Why Erlang Matters

#82

Post by ssmoot »

vvanders wrote: post #78
ssmoot wrote: post #74

Earlier quoted context omitted.

And maybe in a project with truly massive memory requirements that's an issue. I've never encountered it (as an issue that is) But I only got into the JVM on 1.6 with Jruby, made the switch to Scala around 1.7, and have been on 1.8 pretty much since release. A 3GB heap is pretty typical, but that's mostly just room for cache. If you're writing web-apps, there's a ridiculous amount of opportunity for using Actors to g…

Not everything is web-apps either. If you've got soft realtime requirements( Erlang's GC model is just incredibly elegant. Almost like pooled allocators that we used to use in GameDev but in a completely transparent and intuitive way.

I'll concede that. But you have to admit this is an incredibly niche problem space.

OTOH the JVM will have much higher throughput on the other 99% of apps.

Don't get me wrong. I like Erlang. It's definitely in my top.. Uhm... 3 languages of interest. Being the only other language I know with Pattern Matching is a huge huge part of that.

For most developers I'd just be careful in making that jump. Because most of what this article is about isn't Erlang specific. It's more like a pretty small club of platforms/languages. IMO.

Re: Why Erlang Matters

#83

Post by andy_ppp »

jlouis wrote: post #72
andy_ppp wrote: post #60

Earlier quoted context omitted.

https://github.com/thejerf/suture Supervisors for golang. It looks excellent. I personally have fallen for Elixir and think the syntax, immutability, community and class functionality like Phoenix.Presence make me bet that it'll be bigger than Python for jobs in 5 years.

Supervisors is only half the game here. Suppose A sends a message to B and decides to wait around for the answer. B now divides by zero. In Go, your whole program is in consistency trouble and you have to write code to handle the case. In Erlang, your monitor on B means you get told it is dead via an async exception delivered into your mailbox. I know what kind of system I want to work with here :)

Wow. That's just incredible. I seem to keep saying that the more I learn about Erlang/Elixir.

Re: Why Erlang Matters

#84

Post by jeremyjh »

atemerev wrote: post #47

AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler. All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge. And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggrega…

There is one other. Haskell has green threads, a preemptive scheduler, and it has a pretty decent implementation of Erlang-inspired multi-node concurrency primitives and higher-level framework including supervisors, gen_server equivalent etc in the Cloud Haskell project. It does NOT have Erlangs deployment base and track record but it is still a very promising framework and very appealing if you like Haskell's type system.

http://haskell-distributed.github.io/

Re: Why Erlang Matters

#85

Post by simoncion »

dmix wrote: post #44
rb808 wrote: post #8

I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant. Is Erlang too esoteric?

Having spent quite a bit of time searching for Erlang packages on Github recently, I've found quite a few Erlang packages haven't had commits since around 2013. I believe there was a spike in adoption around 2012-2013 which resulted in a bunch of activity on Github. Which seemed to have tapered off recently. But you still find many core packages that are active - things like JSON parsers, templating libraries, and we…

Man, whoever redesigns erlang.org needs to think really hard about how they're going to re-work the documentation section. It's really good as is:

* Color scheme and fonts are easy to read.

* One can switch between API reference for the current module and Users Guide for its containing application with one click.

* On the left-hand-side one has a scrollable tree of modules in the current application, each of which is expandable to reveal the API calls within any given module.

* Sensible URL scheme: doc/man/$MODULE.html for a module's API docs and doc/apps/$APP/users_guide.html for an application's Users Guide.

Re: Why Erlang Matters

#86

Post by strmpnk »

findjashua wrote: post #57
dewiz wrote: post #56

Earlier quoted context omitted.

So is preemptive or cooperative better in your opinion ? I couldn't figure it out from your comment.

preemptive. Cooperative scheduling runs the risk that a long-running actor might starve the other actors

Exactly. In terms of fault tolerance, a buggy actor is isolated in regards to scheduling others. Bad behavior has a more limited scope.

This isn't to say that one can't create a process that eventually has harmful consequences to the entire system, it just means it's much less likely. These little points of isolation add up. Scheduling, memory management, lifecycle, crashes, &c... It's why it's a bit funny when I hear Akka compared. Akka is quite impressive but I'd never consider it a true alternative to an Erlang or BEAM style runtime.

Re: Why Erlang Matters

#88

Post by querulous »

bitmadness wrote: post #53

Erlang is glacially slow. Even on a 20 core machine, a multithreaded Erlang implementation will usually be trounced by a good singlethreaded C++/Go/Java implementation. All this stuff about multicore scaling is baloney - who cares it is scales and is still slow?

speed isn't a scalar. sometimes you care about latency. sometimes you care about throughput. sometimes you care about arithmetic.

http://www.phoenixframework.org/blog/the-road-to-2-million-w...

Re: Why Erlang Matters

#89

Post by querulous »

ssmoot wrote: post #75
Xixi wrote: post #50

Earlier quoted context omitted.

It's not at all about segfaults. Assuming the Erlang VM is as likely/unlikely to crash as the JVM, then it's a complete wash: Erlang processes are green-threads, not OS processes, so you don't gain anything there. It's about the share-nothing architecture of Erlang: it means your processes are isolated and can be stopped/restarted independently, crash/hang without writing into the memory of another process, have thei…

Akka checks most of those boxes AFAIK. And there's really not much you can do in the way of cheating unless I misunderstand you. Or at least idiomatically you wouldn't cheat in Scala anyways. Speaking of which, I just realized the AtomicLong I'm using in my IdGenerationActor (performs an atomic increment of a processId counter in the database, then uses that with the AtomicLong as the input to Hashids; fast, in-proce…

this is just not true. every other week i have production issues because akka managed to exhaust the thread pool with long running/nonresponsive actors
Post reply on HN