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

141–150 of 210 posts

Re: Why Erlang Matters

#141

Post by rdtsc »

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…

I am excited for a continued improvement and enhancement to the language.

Erlang 18 brought maps, people complained about that for years. Erlang 18 also brought (via a feature flag) dirty schedulers so can have long running C function embedded in without messing up process scheduling also an often requested features. Probably the best thought-out handling of time in any language I've seen so far ( synchronization, warping, moving backwards: http://erlang.org/doc/apps/erts/time_correction.html )

Erlang 19 is exciting as well -- 10x faster tracing, dirty schedulers turned on by default, a new state machine OTP module, an external plugin (with LevelDB as one example) for Mnesia storage also something people complained, 2x-3x faster spawning external processes + many others.

The impressive part is that these changes are done to a 30 year old language.

Re: Why Erlang Matters

#142

Post by simula67 »

Please let me ask some noob questions.

> Erlang matters today because it demonstrates how these semantics can be elegantly packaged in one language, execution model, and virtual machine.

Why is it so important to demonstrate that these semantics can be packaged into such a homogeneous environment ? Is it even a good idea ? Is this way of doing things superior to having micro-services that talk to each, all managed by a supervisor system ? Wouldn't that allow us to take advantage of the unique upsides of multiple programming languages, virtual machines and execution models ?

Re: Why Erlang Matters

#143

Post by MichaelGG »

amsha wrote: post #66

Any programming language can do IPC, but Erlang/Elixir is the only language I've seen that makes it really easy. Erlang IPC is transparent whether you're sending messages between to local processes or remote processes. Most languages have trouble with local IPC (usually because of race conditions in data). Every other language I know of, including Go, needs custom code to handle remote IPC.

It just seems that all the effort going into Erlang would be better spent on making the OTP stuff as a library for a popular, cross-language platform. Like the JVM (or maybe .NET.)

Re: Why Erlang Matters

#144

Post by Tomte »

simula67 wrote: post #142

Please let me ask some noob questions. > Erlang matters today because it demonstrates how these semantics can be elegantly packaged in one language, execution model, and virtual machine. Why is it so important to demonstrate that these semantics can be packaged into such a homogeneous environment ? Is it even a good idea ? Is this way of doing things superior to having micro-services that talk to each, all managed by…

You may underestimate the difficulty of writing a bullet-proof and feature-rich "supervisor system". That has pretty high complexity and lots of nasty edge-cases.

Erlang happens to nail that part with OTP.

Re: Why Erlang Matters

#145

Post by pron »

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…

Quasar has preemptive scheduling for fibers/actors on the JVM.

Re: Why Erlang Matters

#146

Post by sa1 »

logicchains wrote: post #124
jeremyjh wrote: post #84

Earlier quoted context omitted.

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 s…

Just a nitpick, but Haskell's scheduler (like Go's) is "less preemptive" than Erlang's. If you have e.g. i = 0 for{ i += 1 } or equivalent in Go/Haskell, then the HS thread/goroutine running it cannot be interrupted, as interruption can only take place at certain points (e.g. allocation or function calls). Erlang on the other hand assigns a certain amount of time units to each process, and each pure-Erlang operation…

Admittedly, Haskell is less preemptive than Erlang, but definitely not at the same level as Go. A mutating variable is not what you commonly use in Haskell, so the idiomatic equivalent of your code would have memory accesses anyway, and it would be possible to interrupt it.

Re: Why Erlang Matters

#147

Post by querulous »

MichaelGG wrote: post #143
amsha wrote: post #66

Any programming language can do IPC, but Erlang/Elixir is the only language I've seen that makes it really easy. Erlang IPC is transparent whether you're sending messages between to local processes or remote processes. Most languages have trouble with local IPC (usually because of race conditions in data). Every other language I know of, including Go, needs custom code to handle remote IPC.

It just seems that all the effort going into Erlang would be better spent on making the OTP stuff as a library for a popular, cross-language platform. Like the JVM (or maybe .NET.)

sure. we can start when the jvm can do preemptive scheduling of processes

erlang isn't great because of a single feature or library, it's great because it's designed from the ground up for one very particular role. you can't just port the otp api to go or the jvm. you need the whole foundation

Re: Why Erlang Matters

#148

Post by pmontra »

jrobn wrote: post #100
pmontra wrote: post #51

Earlier quoted context omitted.

He probably means that an Erlang process is equivalent to an object and message passing among processes is equivalent to method calls. In my experience with Elixir, objects, method calls and mutable data are easier to write than processes, messages and immutable data. It's not the mutable and immutable part, it's more about the boiler plate of spawning processes, receiving messages and matching them to dispatch them…

There is Pony ( http://www.ponylang.org ).

Interesting language, thanks. What's the amount of adoption to date?

Re: Why Erlang Matters

#149

Post by simoncion »

rdtsc wrote: post #141
dmix wrote: post #44

Earlier quoted context omitted.

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…

I am excited for a continued improvement and enhancement to the language. Erlang 18 brought maps, people complained about that for years. Erlang 18 also brought (via a feature flag) dirty schedulers so can have long running C function embedded in without messing up process scheduling also an often requested features. Probably the best thought-out handling of time in any language I've seen so far ( synchronization, wa…

mnesia_leveldb is scheduled for OTP 19? That's great news!

I can't tell you how many times I've cursed at the overfilled-hours-ago-but-mnesia-didnt-care DETS table shard. Getting a on-disk backend that can store more than 2GB at a time will be great!

It'll be even better if the writer code actually notices failures to write to the backing store and aborts transactions when they happen! [0] :)

[0] Seriously, who thought it was a good idea to ignore the return value from dets:insert/2? :(

Re: Why Erlang Matters

#150

Post by ngrilly »

logicchains wrote: post #124
jeremyjh wrote: post #84

Earlier quoted context omitted.

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 s…

Just a nitpick, but Haskell's scheduler (like Go's) is "less preemptive" than Erlang's. If you have e.g. i = 0 for{ i += 1 } or equivalent in Go/Haskell, then the HS thread/goroutine running it cannot be interrupted, as interruption can only take place at certain points (e.g. allocation or function calls). Erlang on the other hand assigns a certain amount of time units to each process, and each pure-Erlang operation…

Yes, an Erlang process can be interrupted at any point, unlike Go/Haskell, but this is at the cost of bytecode interpretation. I'm not saying it is bad, but there is a tradeoff.
Post reply on HN