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

21–30 of 193 posts

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

#21

Post by gamache »

hota_mazi wrote: post #13

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. And yes, that…

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

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

#23

Post by NotThe1Pct »

I looked at Erlang some time ago with a consultant, who was trying to get something Erlang going in our firm, and we compared a simple queue with boost, which is not really optimized for speed. I think the C++ version was sort of 20x faster.

I assume the dude was not that unskilled since he was selling his Erlang solutions for many years but it was bad enough that it left no room for a second meeting.

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

#24

Post by patates »

zaphar wrote: post #19
hota_mazi wrote: post #13

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. And yes, that…

If I am totally honest. Most of the code where I was pretty sure I had figured out the whole mutable states and locks thing has another developer looking at it right now and cursing me under his breath.

I'm investigating an issue with a deployment where a process keeps crashing with the log.fatal("not reachable"). I already fixed 3 potential race conditions and still not sure if and when I'll get my next email basically telling me "haha it's still reachable". Yesterday my neighbor came to my door to ask if everything is okay because I cried "aber warum?" (but why?) out loud.

tl;dr: Don't be that programmer :)

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

#25

Post by djKianoosh »

derefr wrote: post #12
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.

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?

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

#26

Post by lliamander »

hota_mazi wrote: post #13

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. And yes, that…

>> How do programmers fix these problems? They don’t. They pray.

>Ah! No, Joe, that's what you do.

I don't know if Joe is a religious man, but I don't believe beseeching the Almighty was one of the reasons listed for why an Ericsson switch was able to achieve nine 9's of availability.

> Most of developers have figured out how to do concurrency and parallelism with mutable state and locks.

It appears to me that the industry has moved to a combination of promises, message passing, thread-safe data structures, transactions, etc., instead of code that directly manipulates locks.

>...as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe.

Depends on what you mean for scale. If you mean "suitable for gargantuan code bases and development teams" then it might not be the best. If you mean "suitable for processing large volumes of requests/events with low latency" then Erlang should be fine.

Types are nice, and I try to heavily leverage the type analysis tools that are available for Erlang (e.g. dialyzer). Java & C# (the two main static languages) are OK, but presence of null pointer exceptions and absence of sum types, intersection types, tuples, etc. really makes righting terse, type-safe code a chore.

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

#27

Post by geodel »

chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

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.

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

#28

Post by lngnmn »

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 tolerance)
   * reusable components for server development
I probably forgot something

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

#29

Post by boardwaalk »

derefr wrote: post #12
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.

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…

I've been thinking about this deployment thing because I'm experimenting with writing an "end user" application in Elixir + C port drivers. I don't see a particular reason one couldn't do something similar to "py2exe" and bundle everything into a single executable, with a custom loader to load modules from embedded resources. It sounds like a fun project, and one I might try out...

edit: There's this (abandoned, for reference): http://www.oocities.org/erlang_journal/sae.html

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

#30

Post by nilved »

gamache wrote: post #21
hota_mazi wrote: post #13

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. And yes, that…

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…

Are you referring to Dialyzer? I've always wanted to learn Erlang but can't give up on types.
Post reply on HN