Hacker News Reader

Comment by jhancock | Hacker News Reader

That's a good question. I've been using merb lately. I started with rails and didn't like it but thought ruby was ok. The main reason for going with ruby was to be able to hire other programmers and get out of the way of coding everything myself. I assumed 3 years ago when I made the decision that I would eventually be able to hire others. This has not worked out as planned. I am still coding everything. It turns out erlang has taken off enough that it may be reasonable to do a new project in erlang. I'm still not a fan of using erlang for writing view templates, but choices for this have improved greatly as well. When viewing the erlang vs. ruby programmer talent pool, there is a gut feel that the erlang pool may have a higher quality ratio although its a much smaller pool.

I can tell you that although merb is a nice framework, I still end up digging through code at times to find bugs that would be much easier to spot if it were in erlang.

View on HN

When you say that hiring others hasn't worked out as planned, have you had a hard time finding talent or you just haven't been in a place that hiring outside help was a viable option?

Sorry for all the questions, I just think it's an interesting insight to what happens if you pick a language / framework that isn't terribly mainstream.

Rails is pretty mainstream now, though, isn't it?

I think it's tough hiring good Ruby/Rails people because they're all busy. And those that aren't, are probably not good to begin with...

(I think the OP mentioned "hasn't worked out as planned" with regards to hiring Rails talent, not erlang)

Sorry, it was 2 thoughts conveyed poorly. Question 1 was whether he was having a hard time finding rails people or just that he didn't need more people.

Then my statement was more directly referring to the Erlang piece of it.

One of the things that crosses my mind every time I start leaning towards one of the more exotic languages is whether or not I'll ever be able to find someone to maintain the software later.

FWIW, I've read several accounts of companies switching from Rails to PHP because they couldn't find enough developers (or didn't like negotiating with the few available ones).

Of course good PHPers are probably busy too.

Why would there be something generalizable about rails programmers, or any language for that matter. Honestly, this whole notion always seems so out there.

Culture. Obviously the generalization will be lossy - not all Ruby devs are the stereotypical super-ninja-rockstars, nor are all Java devs preoccupied with building the Leaning Tower of Layered Abstractions, but still. Culture matters.

didn't like negotiating

I have never heard of a company scrapping a business deal because the world ran out of lawyers or accountants. The problem isn't a lack of developers, the problem is a lack of developers at the price the company is willing to pay.

I was speaking about long term funding for my projects. I ended up with funding in spurts which made it hard to keep any programmer on long term. So I ended up doing most of it myself. Given this hindsight, this means I could chose language and framework for their tech merits only and not worry about placing bets on programmer community growth and costs.

I started a new webapp two months ago. I ended up using merb again because I already have a merb app in production and could leverage my investment. Merb is obviously not mainstream and even less so now that the project is mostly discontinued in lieu of rails 3.

If I knew now about the length of these projects and my limited funding, I may have stayed with erlang. It was a tough call to let go of it and go with ruby/rails and then have to go to merb due to rails not satisfying my needs to ensure the app only did the things I expected it to do. This is a key issue with rails. Its too complex for some needs. Some apps have a need for simpler frameworks due to security concerns, which was big in my case.

Erlang is, IMO, a less well-rounded tool than Ruby in some ways. It does some things really well, but other things not well at all. If you take something like Java or Python, you're likely to be able to do anything with it, even if it's not really the best fit. With Erlang, you'll be the best at some things, and not good at all for others.

Also, Ruby is way less verbose than Erlang. A lot of pattern matching code seems to fail the "don't repeat yourself" in some ways - you write a lot of the same things, and just one changes.

Having used Erlang, Ruby, and Java in production, I can say all these langs offer the ability to do just about anything. Its a matter of style with each lang having strengths and weaknesses. Also a matter of library choice so you don't have to roll your own for everything. Erlang a few years ago had many libraries missing for mainstream web app needs. Although Java and ruby have multiple options in almost every category, erlang seems to have "enough" options these days.

I don't agree that erlang fails the "don't repeat yourself" test. In fact, I think ruby fails this test miserably in that you have to write so much test coverage. Although Ericsson devs wouldn't agree with this, I found that my code was my tests. I think the difference of opinion has to do with how the apps are used. My apps were end user web apps and my code was solid enough to be its own tests. Ericsson's code is enterprise grade telecom switches and their business model demands test coverage far beyond what most web apps demand. If you tried to write telecom switching code in ruby, your tests line count would be multiples, perhaps an order or magnitude, greater than the line count of the Ericsson erlang tests.

Ruby is class based OO programming, erlang is functional oriented. My erlang webapp line count was very reasonable. I'm not sure I would have fewer lines of ruby for the same app. The syntax sugar that makes ruby so appealing is a drawback as well at times: the code can be ambiguous with the only way to be certain of what it does being to write tests. Erlang syntax takes getting used to, it certainly doesn't have the immediate appeal as ruby. But it makes up for this in that once you are comfortable reading erlang, you can simply read the code and be certain of what it does and that it does it correctly.

What I mean by repeating yourself is code like this:

    skip_past_separator([]) ->    
	[];
    skip_past_separator([$; | Rest]) ->
	Rest;
    skip_past_separator([$, | Rest]) ->
	Rest;
    skip_past_separator([_ | Rest]) ->
	skip_past_separator(Rest).

(From mochiweb). That sort of thing appears to pop up with some frequency in Erlang code, and it seems wasteful.

If you're not matching on variable numbers of arguments, you can just have 1 function sig and a case statement.

The thing I dislike most about erlang, besides the lack of a good macro system, is that the repl is full of annoying special cases, so you have to actually stick your code in a file with a proper module name and compile it in order to test stuff :(

Pattern matching with functions is more 'idiomatic' Erlang, though, than case statements. At least that's what I've seen.

It's not wasteful, it is just putting the "logic" into the pattern matching at the function selection level. In Erlang you can usually take the first level of case/if statements or arg parsing and put them into the function definition. You do end up repeating certain patterns when defining the function head, but it lets you get away with a lot less repetition in the body of the function.

Different strokes I guess, but in my experience I found myself repeating code a lot less in Erlang due to the functional nature of the language and because it made certain bits of repetition in the code more obvious due to the "shape" of code in my editor.

I'm guessing your example is a matter of factoring and how/if the frameworks/libs suite your needs. Rails provides DLSs which have just the right interface to allow you to not repeat yourself in many use cases. If your erlang libraries do not, thats a function of the lib/frameworks, not the language.

In terms of "suiting my needs", that's an example from mochiweb itself, so my needs have nothing to do with it.

In terms of refactoring... I've seen code like that scattered through Erlang often enough to have a slight dislike for it (it is not a Major Problem with the language, and pattern matching is elegant).

And to some degree - it is a function of the language:

     foobar(a, b, c=1) ...

is a lot less code than

     foobar(A, B) -> ...;
     foobar(A, B, C) -> ....

So I will stand by my statement that Ruby is generally more succinct than Erlang, which is something that strongly pushes me towards using Ruby for most things, and Erlang only where it really shines.

I don't dislike Erlang - quite the contrary - I first encountered it professionally in 2003 and have dabbled now and then with it. I just think it can be a bit "uneven" - which makes me think it will likely never catch on as a very widespread general language.

And I don't believe in "the right tool for the job" - most people are going to know a few languages (at best) and stick with them, because for most things, it's cheaper in terms of overall effort to do something with a language you know than doing it with something you don't and have to learn (also likely not doing as good a job, because you're new to it), even if the result isn't perfect. So languages that are niche only, in my mind, are probably going to be less popular than they could have been if they were more general purpose.

Perhaps a call to dropwhile could be used instead:

http://www.erlang.org/doc/man/lists.html

If anybody is looking for a competent Erlang guy, give Rusty a shout:

http://news.ycombinator.com/user?id=RKlophaus

I met the guy in D.C. and he lives and breathes Erlang.

Reply on news.ycombinator.com