I'm wondering if there are any less-biased resources that give good, specific overviews of programming languages and their intended goals. I would like to learn a new language, but visiting the sites of each language isn't working. Each one talks about how great it is without much mention of it's weaknesses or specific goals.Ruby is a dynamic, open source  programming language with a focus on  simplicity and productivity.Python is a programming language that  lets you work more quickly and  integrate your systems more  effectively.Having been a PHP developer for years, Vic Cherubini sums up my plight well:I knew PHP well, had my own framework,  and could work quickly to get  something up and running.I programmed like this throughout the  MVC revolution. I got better and  better jobs (read: better paying,  better title) as a PHP developer, but  all along the way realizing that the  code I wrote on my own time was great,  and the code I worked with at work was  horrible. Like, worse than horrible.  Atrocious. OS Commerce level bad.  Having side projects kept me sane,  because the code I worked with at work  made me miserable.This is why I'm retiring from PHP for  my side projects and new programming  ventures. I'm spent with PHP.  Exhausted, if you will. I've reached a  level where I think I'm at the top  with it as a language and if I don't  move on to a new language soon, I'll  be done completely with programming  and I do not want that.Languages I've looked at include JavaScript (for node.js), Ruby, Python, & Erlang. I've even thought about Scala or C++. The problem is figuring out which ones are built to handle my needs the best.So where can I go to skip the hype and get real information about the maturity of a platform, the size of the community, and the strengths & weaknesses of that language. If I know these then picking a language to continue my web development should be easy.UpdateI just don't want to get 4 months down the road with some language and find it sucks because each thread has 4MB of overhead, or the max concurrent connections is 999, there is no package to do X feature, or support is being phased out for a new language branch.
Finding a new programming language for web development?
programming languages
I wasn't going to post this as an answer, but Xeoncross asked me to, so here we go:(Sidenote: if someone could fix the markdown issue in the little code example, I'd appreciate it.)Posted by Alex Martelli on comp.lang.python: What's better about Ruby than Python? on Aug 18 2003, 5:50 pmErik Max Francis wrote: Brandon J. Van Every wrote: What's better about Ruby than Python? I'm sure there's something.       What is it?       Wouldn't it make much more sense to ask Ruby people this, rather than       Python people? Might, or might not, depending on  one's purposes -- for example, if   one's purposes include a sociological  study of the Python community,  then  putting questions to that community is  likely to prove more  revealing of  informaiton about it, than putting  them elsewhere:-).   Personally, I  gladly took the opportunity to follow  Dave Thomas'  one-day Ruby tutorial at  last OSCON. Below a thin veneer of  syntax  differences, I find Ruby and  Python amazingly similar -- if I was   computing the minimum spanning tree  among just about any set of   languages, I'm pretty sure Python and  Ruby would be the first two  leaves to  coalesce into an intermediate node:-).Sure, I do get weary, in Ruby, of  typing the silly end at the end  of  each block (rather than just  unindenting) -- but then I do get  to  avoid typing the equally-silly :  which Python requires at the   start of each block, so that's almost a wash:-). Other syntax   differences such as @foo versus  self.foo, or the higher significance  of case in Ruby vs Python, are really  just about as irrelevant to me.Others no doubt base their choice of  programming languages on just  such  issues, and they generate the hottest  debates -- but to me that's  just an  example of one of Parkinson's Laws in  action (the amount on  debate on an  issue is inversely proportional to the  issue's actual  importance).   One  syntax difference that I do find  important, and in Python's  favour --  but other people will no doubt think  just the reverse --  is how do you  call a function which takes no  parameters. In  Python (like in C),  to call a function you always apply  the  call operator -- trailing  parentheses just after the object   you're calling (inside those trailing  parentheses go the args  you're  passing in the call -- if you're  passing no args, then  the parentheses  are empty). This leaves the mere  mention of  any object, with no  operator involved, as meaning just a   reference to the object -- in any  context, without special  cases,  exceptions, ad-hoc rules, and the  like. In Ruby (like  in Pascal), to  call a function WITH arguments you  pass the  args (normally in  parentheses, though that is not  invariably  the case) -- BUT if the  function takes no args then simply   mentioning the function implicitly  calls it. This may meet  the  expectations of many people (at least,  no doubt, those  whose only previous  experience of programming was with  Pascal,  or other languages with  similar implcit calling, such as   Visual Basic) -- but to me, it means  the mere mention of an  object may  EITHER mean a reference to the object,  OR a call  to the object, depending on  the object's type -- and in those   cases where I can't get a reference to  the object by merely  mentioning it I  will need to use explicit give me a  reference  to this, DON'T call it!  operators that aren't needed  otherwise.  I feel this impacts the  first-classness of functions (or   methods, or other callable objects)  and the possibility of  interchanging  objects smoothly. Therefore, to me,  this specific  syntax difference is a  serious black mark against Ruby -- but  I do understand why others would thing  otherwise, even though  I could hardly  disagree more vehemently with them:-).  Below the syntax, we get into some  important differences in  elementary  semantics -- for example, strings in  Ruby are  mutable objects (like in  C++), while in Python they are not   mutable (like in Java, or I believe  C#). Again, people who  judge  primarily by what they're already  familiar with may  think this is a  plus for Ruby (unless they're familiar  with  Java or C#, of course:-). Me, I  think immutable strings are  an  excellent idea (and I'm not surprised  that Java, independently  I think,  reinvented that idea which was already  in Python), though  I wouldn't mind  having a mutable string buffer type  as well  (and ideally one with better  ease-of-use than Java's own  string  buffers); and I don't give this  judgment because of  familiarity --  before studying Java, apart from  functional  programming languages  where all data are immutable, all  the  languages I knew had mutable  strings -- yet when I first saw  the  immutable-string idea in Java (which I  learned well before  I learned  Python), it immediately struck me as  excellent, a  very good fit for the  reference-semantics of a higher level   programming language (as opposed to  the value-semantics that  fit best  with languages closer to the machine  and farther from  applications, such  as C) with strings as a first-class,  built-in  (and pretty crucial) data  type. Ruby does have some advantages in  elementary semantics -- for  example,  the removal of Python's lists vs  tuples exceedingly  subtle  distinction. But mostly the score (as  I keep it, with  simplicity a big plus  and subtle, clever distinctions a  notable  minus) is against Ruby (e.g.,  having both closed and half-open   intervals, with the notations a..b and  a...b [anybody wants  to claim that  it's obvious which is which?-)], is  silly --  IMHO, of course!). Again,  people who consider having a lot of   similar but subtly different things at  the core of a language  a PLUS, rather  than a MINUS, will of course count  these the  other way around from how  I count them:-). Don't be misled by these comparisons  into thinking the two  languages are  very different, mind you. They aren't. But  if I'm asked to compare  capelli d'angelo to spaghettini,   after pointing out that these two  kinds of pasta are just  about  undistinguishable to anybody and  interchangeable in any  dish you might  want to prepare, I would then  inevitably have  to move into  microscopic examination of how the  lengths and  diameters imperceptibly  differ, how the ends of the strands   are tapered in one case and not in the  other, and so on -- to  try and  explain why I, personally, would  rather have capelli  d'angelo as the  pasta in any kind of broth, but would  prefer  spaghettini as the  pastasciutta to go with suitable  sauces for  such long thin pasta forms  (olive oil, minced garlic, minced  red  peppers, and finely ground anchovies,  for example - but if  you sliced the  garlic and peppers instead of mincing  them, then  you should choose the  sounder body of spaghetti rather than  the  thinner evanescence of  spaghettini, and would be well advised  to forego the achoview and add instead  some fresh spring basil  [or even --  I'm a heretic...! -- light mint...]  leaves -- at  the very last moment  before serving the dish). Ooops,  sorry,  it shows that I'm traveling  abroad and haven't had pasta for  a  while, I guess. But the analogy is  still pretty good!-) So, back to Python and Ruby, we come  to the two biggies (in  terms of  language proper -- leaving the  libraries, and other  important  ancillaries such as tools and  environments, how to  embed/extend  each language, etc, etc, out of it for  now -- they  wouldn't apply to all  IMPLEMENTATIONS of each language  anyway,  e.g., Jython vs Classic  Python being two implementations of   the Python language!): Ruby's iterators and codeblocks vs Python's iterators   and generators;Ruby's TOTAL, unbridled dynamicity, including the ability       to reopen any existing class,  including all built-in ones,   and  change its behavior at run-time -- vs  Python's vast but   bounded  dynamicity, which never changes the  behavior of   existing built-in  classes and their instances. Personally, I consider 1 a wash (the  differences are so  deep that I could  easily see people hating either  approach  and revering the other, but  on MY personal scales the pluses  and  minuses just about even up); and [2] a  crucial issue --  one that makes Ruby  much more suitable for tinkering,  BUT  Python equally more suitable for  use in large production  applications.  It's funny, in a way, because both  languages  are so MUCH more dynamic  than most others, that in the end  the  key difference between them from my  POV should hinge on  that -- that Ruby  goes to eleven in this regard (the   reference here is to Spinal Tap, of  course). In Ruby,  there are no  limits to my creativity -- if I decide  that  all string comparisons must  become case-insensitive, I CAN  DO  THAT! I.e., I can dynamically alter  the built-in string  class so that a = Hello World b = hello world if a == b   print equal!\n else   print different!\n end WILL print equal. In python, there  is NO way I can do  that. For the  purposes of metaprogramming,  implementing  experimental frameworks,  and the like, this amazing dynamic   ability of Ruby is extremely  appealing. BUT -- if we're  talking  about large applications, developed by  many people  and maintained by even  more, including all kinds of libraries  from diverse sources, and needing to  go into production in  client sites...  well, I don't WANT a language that is  QUITE  so dynamic, thank you very  much. I loathe the very idea of  some  library unwittingly breaking other  unrelated ones that  rely on those  strings being different -- that's the  kind of  deep and deeply hidden  channel, between pieces of code that  LOOK separate and SHOULD BE separate,  that spells d-e-a-t-h  in large-scale  programming. By letting any module  affect the  behavior of any other  covertly, the ability to mutate the   semantics of built-in types is just a  BAD idea for production  application  programming, just as it's cool for  tinkering. If I had to use Ruby for such a large  application, I would  try to rely on  coding-style restrictions, lots of  tests (to  be rerun whenever ANYTHING  changes -- even what should be   totally unrelated...), and the like,  to prohibit use of this  language  feature. But NOT having the feature  in the first  place is even better, in  my opinion -- just as Python itself   would be an even better language for  application programming  if a certain  number of built-ins could be nailed  down, so  I KNEW that, e.g.,  len(ciao) is 4 (rather than having  to  worry subliminally about whether  somebody's changed the  binding of  name len in the __builtins__  module...). I do  hope that  eventually Python does nail down its  built-ins. But the problem's minor, since  rebinding built-ins is quite  a  deprecated as well as a rare practice  in Python. In Ruby,  it strikes me as  major -- just like the too powerful  macro  facilities of other languages  (such as, say, Dylan) present  similar  risks in my own opinion (I do hope  that Python never  gets such a  powerful macro system, no matter the  allure of  letting people define  their own domain-specific little   languages embedded in the language  itself -- it would, IMHO,  impair  Python's wonderful usefulness for  application  programming, by  presenting an attractive nuisance to  the  would-be tinkerer who lurks in  every programmer's heart...). Alex