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

81–90 of 193 posts

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

#81

Post by chrisseaton »

mnd wrote: post #79
chrisseaton wrote: post #75

Earlier quoted context omitted.

I acknowledged the areas where Erlang did bring advancements such as fault tolerance. I read that paper, more than once, and his thesis, when I was doing my own PhD on parallelism, so I know the area and related work fairly well. I don't think I'm embarrassing myself when I say that it's silly to claim that an arbitrary Erlang program should achieve linear scalability. But we don't need to debate with vague claims to…

Concurrency is not parallelism. You conflate parallelism with concurrency in your comments both here and above. I should also mention that for a big part of its life the Erlang virtual machine has had no support for parallelism. Erlang was not invented to solve parallelism so your hypothesis is downright wrong. Parallelism was just a consequence of the concurrency which was not exploited by the Erlang virtual machine…

I don't know what to say apart from that I disagree with how your describing my argument back to me.

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

#82

Post by mnd »

kevinjcliao wrote: post #78
mnd wrote: post #74

Earlier quoted context omitted.

Unrelated to your discussion with the parent, but I just wanted to point out that the fact that a system which was implemented in Elixir and runs on the Erlang virtual machine is able to sustain that traffic (and here I am referring to the link you posted) is and should be regarded as, largely, a quality of the Erlang virtual machine, and only to a very small extent to the programming language that it has been implem…

Thanks for your clarification. I think 'just syntax' is a bit dismissive of the importance that well-designed syntax has on being able to reason clearly in a certain way. Elixir's "just syntax" has made it so easy for me to understand FP concepts like pattern matching and higher order functions. I've struggled with these concepts before while trying to learn Haskell, Erlang and many other FP languages. Does that make…

My point was not that everything which is written in Elixir can be written in Erlang but mostly that using a reference to a system that sustains a large amount of traffic which is implemented in Elixir and runs on top of the Erlang virtual machine as an argument for how incredible Elixir is, is naive at best, as Elixir is just a layer on top of many Erlang libraries and also the Erlang virtual machine. Yes, syntax can matter, but you can discuss that later when you discuss maintainability and other software design and maintenance issues. You cannot discuss syntax and then argue that your program sustains large amounts of traffic; you can, but it’s pointless.

And to answer your first question, although I thought I was very clear that I do not want to take part in your discussion with the parent: no, I do not think that you are a bad programmer for learning Elixir, I think if you were to only learn Elixir, call it a day, and then spread the word of how incredible Elixir is, you would be, however. Programming languages are just that, programming languages. The more you know the better and there is no silver bullet. As you will get back to Haskell you will probably come to appreciate its powers. Also, the fact that you have not grasped Haskell’s syntax when you have first tried does not make it a poor functional programming language and it certainly does not make Elixir a better designed functional programming language. That’s just your perception because Elixir was, for you, easier to learn. The fact that I cannot comprehend particle physics does not necessarily make particle physics a badly designed model.

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

#83

Post by ww520 »

mnd wrote: post #79
chrisseaton wrote: post #75

Earlier quoted context omitted.

I acknowledged the areas where Erlang did bring advancements such as fault tolerance. I read that paper, more than once, and his thesis, when I was doing my own PhD on parallelism, so I know the area and related work fairly well. I don't think I'm embarrassing myself when I say that it's silly to claim that an arbitrary Erlang program should achieve linear scalability. But we don't need to debate with vague claims to…

Concurrency is not parallelism. You conflate parallelism with concurrency in your comments both here and above. I should also mention that for a big part of its life the Erlang virtual machine has had no support for parallelism. Erlang was not invented to solve parallelism so your hypothesis is downright wrong. Parallelism was just a consequence of the concurrency which was not exploited by the Erlang virtual machine…

I think OP specifically talked about this assertion, "Your Erlang program should just run N times faster on an N core processor." This assertion is about parallelism, not concurrency.

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

#84

Post by di4na »

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…

It does that. This is an erlang release, and that is something that erlang does really well. The problem lie more on the tooling that made it harder than it should have been. This is what Elixir bring to the table.

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

#85

Post by boardwaalk »

yellowapple wrote: post #67
gamache wrote: post #47

Earlier quoted context omitted.

Yup, Dialyzer. Works with Elixir too (there's even a Dialyxir mix task) and gives me all the type checking I want -- which admittedly isn't much.

Personally, even when I do want something resembling type checking, I've found pattern matching / destructuring to be more than sufficient. With Elixir's structs, this is trivial: def some_function(SomeStruct{} = some_struct) do some_struct.foo + some_struct.bar end Or better yet, if I only want certain fields: def some_function(SomeStruct{foo: foo, bar: bar}) do foo + bar end This way, if the "type check" fails (tha…

Pattern matching is fantastic. Also, there are guards:

  def handle_info(msg, state) when is_tuple(msg) do
    # ...
  end
I haven't written anything big with Elixir/Erlang yet, but I definitely feel more confident my Elixir code will work than Python, say. Not as much as Go, though.

As an aside, comparing:

  {:ok, port} = Port.open(...)
to something similar in Go:

  port, err := port.open(...)
  if err != nil {
    panic(err)
  }
That's very convenient. Also, you can bind multiple times to a single argument (sort of like what you showed):

  def handle_info([], state = {ppid, _port}) do
    Supervisor.stop(ppid)
    {:noreply, state}
  end
That's not a default argument, that's binding the second argument to state and the pid inside the state tuple.

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

#86

Post by devishard »

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…

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

You've made two claims, one irrelevant and one false:

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

2. it's trivial to write a program that's faster in X language I'm not sure how toot define trivial, but I've yet to find a language that can communicate between threads as performant-ly. Even languages like Clojure which use similar thread semantics can't do what Erlang can because the underlying threads aren't as lightweight. Spinning up a million threads in Erlang isn't even unusual, whereas in any of the languages you mention it's either crippling-ly slow (Python or Java) or very difficult to synchronize (C most, but Python and Java aren't easy).

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

#87

Post by Vaelatern »

stcredzero wrote: post #71
Vaelatern wrote: post #50

Earlier quoted context omitted.

Why did you leave Clojure?

Clojure weenies on IRC. To be fair, the Go weenies aren't much better. If you like hanging out on IRC so that you can emotionally abuse newbies, ask yourself what you're doing with your life.

Fascinating, so it was purely a communal decision.

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

#88

Post by di4na »

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…

That still does not works. I have to maintain that code everyday. It does not work.

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

#89

Post by ww520 »

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…

In the case of Erlang, how would immutable data help? The code all run in single thread execution path in each process; there's no need for lock anyway. Each process can't access data of another process.

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

#90

Post by di4na »

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…

You mistake concurrency with parallelism. If each of your "synchronous" call to a method is an asynchronous message, suddenly, all your program is embarasingly concurrent. Wait... was that what Alan Kay was saying with SmallTalk ? Would we have all lost our mind on RPC and synchronous calls for so long?

Yes. Yes we did.

Post reply on HN