Erlang is like Ruby in ‘02?

There are two upcoming Erlang books :
1.Title: Concurrent Programming with Erlang/OTP
Publisher: Manning
Link: http://manning.com/logan/
Availability: 2 Chapter MEAP PDF
Release : Feb 2009 (est.)
2.Title: Erlang Programming
Publisher: O'Reilly
Link: http://www.amazon.com/Erlang-Programming-France...
Availability: Not yet
Release: Dec 2008 (est.)

the syntax could definitely be improved on. look at Lua for examples of syntax that isn't ugly

Like Alain, I think that the main issue is really functional programming itself.


I've only just started getting into Erlang, and had a sudden appreciation of the first-year programming I did over a decade ago. We were taught a functional language first even though I have never actually used one in my professional software career (Java, PHP, VB, Ruby, Python etc).

And it's all still in my head.
But there are many many people who have never even seen a functional language, let alone used one.

One thing I find a bit hard is the syntax itself. I would love a syntax that was a bit more Ruby like (even toying with the idea of a ANTLR based translator).

IMHO, the barrier of entry to Erlang has more to do with functional programming not being taught to the average developer than any inherent difference in complexity.

Most of my experience is with Java. Having learned Erlang I can say with confidence that it is substantially less complicated than Java. I would argue that it is less complicated than Ruby or Python as well. The syntax for Erlang is different from, but substantially less complex (in terms of the variety of syntactical constructs you need to understand to read other people's code) than Java, Ruby, or Python.

Expressiveness is a double-edged sword. I have used Ruby and Groovy and both are very expressive, but lend to a tendency to writing Domain Specific Languages. That encourages people to have inconsistent coding styles down to the syntax (a major problem I had with Rails). The constraints and simplicity of Erlang make it more likely for a team of developers to code consistently.

Even for sequential programming I find Erlang faster to develop and easier to evolve than any other language I have used.

Ruby and Python have a ridculously easy way to bind to C libraries or build their own. Besides, Ruby has gem (Erlware is going in that direction, but it hasnt become a de facto standard)

Erlang, on the other hand, has a much higher entry level

IMHO, of course

I'd rather see possibilities of Erlang on infrastructure servers other than HTTP (I know Erlang works very well on HTTP as yaws has proven); the concurrent programming style is totally different from other languages allowing mutable variables and shared memory.

I think http://erlyweb.org/ could be a good starting point for people most familiar with Rails.

I don't see CouchDB as a candidate for being Erlang's Rails, getting lots of programmers to start learning Erlang. Rails is a framework; to use it to build your application, you have to learn Ruby. CouchDB is an application with a REST + Javascript interface. You don't need to know Erlang to use it.

“Erlang reminds me of Ruby during its early days”
You mean when Ruby was lean and mean? (I'm kidding).

Ruby gets you where you want, but it's compiler(s) seem to be based on a huge and messy codebase to reach the kind of ...syntax... that ruby have.

Erlang is for stable and concurrent systems. Which would you rather code in? Ruby. Which would you rather that your day to day software was coded in? Erlang.

Erlang has potential to grow. Ruby on the other hand, can become faster, but are there really any features that needs to be added that wouldn't require massive changes?

The larger market is almost entirely driven by utility for web applications. Erlang is in many ways more mature than Ruby, but has had a different focus. Commercially, Erlang has mainly been used in telecoms systems, and many of the qualities that make it highly suitable for telco systems would also be great for building scalable mission-critical web apps.

Compared to Ruby, Erlang lacks the low-threshold entry point a la RoR. No hosting companies that I know of offer Erlang as an alternative web app creation environment. So if you want to build an Erlang-based web service, you have to host it yourself, or set up virtual servers and build more or less from scratch. That's fine, if you know that you'll have to do it anyway. Then you can fairly easily build a non-stop, low-latency web service using Erlang, but it's quite a plunge if all you want to do is play around some first.

I'd agree with that. I found ruby in 2000 or so, looking for an alternative to learning perl for some simple scripting tasks.

There's a lot erlang could learn from ruby in those days... from my point of view two things were really key to ruby gaining traction: Why's blog and ruby gems. Why's blog was a good hook that started to build a community. The wackiness made ruby remarkable. Gems greatly simplified using other people's code. I'm convinced that without these two things DHH would not have found ruby when he was looking to write rails (I assume everyone is familiar with rails, how it was marketed and how it broke ruby into industry).

It definitely seems like the same things are happening with erlang, both with blogs like this and the efforts for simpler packaging and distribution of erlang applications. Erlang hasn't found it's rails yet, though couchdb is looking to be a good candidate.

I think there are some clear differences between ruby and erlang however. Ruby is a sort of wolf in sheep's clothing: it's looks warm and inviting to people familiar with other OO languages, but keeps some of the expressive power of functional languages. This made it an easy proposition for most adopters: with very little investment they could be productive with ruby in a very short time. Writing ruby is easy and fun.

Erlang unfortunately is a more complicated language, built around concepts more foreign to most developers. I don't think there are any easy answers here, but I suspect that erlang will need to focus on it's power as a carrot to get developers to put in the initial effort to learn. But I also think it might be worthwhile to look additions or changes to the standard library to make those first days a bit more smooth.

I think erlang's biggest challenge will be finding how to make itself easy and fun for novice developers without sacrificing it's power.

I love Erlang but I don't really expect it to reach the same level of interest as Ruby.

Through Rails, Ruby got attention as a better alternative to Java, PHP, and Perl for rapid development of web applications. Faster to get a working site up than coding in Java and cleaner and easier to maintain than a PHP or Perl spaghetti code mess (though Perl isn't really that far behind Ruby). Erlang arguably has some of the same advantages over Java or PHP but not so much over the Rails/Django/Catalyst type frameworks and then has the added disadvantage of having a much smaller community of developers.

What interests people about Erlang is its potential for making bulletproof, high concurrency, and/or distributed applications. While that's a growing market, it's still nowhere near the size of the "I need a quick database backed site to implement my startup's business plan and we can worry about scaling and reliability once we actually have clients" market where Ruby has gained so much ground. Some of the successful ones of those will start to hit their scaling and availability limits and look at switching some of their infrastructure to Erlang but most just never even make it that far and move on to the next attempt.

I guess there's potential for Erlang to eat into the "Enterprise" market since they do care about availability and concurrency but they're also very conservative. No one's about to dump their gigantic J2EE stack and replace it with Erlang anytime soon. That stuff will be around longer than Cobol.

I just wrote about this on erlanginside...