ROR vs. Java / Tomcat
Brad O'Hearne
I know I've asked some of you this question in some form in person, but I wanted to broach the issue one more time in a different form. I also am well aware that this is a Ruby list, so views are going to be likely (and understandably) in favor of using Ruby.
However, I'd like to ask those intimate with outer limitations of ROR what circumstances you would consider Java / Tomcat a better, or equal choice to using ROR for a web interface / web service / REST service server. For the purposes of this question, please ignore issues pertaining to skillset of resource, and corporate concerns like having to use industry standards, and the like. I'm interested primarily in the technical aspects of this question.
I'll also add this one wrinkle -- consider this question for:
a) A web server managing information from a database.
b) A web server providing web services which are pure business logic, and don't immediately need to use a database (i.e. they are computational, or a delegate of behavior which doesn't require database reading / writing).
Thanks for your wizardry,
Brad
Brad O'Hearne
Owner / Developer
Big Hill Software
ph.480.280.1468
fx.888.600.8806
br...@bighillsoftware.com
http://www.bighillsoftware.com
James Britt
> All,
>
> I know I've asked some of you this question in some form in person, but I wanted
> to broach the issue one more time in a different form. I also am well aware that
> this is a Ruby list, so views are going to be likely (and understandably) in
> favor of using Ruby.
>
> However, I'd like to ask those intimate with outer limitations of ROR what
> circumstances you would consider Java / Tomcat a better, or equal choice to
> using ROR for a web interface / web service / REST service server. For the
> purposes of this question, please ignore issues pertaining to skillset of
> resource, and corporate concerns like having to use industry standards, and the
> like. I'm interested primarily in the technical aspects of this question.
You can sort of have both with Rack-based Web apps including Rails)
running under JRuby and deployed to an app server (such as Glassfish)
using Warbler (to make the war file).
It is, technically, Java(tm), so suits should like it. :) They get to
use familiar tools.
>
> I'll also add this one wrinkle -- consider this question for:
>
> a) A web server managing information from a database.
>
Glassfish, etc. can give you connection pooling quite nicely.
> b) A web server providing web services which are pure business logic, and don't
> immediately need to use a database (i.e. they are computational, or a delegate
> of behavior which doesn't require database reading / writing).
The control panels for various apps servers can make deployment and
scaling mush nicer than bare-metal Mongrel, for example.
Perhaps at some future Ruby meeting I can talk on my experience with
Rack, JRuby, Warbler, and Glassfish.
--
James Britt
www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
Brad O'Hearne
I'd love to meet and hear about Glassfish, as I'm actually already
looking into it for the same reason. I don't know when the next Ruby
meeting you can present at is, but If you'd be interested in meeting
possibly next week sometime at a coffee shop, I'm game. We kind of do
that impromptu style stuff with the Joe-Developer group (just area
techies with random tech interests who meet on occasion to discuss
them). It would be of interest to me.
Brad
Logan Barnett
<banner---big-hill-software.gif>
Joshua Zeidner
James,
Have you had any production successes with JRuby?
seems reminiscent of JPython, which is of so-so quality. Ruby and Java are quite different and I can imagine a lot of quirks in something like JRuby.
-jmz
James Britt
> James,
>
> Have you had any production successes with JRuby?
Yes. It's how we pay the bills at Happy Camper.
>
> seems reminiscent of JPython, which is of so-so quality. Ruby and Java
> are quite different and I can imagine a lot of quirks in something like
> JRuby.
We find it quite solid, plus it's the fastest Ruby implementation available.
Kit Plummer
•Kit•
Joshua Zeidner
I recently had a contract with a Brazilian open source group and they were looking at Grails. Its not a very viable option in most cases because the user base is a small fraction to that of RoR- thus the quality is relatively low. Grails has a big following in Germany. If you want MVC+Java use Struts.
-jmz
Logan Barnett
James,
Have you had any production successes with JRuby?
seems reminiscent of JPython, which is of so-so quality. Ruby and Java are quite different and I can imagine a lot of quirks in something like JRuby.
Michelle Lowman
Michelle
James Britt
> Are you going to be talking about this at the RubyConf recap?
I can, but I won't have anything prepared.
james...@gmail.com
On Nov 8, 8:10 am, James Britt <james.br...@gmail.com> wrote:
> Michelle Lowman wrote:
> > Are you going to be talking about this at the RubyConf recap?
>
> I can, but I won't have anything prepared.
>
and deployment of a JRuby Rack app using Warbler and Glassfish. It
would be more or less ad hoc since I have no time to prepare anything,
but I can point out some places where I had trouble getting things
going. It's quite a simple way to create and deploy Ruby apps to
servlet containers, whch is nice.
clintjhill
WAS 6.1 which I'm convinced is doable. However, I'm hearing stories
about crashes and difficult deployments. We are exploring all of our
options, Glassfish included, but the target would be JRuby on
Websphere.
Anyone here deploy to WAS (even the CE version) with JRuby and have
success?
If so were there any hang ups, performance or otherwise?
Thanks - any advice is appreciated.
Joshua Zeidner
Clint,
Sounds like a 'platypus architecture' but I would be interested to know why you would want to do that.
why not use any of the Java based web application platforms available that work great and are natively Java?
Im not sure JRuby will be too popular with things like GWT acting as attractive alternatives.
-jmz
Joshua Zeidner
just want to add a few thoughts here:
the fact is from a strict language perspective, there is nothing that Ruby gives us that we can't get in similar frameworks built in Java or otherwise. What makes Ruby somewhat attractive is that Ruby programmers typically have a good combination of design and programming skills which reduces the cost of dynamic web sites at certain budget scales. As soon as the team size grows, Ruby has a clear tendency to lose its value. There are lots of costs associated with relating designers (who have an arts background) and programmers (who have a sciences background). Ruby does help to lower costs in this respect, because it makes programming a simpler task for certain kinds of problems. Note that Google does not use Ruby on any significant level as far as I know.
so it seems that many of you, and many in the Ruby world are starting to work on larger systems because 1) Ruby has gained credibility, 2) all the systems built in Ruby over the past 5 years have grown... and I think you are assuming that Ruby is the best choice for large systems. While I won't cast aspersions on such use here (probably not the best place for it), it may be somewhat useful for the world as a whole to explain why Ruby is good for larger systems.
when working with PHP and Java I find it best to use distributed protocols like SOAP for intercommunication.
-jmz
Brad O'Hearne
the fact is from a strict language perspective, there is nothing that Ruby gives us that we can't get in similar frameworks built in Java or otherwise. What makes Ruby somewhat attractive is that Ruby programmers typically have a good combination of design and programming skills which reduces the cost of dynamic web sites at certain budget scales. As soon as the team size grows, Ruby has a clear tendency to lose its value. There are lots of costs associated with relating designers (who have
James Britt
> just want to add a few thoughts here:
>
> the fact is from a strict language perspective, there is nothing that Ruby
> gives us that we can't get in similar frameworks built in Java or
> otherwise.
That's only trivially true. The affordances that are built in to a
language aid in reasoning about problems and code. There is a cognitive
difference when working in Ruby vs PHP vs Haskell, even if the
frameworks are superficially the same.
> What makes Ruby somewhat attractive is that Ruby programmers
> typically have a good combination of design and programming skills which
> reduces the cost of dynamic web sites at certain budget scales.
Language design aids (or impedes) the acquisition of design and
programming skills. Working with, say, Lisp or Scheme leads one in a
different direction than COBOL or QBASIC.
> As soon as
> the team size grows, Ruby has a clear tendency to lose its value.
Nice troll.
> There are
> lots of costs associated with relating designers (who have an arts
> background) and programmers (who have a sciences background). Ruby does
> help to lower costs in this respect, because it makes programming a simpler
> task for certain kinds of problems. Note that Google does not use Ruby on
> any significant level as far as I know.
They use Python, a similar language. And JavaScript. Google is big on
flexible, dynamically typed languages (at least for certain things).
>
> so it seems that many of you, and many in the Ruby world are starting to
> work on larger systems because 1) Ruby has gained credibility, 2) all the
> systems built in Ruby over the past 5 years have grown... and I think you
> are assuming that Ruby is the best choice for large systems. While I won't
> cast aspersions on such use here (probably not the best place for it), it
> may be somewhat useful for the world as a whole to explain why Ruby is good
> for larger systems.
Or not. I myself don't give a crap if other people find Ruby useful for
systems large or small. I use what I find works for me. So far I see
nothing to make Ruby a poor choice for large systems.
Joshua Zeidner
That's only trivially true. The affordances that are built in to a
Joshua Zeidner wrote:
> just want to add a few thoughts here:
>
> the fact is from a strict language perspective, there is nothing that Ruby
> gives us that we can't get in similar frameworks built in Java or
> otherwise.
language aid in reasoning about problems and code. There is a cognitive
difference when working in Ruby vs PHP vs Haskell, even if the
frameworks are superficially the same.
or so I hear. Fact is there is a long history of theory behind programming languages, and none of the Ruby proponents have bothered to put their claims in its terms.
Language design aids (or impedes) the acquisition of design and
> What makes Ruby somewhat attractive is that Ruby programmers
> typically have a good combination of design and programming skills which
> reduces the cost of dynamic web sites at certain budget scales.
programming skills. Working with, say, Lisp or Scheme leads one in a
different direction than COBOL or QBASIC.
Nice troll.
> As soon as
> the team size grows, Ruby has a clear tendency to lose its value.
Well, James if you are not arguing from the platform that it is possible, if not probable, there there are some things *that Ruby isn't good at*, I'm not sure if we can have a productive exchange here.
They use Python, a similar language. And JavaScript. Google is big on
> There are
> lots of costs associated with relating designers (who have an arts
> background) and programmers (who have a sciences background). Ruby does
> help to lower costs in this respect, because it makes programming a simpler
> task for certain kinds of problems. Note that Google does not use Ruby on
> any significant level as far as I know.
flexible, dynamically typed languages (at least for certain things).
Google uses a lot of Java.
Or not. I myself don't give a crap if other people find Ruby useful for
>
> so it seems that many of you, and many in the Ruby world are starting to
> work on larger systems because 1) Ruby has gained credibility, 2) all the
> systems built in Ruby over the past 5 years have grown... and I think you
> are assuming that Ruby is the best choice for large systems. While I won't
> cast aspersions on such use here (probably not the best place for it), it
> may be somewhat useful for the world as a whole to explain why Ruby is good
> for larger systems.
systems large or small. I use what I find works for me. So far I see
nothing to make Ruby a poor choice for large systems.
In my view you just contradicted yourself. You may not give a crap what other people think, but big systems' involve lots of people who do give a crap. To reiterate, Ruby is great because it allows one person to perform tasks that perhaps involved a Web dev, a DBA and a Designer before. Problem is that the Ruby stack has problems scaling.
Im certainly not aiming to commit Ruby blasphemy here, so please try to keep this one on the straight and factual please. Ruby = 'Best Language EVAR' is not a statement I plan to respond to.
thanks,
-jmz
Joshua Zeidner
Joshua,I'd like to hear more about this, if you'd care to expound:
the fact is from a strict language perspective, there is nothing that Ruby gives us that we can't get in similar frameworks built in Java or otherwise. What makes Ruby somewhat attractive is that Ruby programmers typically have a good combination of design and programming skills which reduces the cost of dynamic web sites at certain budget scales. As soon as the team size grows, Ruby has a clear tendency to lose its value. There are lots of costs associated with relating designers (who haveIf I read you properly, you are suggesting that Ruby's value isn't the merit of the framework, so much as it is the utility offered to a development team of specific skill sets and size.
Thanks for the response Brad,
Thats right... RoR is not that innovative as a framework. What I find is that many people that use Ruby have very little experience with anything else What you get with Ruby is a very small 'ramp up' cost, which allows designers to quickly reach a productive level (in a programming sense). This tends to scale costs down at certain levels, but also produces people who want to do everything themselves in venues where that is not appropriate.
One thing I can tell you as a concrete rule is that I wouldn't want to invest mine or my client's development future in a product or a development approach that isn't going to scale, or decrease in value as they grow. I'd rather it gain value as it grows, rather than the opposite.
In general if the system is small and local, you'll probably get a good value out of Ruby. If you've got a buyer with big dreams where you'll be responsible for all the costs associated with getting there... not sure if Ruby is right. -jmz
James Britt
>
> If I read you properly, you are suggesting that Ruby's value isn't the
> merit of the framework, so much as it is the utility offered to a
> development team of specific skill sets and size.
Ruby is not a framework, though there are dozens of frameworks written
in Ruby.
> One thing I can tell
> you as a concrete rule is that I wouldn't want to invest mine or my
> client's development future in a product or a development approach
> that isn't going to scale, or decrease in value as they grow. I'd
> rather it gain value as it grows, rather than the opposite.
That's true for all teams using any language. Success depends on proper
size and skill set. Whether the skill set includes Ruby or PHP or Java
or C, it's the same concern, and there's nothing special about Ruby in
this regard. Given any team, the dynamics change when you add or remove
people. (I'm wondering if this concern comes from a false conflation
of Ruby and Rails; Ruby != Rails.)
>
> Is this the general consensus of those using Ruby?
Is what the general consensus? I picked Ruby for its features as a
general-purpose programming language. I have a good choice of
frameworks for different tasks, and have found it reasonably
straightforward to roll my own when needed. I find Ruby extremely
suitable for sys admin work, Web applications, and desktop programs,
have had no issues with "scaling".
Joshua Zeidner
Ruby is not a framework, though there are dozens of frameworks written
Brad O'Hearne wrote:
>
> If I read you properly, you are suggesting that Ruby's value isn't the
> merit of the framework, so much as it is the utility offered to a
> development team of specific skill sets and size.
in Ruby.
That's true for all teams using any language. Success depends on proper
> One thing I can tell
> you as a concrete rule is that I wouldn't want to invest mine or my
> client's development future in a product or a development approach
> that isn't going to scale, or decrease in value as they grow. I'd
> rather it gain value as it grows, rather than the opposite.
size and skill set. Whether the skill set includes Ruby or PHP or Java
or C, it's the same concern, and there's nothing special about Ruby in
this regard. Given any team, the dynamics change when you add or remove
people. (I'm wondering if this concern comes from a false conflation
of Ruby and Rails; Ruby != Rails.)
Not really. Java was perhaps the 'highest' language in existence right now. It is the culmination of decades of CS theory and practices learned the hard way. Ruby is very expressive and easy to pick up. Java is not easy to learn. The OO concepts put a lot of people off and they don't understand why they have to think this way. I'll use a iffy analogy: Java is to Latin what Ruby is to French (think: middle ages :) ). Java is used for more serious things, it is highly formalized but carries a significant overhead, and Ruby is prized for its ease of use and penetration in certain localized areas. You can mobilize your web operations with Ruby, but you can't write a serious financial transaction system with it.
Is what the general consensus? I picked Ruby for its features as a
>
> Is this the general consensus of those using Ruby?
general-purpose programming language. I have a good choice of
frameworks for different tasks, and have found it reasonably
straightforward to roll my own when needed. I find Ruby extremely
suitable for sys admin work, Web applications, and desktop programs,
have had no issues with "scaling".
As it currently stands: there is far too much legacy in major corporate environments to suggest using Ruby for much of anything outside of RoR. You can try. Im not going to stop you. It may be useful to use Ruby as a general purpose language if you're a Ruby programmer, but try to consider the effort involved in re-engineering the utility already found in major languages such as Java. If you claim it is already there, you are kidding yourself. -jmz
David Koontz
On Nov 12, 2008, at 12:19 PM, Joshua Zeidner wrote:
> > There are
> > lots of costs associated with relating designers (who have an arts
> > background) and programmers (who have a sciences background).
> Ruby does
> > help to lower costs in this respect, because it makes programming
> a simpler
> > task for certain kinds of problems. Note that Google does not use
> Ruby on
> > any significant level as far as I know.
>
> They use Python, a similar language. And JavaScript. Google is big
> on
> flexible, dynamically typed languages (at least for certain things).
>
> Google uses a lot of Java.
Google also uses lots of Javascript and C++. All 4 are sanctioned
languages for just about any project and the developers choose the on
that is the best fit. If Python had problems with large teams would
they be writing infrastructure in it? Now I bring up this point
because Python and Ruby are fairly similar with regards to the typical
arguments against dynamic languages re: scaling. I'm not saying Ruby
great for huge systems, I'm not saying it's bad either, I'm just
saying Google views Python and Javascript as maintainable and usable
for infrastructure, and that's a pretty big endorsement of the dynamic
language space for systems that need to work in large teams. Second,
could you please explain the problems you're referring to that in your
opinion Ruby suffers from with large teams. What experiences do you
base your opinions on? I have found that on large teams personnel
issues dwarf any issues languages introduce. Java, for example, was
not a silver bullet for large projects even though it's the most
"protect the programmers from themselves" minded language in
widespread use.
> > so it seems that many of you, and many in the Ruby world are
> starting to
> > work on larger systems because 1) Ruby has gained credibility, 2)
> all the
> > systems built in Ruby over the past 5 years have grown... and I
> think you
> > are assuming that Ruby is the best choice for large systems.
> While I won't
> > cast aspersions on such use here (probably not the best place for
> it), it
> > may be somewhat useful for the world as a whole to explain why
> Ruby is good
> > for larger systems.
One reason that I would give for why Ruby is a good choice is that you
can often get by with a smaller team. Since a large team is going to
have problems no matter what, avoiding the large team (> 11 people) is
a huge benefit in terms of productivity. The same argument could be
made for Lisp or Smalltalk or a host of other high level languages
though, this is not unique to Ruby. Historically, many of these other
languages (mainly Lisp and Smalltalk) have seen great success in very
large scale applications which gives a nice indication that Ruby can
probably do the same. Second, no one here said Ruby was the one true
language to be used in every situation. Lots of Ruby apps use C
libraries and JRuby based apps often use Java libraries heavily (for
both convenience of choice and speed). Third, a point that is related
to point #1. Since Ruby programs are typically much shorter than the
equivalent Java/C#/C++, there is a lot less code to read and
maintain. In a large project, you probably know, an inordinate amount
of time is spent in maintenance. Code that is simple to read and not
cluttered by unnecessary syntax has proven, (for me) to be a boon to
maintenance and bug fixing.
So, if you're looking for a comp sci dissertation on the fundamentals
of Ruby and how they fit into the ecosphere of programming language
theory, well, this is probably the wrong place for that. If you're
looking to get feedback from real developers making their livings off
of Ruby and whatever other technologies they need to get real work
done, then hopefully you'll find this feedback useful.
David Koontz
Chad Woolley
On Wed, Nov 12, 2008 at 12:29 PM, James Britt <james...@gmail.com> wrote:
That's true for all teams using any language. Success depends on proper
size and skill set. Whether the skill set includes Ruby or PHP or Java
or C, it's the same concern, and there's nothing special about Ruby in
this regard. Given any team, the dynamics change when you add or remove
people. (I'm wondering if this concern comes from a false conflation
of Ruby and Rails; Ruby != Rails.)
Not really. Java was perhaps the 'highest' language in existence right now. It is the culmination of decades of CS theory and practices learned the hard way. Ruby is very expressive and easy to pick up. Java is not easy to learn. The OO concepts put a lot of people off and they don't understand why they have to think this way. I'll use a iffy analogy: Java is to Latin what Ruby is to French (think: middle ages :) ). Java is used for more serious things, it is highly formalized but carries a significant overhead, and Ruby is prized for its ease of use and penetration in certain localized areas. You can mobilize your web operations with Ruby, but you can't write a serious financial transaction system with it.
Josh,
At the risk of feeding the flame - how much Production (deployed and running now) Ruby have you written as part of a team (>2 members) for a project of significant length (>1 month)?
I've written a lot of code under these criteria, and I think it is great language. I'll concede that maybe Java makes it easier to have more, and more mediocre, developers, but I'd also argue that that is not really a worthwhile goal...
-- Chad
James Britt
Troll, not flame.
James
David Koontz
> corporate environments to suggest using Ruby for much of anything
> outside of RoR. You can try. Im not going to stop you. It may be
> useful to use Ruby as a general purpose language if you're a Ruby
> programmer, but try to consider the effort involved in re-
> engineering the utility already found in major languages such as
> Java. If you claim it is already there, you are kidding yourself. -
> jmz
I do claim it is already there. I use JRuby every day and leverage
all the goodness of the JVM without writing a line of Java. You seem
to conflate Java the language with the JVM. The JVM in fact is based
on a Smalltalk VM which is a language quite similar to Ruby. I don't
find that many people at my local JUG, conferences, etc. feel that the
Java language is the pinnacle of language design. They all appreciate
the amazing engineering that went into the JVM though. Are you
arguing that because Ruby doesn't have checked exceptions, a complex
generics system that allows NPE's on primitives, no property stystem,
etc. that it lacks the input of years of comp-sci theory? What about
all the comp-sci theory that went into Smalltalk? Ruby shares all of
those characteristics. Just because it's not a static type system
doesn't mean it's not valid. If you're going to argue for the
application of the latest and greatest in comp-sci then Java is about
20 years old, you should really be looking at Haskell, OCaml, Scala,
etc. as functional paradigms are likely to be increasingly prevalent.
Second, you say outside of RoR there's too much legacy. Does that
mean no new language can ever penetrate the corporate sphere? Java
did 12 years ago, why not Ruby today? PHP has penetrated lots of
corporations, Perl too. Just because we're not writing messaging
systems in PHP (ok, maybe Perl) doesn't mean they're not in use.
There's lots of work to be done that's not hard-core nitty gritty comp-
sci algorithm stuff. Java didn't replace C/C++ overnight, it took
until the VM was mature for that to happen, the same is happening for
Ruby (although I'm not saying Ruby *will* displace Java ever, just
that there's no reason it couldn't). Finally, Ruby != RoR. There are
many good web framework and non web related projects going on with
Ruby. Need a new corporate intranet application written in Swing?
You can (and we are) using JRuby/Groovy/Clojure/Jython for that. Lots
of things that used to be Java-only are now "any JVM language"-only.
David Koontz
Chad Woolley
Troll, not flame.
> At the risk of feeding the flame
I initially wrote that but changed it. I try hard to be nice, since my natural tendency is to be a jerk ;)
Joshua Zeidner
>> At the risk of feeding the flame
Im not going to address all the threads that have spawned here. In general, I find the Ruby world does not understand that Ruby is great for managing web UI problems, but not much else. It may appear to do everything to some of everything = Web UI problems. Of course a Ruby programmers will argue that it is possible to do everything in Ruby. But from a manager perspective, I ask: why would I do that? Why use JRuby when I can actually use Java? Historically, these kind of language couplers have been quite problematic, and I have no good reason to believe JRuby is any different. Ruby programmers tend to believe that Ruby has some kind of magical properties, which elude formal analysis that make Ruby the appropriate choice for just about every task we can imagine. Sorry if I suggest your language of choice is not appropriate in every situation- but someone has to bring reason to the argument.
while we could pursue argumentum ad verecundiam with Chad Wooley, just to make it clear I am not claiming to be a Ruby expert. But I have observations which are valid, and I think that what weve got here is the old case of 'man learns to use a hammer and thinks everything is a nail'. -jmz
Joshua Zeidner
On Wed, Nov 12, 2008 at 1:08 PM, James Britt <james...@gmail.com> wrote:wow James, thanks. much appreciated.>Troll, not flame.
>> At the risk of feeding the flame
Im not going to address all the threads that have spawned here. In general, I find the Ruby world does not understand that Ruby is great for managing web UI problems, but not much else. It may appear to do everything to some of everything = Web UI problems.
ech. had a little copypasta fail here. thats " It may appear to do everything to some if everything = Web UI problems." :)
-jmz
Brad O'Hearne
David Koontz
Im not going to address all the threads that have spawned here. In general, I find the Ruby world does not understand that Ruby is great for managing web UI problems, but not much else. It may appear to do everything to some of everything = Web UI problems. Of course a Ruby programmers will argue that it is possible to do everything in Ruby.
But from a manager perspective, I ask: why would I do that? Why use JRuby when I can actually use Java? Historically, these kind of language couplers have been quite problematic, and I have no good reason to believe JRuby is any different.
Ruby programmers tend to believe that Ruby has some kind of magical properties, which elude formal analysis that make Ruby the appropriate choice for just about every task we can imagine. Sorry if I suggest your language of choice is not appropriate in every situation- but someone has to bring reason to the argument.
while we could pursue argumentum ad verecundiam with Chad Wooley, just to make it clear I am not claiming to be a Ruby expert. But I have observations which are valid, and I think that what weve got here is the old case of 'man learns to use a hammer and thinks everything is a nail'. -jmz
Chad Woolley
while we could pursue argumentum ad verecundiam with Chad Wooley, just to make it clear I am not claiming to be a Ruby expert. But I have observations which are valid, and I think that what weve got here is the old case of 'man learns to use a hammer and thinks everything is a nail'. -jmz
Too lazy to even google that Latin. But the point is (other than there are two L's in my name):
* Real developers who use Ruby learn to love it.
* Loving your language means loving your job, if you are a developer
* Loving your job means doing efficient and quality work, day after day
* Efficient and quality work is what matters to managers and customers (or should, if they are doing their job right)
I've coded in several languages, including Java for many years, and Ruby for multiple years. Ruby is different. Very different. It's not a hammer for every nail, but it is a malleable tool which feels good in your hand, and can be applied effectively to many tasks, be they nails or not.
My objection is when uninformed people make claims on subjects in which you have no experience. If you have not personally used Ruby to develop production applications as part of a team, then you do not have experience on the subject you are discussing, and should consider being a little less adamant when saying it is not a superior, or at least equal, approach.
-- Chad
Joshua Zeidner
Chad, there is a definite problem when the technical informant is also the salesman.
-jmz
David Koontz
On Nov 12, 2008, at 2:09 PM, Brad O'Hearne wrote:
> The point of my question is really to eventually sift through the
> "views" and get to whatever concrete technical criteria there are
> for deciding between alternatives. That's where I'm extremely
> interested. So while it may touch nerves, I find the suggestion that
> the productivity gains of ROR have decreasing returns under certain
> conditions a worthy premise to pursue down to a determination that
> it is either true, or false, or sometimes one or the other.
I know you didn't get as extensive answer on the JUG list but did you
get the sense that Java web frameworks are immune from problems as
they grow larger? I hear this claim about decreasing returns for
language X or framework Y without much in the way of specifics. I've
certainly experienced decreasing returns using Struts or other Java
web frameworks because *everything* has decreasing returns as the
project gets bigger. More overhead means less can get done, I don't
think any language or framework is going to save you from that. Now,
if RoR falls off much faster than the equivalent Java framework, then
that certainly would be a cause for concern, although I think in
reality the success falls far more onto the shoulders of the
individuals involved instead of the technology choice (so give them
the best tech, whatever that may be). I don't know of any concrete
technical criteria that can be used to measure the construction of
large software projects across different languages. Steve Yegge had a
post a few years back observing Java teams vs Perl teams internally at
Amazon but that's about the closest thing I've seen to a comparison of
large projects "in the wild". If you do have any such references I'd
be very interested in reading up on them as this is a topic that comes
up a lot and, unfortunately, is always relegated to hand waiving. :(
David Koontz
Joshua Zeidner
Brad,
those are the kind of concerns Im addressing with my statements. From my perspective, suggesting that Ruby is good for everything is preposterous. In the AZ scene, most of the jobs are very small websites where low cost, snappy attractive UIs, and quick time to deliver are highly valued. Long term maintainance including future labor costs are not really factored into the equation. Personally I would not recommend using JRuby for many tasks- theres just too many variables there not to mention you break untold levels of your process ranging from deployment to debugging.
the Tomcat stack has proven itself to be a long-term contender with useful long-standing semantics and friendly licensing.
-jmz
James Britt
>
> This list isn't my only source of information -- I've been talking
> with someone with a company who does georouting or municipalities
> across the country on a Flex-ROR stack for over a year now. I also
> have someone I'm working with who has extensive ROR experience, and
> his views as a sounding board too. So do not think that I'm doing
> anything based solely upon information in a post or two here.
Excellent.
>
> The point of my question is really to eventually sift through the
> "views" and get to whatever concrete technical criteria there are for
> deciding between alternatives. That's where I'm extremely interested.
> So while it may touch nerves, I find the suggestion that the
> productivity gains of ROR have decreasing returns under certain
> conditions a worthy premise to pursue down to a determination that it
> is either true, or false, or sometimes one or the other.
The discussion here kept flipping between some framework and Ruby as a
whole, and it's important to note that various issues with Rails may
not be a problem in other Ruby Web frameworks, or with Ruby the language
itself.
David Koontz
territory now.
On Nov 12, 2008, at 2:32 PM, Joshua Zeidner wrote:
> Brad,
>
> those are the kind of concerns Im addressing with my statements.
> From my perspective, suggesting that Ruby is good for everything is
> preposterous.
For the umpteenth and final time, no one has made this assertion
except *you*.
> Personally I would not recommend using JRuby for many tasks- theres
> just too many variables there not to mention you break untold levels
> of your process ranging from deployment to debugging.
Since you've clearly never touched JRuby let me educate you. JRuby
runs on the JVM. The deployment scenario is JVM based. You deploy on
Tomcat, on Glassfish, on whatever has a servlet container (I'll give
you a hint, that's *everything*). You can debug into your JRuby code
from Netbeans/Eclipse. You can hook up to your JRuby app with Visual
VM and take a look. Your classes compile down into .class files and
you bundle them into jars. You hand your sysadmin a .war file and
they deploy it. There is no barrier to integrating JRuby into a Java
ecosystem. Sun is running commercial projects on JRuby (Kenai) as is
Oracle (Oracle Mix), both of which are obviously very Java heavy in
their infrastructure.
> the Tomcat stack has proven itself to be a long-term contender
> with useful long-standing semantics and friendly licensing.
And your deployment descriptor is still XML, just like it's always
been. All your Tomcat config guru knowledge still works, you still
deploy a war file, it just happens to be Ruby inside. As for
licensing, what the hell are you talking about? Just about everything
in the JRuby / Ruby world is under the Ruby license which is basically
MIT, one of the most open licenses ever.
Brad, hopefully some of this is actually helping. I'm going to stop
feeding the trolls now since it's pretty clear to me now that Mr.
Zeidner is simply throwing out unfounded allegations to try and smear
the reputation of Ruby.
David Koontz
Joshua Zeidner
Ok, I'm beginning to agree with James. Josh is definitely into troll
territory now.
Im sorry, I thought for a minute here this was the 'ROR vs. Java / Tomcat' thread, not the 'Should the Whole World be Rewritten in Ruby?' thread. Have a look around the software industry some time. and please grow up.
-jmz
Chad Woolley
Ok, I'm beginning to agree with James. Josh is definitely into troll
territory now.
Yep. Everyone stop feeding. 123 GO!
Brad O'Hearne
I've been doing Java development almost since its inception, and I
still find many things cumbersome in Java. I attribute that in part to
Sun, not so much that they've done something wrong per se, but that
they have seemed averse to really putting significant effort into
bringing the SDK beyond widget stage to the place where it was uber-
productive. Therefore, the OSS world has generally lead in that area.
(My opinion only, not need to debate that).
Having said that, I really like many things I see in ROR. However, I
don't see (yet) what ROR offers that couldn't be done in Java given a
clever, code-generating or introspecting framework. The advantage I
see now is that in ROR, it is already there. The other thing I'm kind
of hitting on here is that the proof is beyond tutorial-land.
Tutorials are great, I love them, but as soon as you get into solving
a real problem, then the real issues arise. The other thread I posted
about non-entity orientation, or action-orientation, or business-logic
orientation (call it what you want) is an example of this. I
definitely want a framework to expedite managing entities and database
operations. ROR wins there. But that's only one part of the equation.
I have computational, business-logic oriented services which may be
leveraging other services; and this has to be done under potentially
high traffic volume. This is what gets me to really thinking
critically about what the nature of productivity gains in ROR really
are -- is it the language itself (Ruby)? Is it just having conventions
organized? Is it generating and managing all the database code? Is it
generating and managing deployment / undeployment? The reason those
are important is because:
- if it is language, then conversation over. We don't need to debate
much else, it is what it is.
- If it is having conventions organized, then that seems a matter of
discipline, which can be realized on any platform.
- If it is generating and managing database code -- then I'll take it
with a grain of salt, for two reasons: a) because as a DBA in a long,
lost, ancient life, I am somewhat of a tier / database design purist.
Although I engage regularly in the practice of managing the database
from the middle tier, I am somewhat philosophically opposed to the
notion that this is where it ought to be done (big conversation here
-- not trying to cause a diversion). It isn't optimal from a database
standpoint for either performance, security, or management. I guess it
isn't so much an issue of is the middle tier managing the database so
much as it is an issue of what options there are to not do things this
way. (In fairness, the same criticism could be made of Hibernate).
- Is it generating / managing deployment? Fair enough, but not my
primary concern.
Anyway, I think you get the idea -- I should tip my hat to those who
are pointing out the Ruby / ROR difference -- I am talking ROR here --
Ruby vs. Java as a language / platform is another conversation. There
are things about Ruby that I am completely enamored with, and think
are sorely lacking in the Java language (like, for lack of the proper
terminology, the ability of Ruby to dynamically type / apply
interfaces to classes at runtime).
Brad
Preston Lee
Joshua Zeidner
excuse me? do any of you ever leave your basements? few of you know me, I try to make a positive contribution to the thread, faithfully stay on topic, and you do not appear to be able to tolerate someone who believes something other than 'Ruby is the only useful language in existence'. Would any of you idiots dare to act like this in real life? Do you have a real life?
I have enough experience to know that the ones who are loudest on an internet forum are rarely the ones with any useful information to share. While I might be tempted to assume that 'troll' here is used to mean : 'Ruby infidel', I tend to think the various loudmouths on here are about as useful as they are subtle. Please allow Brad O'Hearne to ask the question he wants without obstruction.
-jmz
Joshua Zeidner
I don't think anyone is claiming Ruby is 100% the right choice for every situation
It certainly would appear that some are suggesting just that, but to respect this forum, lets just try to address Brad's original q without resorting to name calling and other stupidity.
I do agree that Java has high initial overhead and not well suited to many sysadmin tasks where performance and durability are not major requirements. thanks, jmz
Logan Barnett
Anyway, I think you get the idea -- I should tip my hat to those who
are pointing out the Ruby / ROR difference -- I am talking ROR here --
Ruby vs. Java as a language / platform is another conversation.
James Britt
> I have enough experience to know that the ones who are loudest on an
> internet forum are rarely the ones with any useful information to share.
.
James
Kit Plummer
Just curious - who are you Mr. Zeidner?
Preston Lee
> --~--~---------~--~----~------------~-------~--~----~
> You are subscribed to the Google Groups "Phoenix Ruby Users Group"
> group.
> To post, send email to phoeni...@googlegroups.com
> To unsubscribe, send email to phoenix-ruby-
> unsub...@googlegroups.com
>
> The Phoenix Ruby User Group is sponsored by Rising Tide Software and
> meets on the 2nd Monday of each month at the Rising Tide offices.
> See http://rubyaz.org
> -~----------~----~----~----~------~----~------~--~---
>
Marc Chung
If you guys want to banter about this all day--especially subjectively
and even inaccurately, I might add--I suggest we do this the old
fashion way: a code showdown...
In your favorite programming language, write a search engine that
returns relevant posts made by Arizona bloggers.
Your program should:
- Be open sourced
- Crawl posts from readphoenix.com
- Implement the original PageRank algorithm in the Page/Brin paper [1]
- Execute search queries in a timely fashion
- Offer an XML interface for third party users.
- Run on a single machine
Your program will be graded solely on the following criteria:
- PageRank accuracy.
- I will performance test the living daylights out of your application.
- The last one standing, wins.
If there are 3 or more teams, of differing programming languages, I
will come up with a (yet TBD) cash prize.
Who wants to participate?
--Marc Chung
[1] http://infolab.stanford.edu/~backrub/google.html
Joshua Zeidner
although I don't have any time to participate, Java has you beat there hands down. see: Nutch. Its practically already done.
-jmz
clintjhill
I just asked if anyone had experience deploying Rails to Websphere.
I give a shit less what you think of Ruby, Rails or Java. I work for a
living. I don't proselytize. Josh, thanks for the attempt but damn
man, if you don't have input to the "topic" then piss off. You totally
ruined my opportunity to pick the brain of James with your
distraction. Yep - distraction. While I'm sure you meant no harm, I'm
also positive you have no clue about Ruby. If you did you wouldn't
direct your original statement the way you did.
I happen to be a Ruby, Java, C#, JavaScript kind of developer. Try
boxing me into one camp and you're fucked. I work. I use the language
that best fits the problem. The project I'm on is small. Rails fits
nicely there. My server environment is Websphere. I have to make the
two join nicely. I know it can be done, I'm just reaching out for a
little help.
So back to my question ... please? Or do I need to piss off?
>
> > On Wed, Nov 12, 2008 at 4:48 PM, Preston Lee <preston....@openrain.com>
James Britt
> guys ... guys ... hey ... over here !
>
> I just asked if anyone had experience deploying Rails to Websphere.
>
> I give a shit less what you think of Ruby, Rails or Java. I work for a
> living. I don't proselytize. Josh, thanks for the attempt but damn
> man, if you don't have input to the "topic" then piss off. You totally
> ruined my opportunity to pick the brain of James with your
> distraction. Yep - distraction. While I'm sure you meant no harm, I'm
> also positive you have no clue about Ruby. If you did you wouldn't
> direct your original statement the way you did.
Hey, ask away, and forget the noise.
The Warbler gem works with any Rack-based app, but has a focus on Rails.
When you run
$ warbler config
it creates config/warbler.rb file, which has a default collection of
Rails app settings. (But warbler can be used very nicely with Merb,
Ramaze, etc with just a small amount of config tweaking. See
http://www.jamesbritt.com/2008/11/11/ramaze-warbler-glassfish
for how I used it with Ramaze.)
Running the "warble" command on your project then gives you a WAR file
that contains all the code (libs and views and all) your app needs. It
also has a descriptor file and all that fun Java web app XML stuff.
At that point you should be able to deploy the WAR file to any Java app
server as you would any plain old Java Web app. I've done it on
Glassfish, not Websphere, but in theory it *should* "just work." The
whole process is pretty simple to try, so I'd suggest experimenting.
I've not used Websphere in quite some time so I don't know how much
tweaking might be needed (if any).
One caveat: make sure your Rails app plays nice with JRuby. If you are
using AR with MySQL (or any other DB for which there is a JDBC driver)
you should be golden. If your app is using any libs that requires native
bindings (RMagick, for example) you may need to swapped them for the
JRuby version. But if you've installed those libs as gems under JRuby
then the Rails app should simply find the correct one when rub with JRuby.
People using Merb may have trouble if they are using DataMapper because
of native code in the data objects.
I think you could just run the app via JRuby + Webrick (or whatever is
the default) like this:
$ jruby -S script/server
Or run your tests/specs under JRuby.
Happy Camper Studios has a lot of JRuby experience, so please feel free
to ask questions.
Kit Plummer
framework to the job. Although I like the appeal of Ruby (promoted by
the ability to get there via JRuby), Grails offers a slightly cleaner
(integration) path to your objective. True, the Grails community
can't really compare to RoR - but the pending acquisition of G2One by
SpringSource will surely assist the continued progress of both Groovy
and Grails.
I've done development with Grails, RoR, Merb, and Ramaze and they all
have their quirks. If you are already familiar with Java, Groovy will
be an easier transition than Ruby.
Kit
clintjhill
try and find out why we seem to have problems. My hunch is we aren't
configuring the web xml configs properly for WebSphere.
Thanks for the attention. Sorry to have triggered yet another Ruby vs.
Java pissing match.
Brad O'Hearne
anymore in this thread (or maybe at all :-), but as I see my mail
folder keep growing in size on a thread I started, and mostly in a
less than constructive manner, I almost feel a responsibility to
steer, end, or officially depart the thread. I'm not sure which I'm
doing here, but I suppose the end result is the same, at least for my
participation.
Guys, I found *everyone's* input (which was relevant to the question)
useful, on all sides of the argument. No one is vying for my loyalty
here -- nor was my intent to put either Ruby, ROR, or Java on trial,
or be able to slap a once-for-all-forever label on anything. My intent
was to get strengths / weaknesses type feedback on all sides.
So at least for the purposes of answering my question, everyone can
consider the question answered. I appreciate the feedback -- if anyone
has further useful technical information to impart on this, feel free
to contact me offline.
I'll be a bit more prudent about posting compare / contrast type
questions here in the future.
Cheers,
Brad
On Nov 13, 2008, at 6:39 AM, clintjhill wrote:
>
Chad Woolley
I'll be a bit more prudent about posting compare / contrast type
questions here in the future.
I wouldn't worry about it. I kind of enjoyed this thread, and anyone who doesn't like it can hit mute in gmail.
A good flame war can be fun, as long as it doesn't get too out of hand. I don't think this one did, people knew when to stop (around the 50 message mark). I even forgive Joshua for calling me an idiot. We're all friends here, and developers should be thick-skinned about technical stuff.
Love,
-- Chad