11–20 of 244 posts
Since you asked: I have never tried Erlang because I've heard it's like Haskell but harder to learn, and Haskell already breaks my feeble mind, so I have steered clear. This may or may not be an accurate picture, but it was my decision-making process. I have no programming problems that make me think learning a whole new language would be worth it (on top of my existng stack of 10 or so).
Since you asked: I have never tried Erlang because I've heard it's like Haskell but harder to learn, and Haskell already breaks my feeble mind, so I have steered clear. This may or may not be an accurate picture, but it was my decision-making process. I have no programming problems that make me think learning a whole new language would be worth it (on top of my existng stack of 10 or so).
Ask the simple question of how do you write the equivalent of
int main(....) { ... } and well... there isn't one!
You are almost forced, from the start, to learn about releases and a ton of other really complicated stuff just to write a program you can share. Its sort of being fixed with relx.
Secondly no one seems to understand pattern matching at first. Its just such an alien concept when you look at it compared to all the other mainstream procedural/oo languages people usually already know. Again a huge cliff to climb to really grasp the possibilities and usage.
It really is quite a great language, and an even better runtime. The learning curve to making great things with it is just quite high in my opinion. I've done two major projects with it, one shipped as an embedded web app in some lab equipment out there. I think it was a good choice!
If it had an Algol syntax, and performed the SSA transform behind the scene, it would probably be very, very big now.
Bear in mind as I say this that I'm not necessarily advocating for those changes. For instance, this would require some tweaks to the semantics of pattern matching, too, which aren't necessarily for the better... in the abstract. However, they probably would be for the better in terms of usage.
I'm pretty sure Go is going to eat Erlang. Erlang programmers will 100% absolutely correctly complain that OTP can't be translated without loss into Go, and almost nobody will care. Again, I'm not necessarily advocating for this, because the Erlang advocates will be right, you just can't quite get it fully expressed in Go and that saddens me, it's just what's going to happen, I think.
In fact I'm doing it myself; the Erlang core of my system is getting pulled out and replaced by Go for a variety of reasons, and one is despite the fact my team is fairly adventurous over all, we're still better off finding people to work on Go than Erlang. (In the next couple of months I hope to release my first release of "reign", "Rewrite Erlang In Go Nicely", which brings some of the Erlang stuff into Go for the purpose of porting existing programs. I've been pulled into other fire fighting so I'm not on it this second, but I'll be getting back to it soon. That implements Erlang-like mailboxes and network clustering, and I've got a supervisor tree implementation on deck for Github too. Subscribe to https://github.com/thejerf to see when those come out in the next couple of months.)
By the way, Erlang advocates, bear in mind that trying to argue me out of this position is a waste of time. I've been programming in Erlang for 7 years now. I get the syntax just fine, even if I still don't like it. The problem is that you have to argue the greater programming community out of this position, and I don't think you have, and I really doubt you can. For better or worse, being non-Algol seems to put a hard limit on your general-purpose programming acceptance. (In my opinion, that is for the worse, but here we are. Again, please don't mistake this opinion as celebration of any of these facts. My opinion is that Erlang deserves better. My belief is that it won't get it.)
[1]: That's pretty much every modern mainstream language today: C(/++/#), Java, Python, Javascript, etc. Not all those languages come from the same semantic heritage (scripting vs. conventional OO manifest types being one big example), but they come from the same syntactic heritage. Contrast with the ML family, the Lisp family, the Prolog family (which is pretty much just Erlang now), and the Forth family for different syntactic heritages.
[2]: http://evincarofautumn.blogspot.com.es/2012/02/why-concatena...
It lacks a good way to do abstract data types (records don't count).
The compiler's ability to optimize is limited by the lack of purely functional guarantees and the metaprogramming facilities (parse transforms) aren't easy to use to work around that.
There's no facility like Haskell's ST or clojure transients to encapsulate mutable stuff, just a hole to write code in C and who really wants to do that? Yes, I know about the process dictionary and ets but those aren't appropriate for most algorithms I've wanted mutability for.
That said, I still use Erlang, but only in the domains where it really shines.
This comes from reading rabbitmq and riak-core sources.
Since you asked: I have never tried Erlang because I've heard it's like Haskell but harder to learn, and Haskell already breaks my feeble mind, so I have steered clear. This may or may not be an accurate picture, but it was my decision-making process. I have no programming problems that make me think learning a whole new language would be worth it (on top of my existng stack of 10 or so).
However, too many examples show trivial things like mapping over a list or calculating something recursively. As a professional programmer, I get how those things wrok. What sets these languages apart from Javas of the world is how state is handled. It isn't easy to dig through tutorials and docs to find the best way of keeping state, updating it, referencing it, etc.
I once attempted to implement a small order matcher (from the stock trading world) in Erlang. I know how to do it in imperative languages, but it was pretty painful to do so in Erlang. It was getting very verbose, I wasn't sure how to create a priority queue, how to modify elements in a data structure, etc. Since this wasn't a simple transformation of data, I had a hard time finding references in documentation spread across the web.
I realize that if I was committed to learning Erlang, I would work through a book or two. Perhaps find a small open source project and work through the implementation. However, I, like so many others, wasn't committed. I was merely trying it out and when I couldn't make progress, I decided to use my precious free time on something else.