InfoQ Article: From Java to Ruby - Risk

My apologies for the readers, but the title of the article was mispelled. It should say :

"How you, script kiddies, can play with building simple tiny CRUD web apps, and enjoying your ignorant life without clustering, legacy system integration, distributed caching, [put your favourite here]..."

It is quite amazing to see article after article that has the same error, but no correction from the original posters whatsoever.

Peace

The author clearly speaks about niche-markets. Also, we must agree that not all built apps are needing clustering, legacy system integration, etc. Now, I am wondering what is wrong with having different tools to build different solutions?

./alex
--
:Architect of InfoQ.com:
.w( the_mindstorm )p.

Baron - the article did not attempt to pitch Rails as a solution for large scale distributed systems so it's not fair to criticize it as though it was. It's a fact that Rails is optimal for green field web apps, as evidenced by the Java community attempting to emulate many of these features on it's own web frameworks.

If you're not interested in Ruby/Rails content then you feel free to turn the Ruby community off (see that little widget on the left side bar).

Floyd

There are ways to do clustering, legacy system integration and distributed caching with Ruby. And calling Bruce Tate a script kiddy is, well, misguided.

Also, we must agree that not all built apps are needing clustering, legacy system integration, etc.

Now, I am wondering what is wrong with having different tools to build different solutions?

It's a fact that Rails is optimal for green field web apps...

If you're not interested in Ruby/Rails content then you feel free to turn the Ruby community off

Also, we must agree that not all built apps are needing clustering, legacy system integration, etc.

Now, I am wondering what is wrong with having different tools to build different solutions?

It's a fact that Rails is optimal for green field web apps...

If you're not interested in Ruby/Rails content then you feel free to turn the Ruby community off

It's a fact that Rails is optimal for green field web apps...

IMHO, than this should be stated clearly in the article.

[...]however it is quite annoying to regulary see comparison of RoR and Java, where
usually Java is mentioned in negative context.

Baron, it seems to me that your points are valid for many articles -- although hopefully for none of those published on InfoQ. No offense, but did you actually read this particular one? It does not seem to suffer from the script-kiddy-silver-bullet symptom IMO. But maybe I've missed the parts you allude to -- in this case, please point them out.

I think Bruce is right to focus on productivity as the factor that makes you want to cross the chasm. But where is that productivity if you have to drop back to C for anything more complex than CRUD? CRUD is not that first niche from which a language can go on to conquer the world. It's one of the few things a language 10 times slower than Java or C++ can ever do because CRUD means delegating all the real work to the DBMS and the operating system.

And no, it's not simply a matter of moving your work to JRuby or some CLR based Ruby implementation. Its creators started Ruby at a time when there were no mainstream VMs and they didn't create one either. And that means that Ruby (and Python and Perl) is stuck on that antiquated platform that is C. The implementors of JRuby have to port all the C based stuff to Java and they will always lag behind. It's a brain dead duplication of effort. More and more libraries are created for C based Ruby and there's no way anyone can keep up with porting that stuff to the JVM. C based Ruby becomes more entrenched every day and that means everyone doing anything other than CRUD has code it in C as well.

Are we really moving our infrastructures back to C just because we want to use some dynamically typed scripting language for the CRUD part? I don't think so. It's not that Ruby is too risky. It's that the Ruby environment as a whole is unproductive because it is based on an antiquated platform model.

Yes it's true, J2EE is unwieldy and bloated. Its development and deployment model runs counter to anything remotely agile and the latter hasn't changed in JEE 5 either. But does that mean we should roll back the real progress that has been achieved with JIT accelerated platform independent virtual machines? I think not. It would be a step back in time.

Funny, today Joel commented on a related subject:

"... and a handful of platforms where The Jury Is Not In, So Why Take The Risk When Your Job Is On The Line? (Ruby on Rails). Before you flame me, Ruby is a beautiful language and I'm sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I'm sure you'll have a lot of fun, but for Serious Business Stuff you really must recognize that there just isn't a lot of experience in the world building big mission critical web systems in Ruby on Rails, and I'm really not sure that you won't hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot..."

www.joelonsoftware.com/items/2006/09/01.html

He's being more sly about it now but I can't believe that people are still seriously comparing Ruby to Java. People who wanted to whip out quick web apps have always had the option of using languages like PHP and Python. How often do you see posts of this nature regarding Python vs. Java? Almost never.

I agree that Bruce glosses over with a very wide brush the advantages of Java, and likewise glosses over the disadvantages of Ruby. I happen to think that Rails is a great framework; for me it's Ruby that's the problem. I can't stop thinking that a language that uses run time type checking is simply less safe than one that uses complile time type checking. Regardless of whether it's a small team or even just one person, versus a large team working on a large project.

Not necessarily - en.wikipedia.org/wiki/Duck_typing

It's a risk/reward equation, no? Before automated testing, Java wins. Since automated testing, the reward for static typing is not so great.

I agree that Bruce glosses over with a very wide brush the advantages of Java, and likewise glosses over the disadvantages of Ruby. I happen to think that Rails is a great framework; for me it's Ruby that's the problem. I can't stop thinking that a language that uses run time type checking is simply less safe than one that uses complile time type checking. Regardless of whether it's a small team or even just one person, versus a large team working on a large project.

I just completed a total rewrite of a LAMP system in RoR. I re-created a year and a half worth of part time development in a little under 3 months of part time Ruby. (Although the last few weeks going into production were full time.) As part of the re-write, I developed a lot of new features and COMPLETELY REFACTORED MY DATABASE MODEL -- with over 75 tables.

I have never in my entire 15 year career contemplated completely redesigning the database of a running, production application. Add a table here and there but never, ever perform major surgery. This was only possible due to a feature of Rails: Migrations. I am sure there are good tools out there to version your data model but I have come across nothing so sweetly integrated with your code base as migrations. I am one of those "Technologist/Early Adopters." Call me crazy now but I jumped on Java in '96. This is all that and more. And it's just plain fun.

I knew nothing about Ruby before starting and I never wrote a demo or greenfield application on it. I figured it would be more instructive to take an application that I actually understood and re-do it. Your milage may vary.

If you are a big self starter and your productivity is truely important (ie. your time is highly valued) -- consider RoR. If you tend to require formal training, you probably should wait till it is more widely adopted.

I have a nose for things and I suspect there will be good money in RoR consulting for the early birds...

" I can't stop thinking that a language that uses run time type checking is simply less safe than one that uses complile time type checking. "

Not really. The problem is comprehensibility, especially when it comes to mixins. It'll be interesting to see how Rails manages interface creep over the next few years. Systems that allow unfettered interface and function binding can be very hard to understand and work with in the whole (cf Zope 2). In java mucking about with classes and interfaces is limited to framework infrastructure. In Rails this is very much exposed to the app developer. That's touted as an advantage today, but it's not free. I expect Bitter Ruby will have a chapter called 100 Method Object.

It's a risk/reward equation, no? Before automated testing, Java wins. Since automated testing, the reward for static typing is not so great.

Ah...that's a pretty broad brush you're using. One size fits all.

So...do you use

- Spring to delay binding until run time
- XML to configure anything, which also allows runtime type checking
- Byte code enhancement and reflection frameworks that use run time type checking, within the context of persistence frameworks?

So you use delayed binding and run time checking all of the time. You just don't get all of the benefits of a language that makes it easy to do the same.

The problem is comprehensibility, especially when it comes to mixins. ... Systems that allow unfettered interface and function binding can be very hard to understand and work with in the whole (cf Zope 2). ... In Rails this is very much exposed to the app developer. That's touted as an advantage today, but it's not free. I expect Bitter Ruby will have a chapter called 100 Method Object.

I completely see where you're coming from. I don't think that Rails is perfect. In some ways, it's too accessable. The problem is that we're seeking the same sorts of Rails-like capabilities with Java right now. The complexity comes in a different form, but it still comes. You talk about the 100 method object; what about the 100-class framework to do the same?

Face it: Spring, AOP, heavy reflection, annotations, byte code enhancement, servlets, deployment descriptors, xml configuration...all of these delayed binding programming techniques come with intellectual baggage of their own.

The question is whether you want to be direct about it, at a limited cost, or indirect, at a far greater cost.

The problem is comprehensibility, especially when it comes to mixins. ... Systems that allow unfettered interface and function binding can be very hard to understand and work with in the whole (cf Zope 2).

Sorry for Bruce Tate but the future of webtechnology (for us Java-developers!) might not be Ruby on Rails. The future might be GWT, Google's webtoolkit.

RoR is a pur serverside-framework whereas GWT is a complete client-side and server-agnostic webframework that helps us to build rich web-content in future. Does RoR help us to build rich content say Ajax-RIA's ? I don't think that a pur serverside-framework can provide those facilities. GWT does.

Furthermore RJS (Ruby-Javascript-templates) cannot provdide what GWT can. Being a clientside webframework and being server-agnostic is a very important point too: you can easily connect all kinds of so-called legacy applications like Struts to a GWT-frontend. Being server-agnostic allows us to use existing PHP-, Perl-, Python- etc. infrastructures such as Wikis, CRM's, forums etc.

He's being more sly about it now but I can't believe that people are still seriously comparing Ruby to Java. People who wanted to whip out quick web apps have always had the option of using languages like PHP and Python. How often do you see posts of this nature regarding Python vs. Java? Almost never.

The thing that really turns me off is that Java is singled out for comparison when the usual methodology is to make broad comparisons ... This sort of Burger King/Pepsi (cut down the "market leader" but not the others) type of marketing works for some people, but not all.

I beg to differ! In fact, we only had to port a few core libraries like YAML support, ZLib, and Sockets to get Rails running under JRuby. In 95% of cases, Ruby libraries are written in pure Ruby. In the few cases where a port is necessary, it's almost always just a matter of wrapping existing functionality in Java. For example, Java has very good ZLib and Socket support, so we mostly just had to wrap those existing features.

JRuby already can run Rails in many scenarios, and we're improving compatibility and performance day by day. Almost all C-based extension writers we've talked to are also very interested in having Java-based versions of their code. A notable supporter is Zed Shaw, creator of Mongrel, who has been very helpful in our efforts to bring Mongrel over to JRuby. Not only will JRuby be able to keep up...we'll be able to innovate in many cases. That means more Ruby for everyone!

Baron,
Your attitude can easily be classified by reading this very article. You either should have read before posting or articulate the points.

I just completed a total rewrite of a LAMP system in RoR. I re-created a year and a half worth of part time development in a little under 3 months of part time Ruby.

It's a risk/reward equation, no? Before automated testing, Java wins. Since automated testing, the reward for static typing is not so great.

Do you have any evidence or can you point to any studies that show testing closing the reliability gap with weakly typed systems vs strongly typed ones? It sounds kind of reasonable but there is a ton of evidence, pretty much as long as software engineering has been around that shows a substantial advantage to having compile time checks.

Automated testing is not a terribly new concept, it is also something that has been going on since the 60's or even earlier.

[Ruby is] certainly worthy of attention and doesn't need to expend entire books to comparing itself to Java.

I just completed a total rewrite of a LAMP system in RoR. I re-created a year and a half worth of part time development in a little under 3 months of part time Ruby.

Assume you spent 18 months on a RoR project and you decide to rewrite it in Java, don't you think you will do so in much less time than 18 months?

--
Cedric

Perhaps. A rewrite between comparable languages should take less time because you are not learning the domain model at the same time. However, I shudder to think about the task of rewriting 18 months of RoR in Java.

From my brief brush with Python, I would say a rewrite in Python would be easier to contemplate.

The lines of code multiple with respect to Java alone would be enough to intimidate me out of that particular path. I prefer to work at as high a level as possible.

So do I, but just because it takes more lines of code to do Web applications in Java than in Ruby doesn't mean that it takes more time to do so.

And in my world it's practically always Ruby vs. Java vs. C#.

Re C#, as the article says "I'd throw C# into the mix as effectively a Java clone, though there's room for some argument."

That's my humble (but well informed) opinion as well. There are differences between C# and Java, but for the purpose of comparing them both to Ruby, those differences are not significant enough.

I know just enough PHP to say that the leap from PHP to Ruby is not that big. You are still on the LAMP stack with dynamic typing and interpreted code. In this genre, Ruby is an obviously better general-purpose programming language than PHP, and (from what I hear) Rails is an obviously better MVC framework than any in the PHP world.

Having said that, there are still valid reasons to stay with PHP in certain situations, even so the decision should not be too hard to make.

just because it takes more lines of code to do Web applications in Java than in Ruby doesn't mean that it takes more time to do so.

Risk that the project cannot be built? Risk that the project cannot be sold? Risk that the product has low quality? Risk that the product cannot perform? Risk that you're doing something different than everyone else? Risk of being ashamed for doing something different?

Market share doesn't really reduce some of those risks or really have anything at all to do with them.. Which risk does "language bloat" impact? Can you back that up with any evidence? Doesn't that contradict your thesis because Ruby has a lot more language features than Java does? While Java has a lot more libraries, is it the libraries that cause the bloat? I thought that as market share increased the increased access to libraries/gems and that reduced risk?

Is a new programming language inherently risky? It either works or doesn't, right? The risk is just how much you might have to do to make your project successful with it. You might have to write your own implementation of it, for example, like JRuby.

Seriously, this article isn't even consistent within itself. Is this the kind of crap InfoQ is really about? Bruce, you have anything to add? An apology? Or maybe take your name off it or something? Or maybe you want to take all the risk stuff out and just talk about how great Ruby and Rails is or something?