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

51–60 of 193 posts

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

#51

Post by davidw »

djKianoosh wrote: post #10
davidw wrote: post #6

Earlier quoted context omitted.

> fold the good parts of Erlang/BEAM into them A lot easier said than done, because there are a lot of really fundamental decisions about Erlang that make it what it is. You can't just slap on a scheduler for instance, or Erlang style processes. Go is probably the closest thing, and it's still lacking some things like the supervision tree. Erlang is certainly not 'the answer' in terms of computationally intensive any…

so many people (including me from time to time) misunderstand "computaionally expensive" that I think Elixir/erlang/beam will serve a lot of systems/apps well for a long time until they really see a need for "intense" computation

Oh, absolutely - you can do tons of things with Erlang, just as people do with Ruby, Python, PHP, Tcl, etc...

But that article is a bit hype-y.

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

#52

Post by Const-me »

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…

Immutability is not a silver bullet.

One reason is RAM consumption: while Facebook has bought tremendous amount or RAM for caching content so those extra copies of objects don’t hurt, desktop or embedded apps have different resource constraints.

Another reason is performance. Memory allocation/deallocation is not free. RAM bandwidth for copying those objects isn’t free. Also mutable objects generally more cache-friendly, a modified object stays in the same RAM address i.e. stays cached.

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

#53

Post by derefr »

lobster_johnson wrote: post #41
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…

I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs. I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim w…

Oh, sure, there are plenty of things getting in the way of developers being excited about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang.

But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterprise-y bloatware-apps and business-process servers that make Java's market-share so large.

Because Enterprise software gets designed top-down, how excited developers are to be using the (dictated) language aren't very relevant. How easy the language is to learn is relevant; how many engineers you can either hire or train to code in the language is relevant. But whether they enjoy their day-to-day lives writing in the language isn't, really.

Thus, I think, why things like deployability are more important to Erlang: for the type of software projects Erlang would be good for, considerations like deployability (and maintainability, remote debugging, easy hot-patching, etc.) are what guide language choice. Erlang wins on most of those fronts (as it should: its OTP framework is effectively "30 years of ops best-practices constraining development"), but for various reasons, [non-embedded] deployment has always been a pain-point.

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

#54

Post by hota_mazi »

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…

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 stealing, coroutines, etc...), Erlang is still stuck in the past.

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

#55

Post by yellowapple »

mnd wrote: post #44
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

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…

This is a big part of the reason why I appreciate having learned at least the basics of Erlang before moving on to Elixir, having come from Ruby. It helped establish an appreciation in my brain for declarative programming - something which is possible to do in Ruby, but nowhere close to the extent possible in Erlang or Elixir (or any other language with a similar approach to "pattern matching" as a first-class programming paradigm).

Of course, I tend to feel much more productive in Elixir than Erlang, and thus use Elixir way more often than Erlang directly, but I'm able to come at Elixir with a more Erlangy perspective and approach.

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

#56

Post by zazibar »

stcredzero wrote: post #46
zazibar wrote: post #18

Earlier quoted context omitted.

Can you elaborate on how you implemented those servers? Would you still use Clojure or Go for them now? If not, what alternative do you suggest?

My first attempt was a server for a dungeon crawler that superficially looked like a rogue-like, but was actually 12 frames/sec realtime instead of turn based. It started out on Clojure, but I afterwards ported it to Go. In this server, the world was divided into 80x24 subgrids that did most of their processing in parallel. Processing would happen in two stages: 1) local data processing, where each entity got updated…

Interesting. Thanks for the detailed response!

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

#57

Post by lliamander »

daddykotex wrote: post #37
lliamander wrote: post #26

Earlier quoted context omitted.

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

I think that's where Scala shines. I don't know if you have tried it, but it solves a bunch of the problem you enumerate with Java & C. Sure, it can be hard to read because you can write the same thing in tens of different ways and some people abuse it, but if you don't and your team does not, you end up with a beautiful code base.

I believe it does. The only issue I take is that I believe null objects are still possible. Kotlin and Ceylon both correctly addressed this (but lack some of the sophisticated type features found in Scala).

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

#58

Post by tempz »

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.

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

#59

Post by lobster_johnson »

davidw wrote: post #49
lobster_johnson wrote: post #41

Earlier quoted context omitted.

I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs. I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim w…

As a long-time Erlang user, I think the above is a lot closer to why people always seemed to have some trouble with it. Lots of little weird things. Part of this is that Erlang kind of wants to be its own little world - something that it shares to some degree with Lisp and Smalltalk (images!).

That's a great point — there's an impedance mismatch between Erlang and the rest of the world.

It doesn't just have its own syntax, it has its own idiosynchratic, somewhat alien way of doing almost everything that is already established on Unix. The difference feels almost as stark as Linux vs. Windows.

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

#60

Post by yellowapple »

rvirding wrote: post #36
jbernardo95 wrote: post #35

Earlier quoted context omitted.

In other words, Elixir is the rocket that will make Erlang go big.

Well, it's a skin on the rocket that will make it big. While they generally say that Elixir runs on top of the Erlang VM there happens to be a big fat Erlang/OTP layer in-between which Elixir and its libraries make full use of. This is just smart of course but not mentioning doesn't paint the whole picture.

I'd say Elixir is the skin, like you say: without it, all your rocket pieces are out in the open and not particularly aerodynamic, and they'll start breaking off and you won't be going to space today. There are other skins, though, like LFE and Erlang itself.

The Erlang VM is the engine. You can make a beautiful, sleek, aerodynamic rocket, but it ain't going anywhere unless you literally light a fire under its butt. It helps that BEAM helps the rocket go fast :)

Of course, you need some sort of structural piece to hold your engine and your aerodynamic skin in place, lest your rocket crumples itself up into a ball at launch. That's where OTP comes in: providing a robust structure for your rocket.

Last but not least, you need to launch it. Rebar and Mix work reasonably well as launch clamps in this really contrived metaphor. You also have exrm (or Distillery nowadays, I guess) that works as the VAB, in which your rocket is put together so it can be launched.

Post reply on HN