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

151–160 of 193 posts

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

#151

Post by BeetleB »

brightball wrote: post #128
BeetleB wrote: post #93

Earlier quoted context omitted.

>only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized. OK. Not an Erlang user,…

The prescheduler caps the execution window for anything that would block. 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.

>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 for MPI in C. Later I did some MPI in Python. True there as well. If you have MPI in any language, it is true for that language.

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

#153

Post by BeetleB »

m00x wrote: post #118
chrisseaton wrote: post #100

Earlier quoted context omitted.

I said it is trivial to parallelise a C program that implements an embarrassingly parallel algorithm. Embarrassingly parallel means no resources need to be shared, and there needs to be no communication, so no need for locks or messages, even in C. That's why I say it'd be trivial to parallelise it. Just add a pthread_start. Of course almost no applications are embarrassingly parallel.

And then you also need to implement mailboxes to receive new data, supervisors to watch the threads and revive them when they fail, initialization methods to get back to the original state, etc. You can trivialize any issue if you ignore all the facts, but it doesn't make your argument have any correctness.

I'm really surprised at the arguing in this thread.

Embarrassingly parallel algorithms are trivial in pretty much every language. That is why is embarrassing.

>And then you also need to implement mailboxes to receive new data

If you did, it is not embarrassingly parallel.

You know, a huge amount of parallel work is done in C/C++. It was the language used for multiple parallel algorithms courses in my university. Being able to do basic MPI type stuff in C does not make you a top programmer. And not being able to do an embarrassingly parallel algorithm in C would ring alarm bells.

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

#154

Post by toast0 »

hota_mazi wrote: post #54
gamache wrote: post #21

Earlier quoted context omitted.

Do you realize how silly this sounds? You are disregarding not only Erlang, but decades of research and development on concurrent programming best practices. Immutability has been promoted for parallel programming since the 1970s. For the past fifteen years, even languages like C++ have moved to promote this style of programming. (Also, Erlang has a compile-time static type checker, if type safety is something you're…

I'm well aware of the literature. The fact is that still today, we have millions and millions of lines of code that work in parallel and a crushing majority of it is operating in mutable languages (C++, Java, Javascript, C#, ...). Pushing immutable languages as the silver bullet to solve concurrency problems is trying to solve a problem that nobody has. We've moved on to higher abstraction grounds (fork join, work st…

I think immutability isn't really that important for concurrency in Erlang, since there's conceptually no shared state between Erlang processes -- if you use the mutable process dictionary, no other process could see it anyway[1]. In reality there is ets which is mutable with locks, and refcounted binaries which become immutable once there's more than one reference.

That Erlang forces you to build a shared nothing system is the real win for concurrency. Of course, you can do that with other languages too.

> We've moved on to higher abstraction grounds (fork join, work stealing, coroutines, etc...), Erlang is still stuck in the past.

Erlang can do fork/join, the schedulers can work steal, and erlang processes are approximately equal to coroutines -- I don't understand what you think is stuck in the past (other than the Prolog like syntax, but you get used to that).

Immutability is a big win for garbage collection and memory allocation however, since there are no circular references, mark and sweep isn't required and a simple (generational) copying collector can be used instead.

[1] actually you can look at other processes' dictionaries if you want, but that requires a lock on the destination process.

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

#155

Post by jknoepfler »

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?

having a semantically significant distinction between ; and . is unnecessarily awful. That kind of crap is one of the reasons Elixir has so much support.

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

#156

Post by jknoepfler »

digitalzombie wrote: post #139
mnd wrote: post #44

Earlier quoted context omitted.

Erlang is a great programming language after one takes the time to understand the principles underlying it and its design. Everything fits very nicely into place. There are definitely things that could be done better, but then that’s the case with most programming languages and technologies after they have accumulated some dust. Elixir on the other hand, in my personal opinion, is a false prophet simply because it lo…

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 honestly don't understand how this messes anything up... the elixir syntax produces something semantically equivalent with a lot less garbage. Opinions may differ I guess, but I find your Elixir example much easier to read than your Erlang example (I program in Elixir, so that's not much of a datapoint).

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

#157

Post by pjmlp »

novembermike wrote: post #76
geodel wrote: post #27

Earlier quoted context omitted.

I searched many times the comparison of Erlang BEAM and JVM regarding performance but couldn't find much. May be it is not done, or maybe it is not publicly available. At my work some folks keep pushing RabbitMQ over ActiveMQ for no other good reason than it is in Erlang so we will get much better performance. I know it is not true but could not find web links to support that.

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.

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

#158

Post by jknoepfler »

tempz wrote: post #58
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

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

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

#159

Post by dxhdr »

dozzie wrote: post #80
davidw wrote: post #3

This was back in a brief period when Erlang was being hyped by people as a potential Next Big Thing. Unfortunately it never really got that much momentum though, until Elixir and Phoenix came along.

Similar thing for Ruby: it wasn't popular until Ruby on Rails. It may be just that most programmers need to write dynamic websites, as opposed to network services (most likely with custom protocols).

Here's my Stack Overflow theory:

Programmers writing dynamic websites are likely to post questions on Stack Overflow. Questions on Stack Overflow create mindshare, mindshare attracts more serious programmers who can improve the ecosystem by writing generic network services. Language prospers, cycle repeats.

JavaScript is the most popular language on Stack Overflow and React is the fastest growing technology.

Without the dynamic website programmers the cycle short circuits and you end up with a terrible "new user experience" from lack of answered beginner questions and lack of interest building on the non-existent ecosystem.

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

#160

Post by IanCal »

djKianoosh wrote: post #25
derefr wrote: post #12

Earlier quoted context omitted.

I've always thought that Erlang would be more successful if it had a better deployment story, along the lines of Go or Rust: e.g. if you had the option of baking an Erlang runtime into a static binary. As it stands, software like ejabberd and rabbitmq are pretty ugly in OS package form (because distro maintainers think such packages need to rely on a common, usually very old, Erlang runtime, instead of allowing them…

please, more sources and links? i would love to package up an entire elixir app as an rpm to a rhel7 target that has no internet connection. so the package/binary needs to have everything including erlang. i am not afraid of compiling from source. is the answer distillery or something else entirely?

Does it need to be an RPM or just something easy to install office?

The release process I've used for Erlang before packaged things up into a folder with everything you needed to run.

Post reply on HN