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

What's all this fuss about Erlang? (2007)

pragprog.com

Post reply on HN
Print view View original

181–190 of 193 posts

Re: What's all this fuss about Erlang? (2007)

#181

Post by BeetleB »

brightball wrote: post #170
BeetleB wrote: post #151

Earlier quoted context omitted.

>If one piece of the system would take a long time to finish, it doesn't interfere with the other parts of the system completing their work on schedule. That one blocking piece will finish more slowly, but ever other moving part in the system will keep responding as expected. That's how it works in pretty much any language that supports message passing. I used to do MPI programming in C. Nothing you said is not true…

My understanding is that those languages rely on cooperative scheduling within a thread, meaning that the running code has to relinquish control to the scheduler. Threads themselves are prescheduled at the OS layer but OS threads are much heavier and limited in how many can be running. A Java thread is 1024kb for example, compared to an Erlang process that's 0.5kb.

>My understanding is that those languages rely on cooperative scheduling within a thread

MPI doesn't require threads.

I think people here are confusing parallel programming with multithreaded programming. One is a subset of the other.

Re: What's all this fuss about Erlang? (2007)

#182

Post by esra »

jknoepfler wrote: post #158
tempz wrote: post #58

Earlier quoted context omitted.

Not really. Experience after designing and deploying systems that run 100,000 transactions/sec per box: don't bother with engineers that cannot achieve proficiency in Erlang. Elixir is a crutch, and not something you want to show up with in 400 meters hurdles race. You will look pathetic.

You literally just suggested that someone who writes semantically identical code in a more readable language will look pathetic to you. I think you're confusing nerd-cred with engineering ability. For the record, I will employ the person who prefers to write in Elixir but can work with legacy Erlang before I will employ someone who thinks there's special magic in an obtuse syntax...

I'd say it's extremely subjective which language is more readable, for some that might be Elixir and for others it's Erlang.

Re: What's all this fuss about Erlang? (2007)

#183

Post by zengid »

slashdotdash wrote: post #4

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists

It says Elixir uses the Actor model, but doesn't Erlang use Communicating Sequential Processes (CSP)?

Re: What's all this fuss about Erlang? (2007)

#184

Post by novembermike »

pjmlp wrote: post #157
novembermike wrote: post #76

Earlier quoted context omitted.

BEAM is slower than the JVM for sequential code but it doesn't have a block the world GC and it has preemptive multi processing. It'll have worse steady state performance but a lot of the worst cases that Java can have are heavily mitigated.

You are making the error of comparing BEAM with a specific JVM implementation. Not all available JVMs on the market have "a block the world GC" and the way multi-processing is done is implementation defined.

I could be wrong but I was under the impression that the four major JVM gc's all had a stop the world phase and while multi-processing is implementation specific I'm not aware of a robust pre-emptive multiprocessing model built for the JVM. If you have robust examples that are contrary to this I'd be interested in hearing about them.

Re: What's all this fuss about Erlang? (2007)

#185

Post by digitalzombie »

slrz wrote: post #150
digitalzombie wrote: post #139

Earlier quoted context omitted.

Elixir is prettier than Erlang but it really mess up on certain things. Erlang have pattern matching via function with same name and you can tell if it's a group of pattern matching with semicolon and period. But with Elixir you can't tell it's just def and end. Erlang's: -module(recursive). -export([fac/1]). fac(N) when N == 0 -> 1; fac(N) when N > 0 -> N * fac(N-1). You can tell fac(N) both are in a group of patter…

I think you make the Erlang definition look unnecessarily awful. fac(0) -> 1; fac(N) -> N * fac(N-1). Or is there a particular advantage to write it using guards?

It's an example from http://learnyousomeerlang.com

Re: What's all this fuss about Erlang? (2007)

#186

Post by digitalzombie »

ryeguy wrote: post #145
digitalzombie wrote: post #139

Earlier quoted context omitted.

Elixir is prettier than Erlang but it really mess up on certain things. Erlang have pattern matching via function with same name and you can tell if it's a group of pattern matching with semicolon and period. But with Elixir you can't tell it's just def and end. Erlang's: -module(recursive). -export([fac/1]). fac(N) when N == 0 -> 1; fac(N) when N > 0 -> N * fac(N-1). You can tell fac(N) both are in a group of patter…

How does that matter? Anyone who uses this defines them in groups one after another. You aren't looking at the punctuation at the end of the line, you're looking at the following line to see if it's the same function name.

It matter because you're assuming they will group it. IIRC Erlang forces you to group it.

Re: What's all this fuss about Erlang? (2007)

#187

Post by ryeguy »

digitalzombie wrote: post #186
ryeguy wrote: post #145

Earlier quoted context omitted.

How does that matter? Anyone who uses this defines them in groups one after another. You aren't looking at the punctuation at the end of the line, you're looking at the following line to see if it's the same function name.

It matter because you're assuming they will group it. IIRC Erlang forces you to group it.

It's an incredibly safe assumption to make, though. This isn't enough of a problem in practice to amount to a negative for elixir or a pro for erlang.

Re: What's all this fuss about Erlang? (2007)

#188

Post by pdpi »

novembermike wrote: post #184
pjmlp wrote: post #157

Earlier quoted context omitted.

You are making the error of comparing BEAM with a specific JVM implementation. Not all available JVMs on the market have "a block the world GC" and the way multi-processing is done is implementation defined.

I could be wrong but I was under the impression that the four major JVM gc's all had a stop the world phase and while multi-processing is implementation specific I'm not aware of a robust pre-emptive multiprocessing model built for the JVM. If you have robust examples that are contrary to this I'd be interested in hearing about them.

Azul doesn't. It's not a differnt GC for the hotspot VM, it's a separate VM altogether

Re: What's all this fuss about Erlang? (2007)

#189

Post by LukeShu »

LukeShu wrote: post #123
soyiuz wrote: post #119

How to make sure I don't read your post: > Our site has been optimized for use with newer browsers. We also require that your browser has JavaScript enabled. > It looks as if your browser has JavaScript disabled. > This site has information about enabling JavaScript, if that's something you want to do. Really? I am just trying read a few paragraphs of text on a fairly static-looking site.

It's even worse than that. It is static. It would work without javascript if they didn't put

As a slight followup: In the Advanced settings panel for NoScript, there's an option to disable redirects in blocks.

Re: What's all this fuss about Erlang? (2007)

#190

Post by omgwtfpmr »

XorNot wrote: post #72
lngnmn wrote: post #28

A practical language based on well-researched first principles. Details in the armstrong_thesis_2003.pdf * java is unsuitable * no pthreads, please (wrong concept) * immutable data (no locks - no problem) * isolated lightweight processes (share nothing) * communication by message-passing (grom Kay's OOP) * dynamic typing (good-enough, quick prototyping) * pattern matching (on receive) * supervision hierarchies (fault…

I've not found immutable data to be the big win people tout it as. In most of what I do acting on stale data is just as bad, which means I wind up needing a lock anyway. Doing a < b and taking an action based on that result is as harmful with stale data.

This is a fair point: immutable data is just part of the solution. To get the win, you need to toss out all references to the old data when you update it: then you ensure that you can't access "stale" data. This requires some discipline, either manual (e.g., reusing the same variable name for the old and new bindings to ensure the stale binding is shadowed) or automatic (e.g., linear types).
Post reply on HN