Ruby Sucks Because, My two Cents

While reading about my beloved Ruby on Your Language Sucks I had a deep urge to analyze each point as to me most of the points seemed fillers.

IMHO you shouldn't say "Ruby Sucks" while talking about 5 or even 7 versions older Ruby, you should probably say "Ruby used to suck". So in my analysis i'll just omit talking about those points as it's pointless?

Ruby sucks because

• String#downcase? Who calls it "downcase?" It's called "lower case," and the method should be called "lowercase" or "lower". And String#upcase should have been called "uppercase" or "upper". It does not actually make Ruby suck, it's just a matter of personal taste. Still a better story than tw... PHP.
  
  Yep, this fooled me too, only first time, but what's wrong in using a synonym for lowercase? It's be better not to as most languages have lowercase, but yeah you agreed it's just a matter of personal
• Unicode support should have been built in from 1.0, not added after much complaining in 1.9/2.0 in 2007
  
• No support for negative / positive look-behind in regular expressions in 1.8
  
• Regular expressions are always in multi-line mode
  
  Quoting from: http://ruby-doc.org/core-2.5.0/Regexp.html
  "/./m - Any character (the m modifier enables multiline mode)"
  
• (No longer true since Ruby 2.0!) No real support for arbitrary keyword arguments (key=value pairs in function definitions are positional arguments with default values).
  
• Using @ and @@ to access instance and class members can be unclear at a glance.
  
  Only first day of your programming in Ruby. Unless of course you occasionally have to look at some Ruby code but never work in it, but yeah, try occasionally understanding any other language's code and you'd thank whenever it's Ruby.
• There are no smart and carefully planned changes that can't break compatibility; even minor releases can break compatibility: See "Compatibility issues" and "fileutils". This leads to multiple recommended stable versions: both 1.8.7 and 1.9.1 for Windows. Which one to use?
  Referencing links from Ruby version 1.8.7, released  31 May 2008; 10 Freaking years ago
• Experimental and (known to be) buggy features are added to the production and "stable" releases: See "passing a block to a Proc".
  In Ruby version 1.8.7 released  31 May 2008; 10 Freaking years ago
• The documentation is unchecked: it has dead links, like Things Any Newcomer Should Know
  What's Ruby Garden? is it official Ruby website? I never found a deadlink in my 5+ years of Ruby professional experience.
• There's some minor gotchas. nil.to_i turns nil into 0, but 0 does not evaluate as nil. nil.to_i.nil? #=> false
  
  Yep, this is indeed a minor gotcha
• String#to_i just ignores trailing characters, meaning: "x".to_i == 0
  Yep, this is indeed another gotcha
• Ruby allows users to modify the built in classes, which can be useful, but limited namespace means addons can conflict. Experienced programmers know to add functionality through modules rather than monkey patching the built in classes, but is still prone to abuse. This has been resolved in ruby 2.0
  
• Aliased methods in the standard library make reading code written by others more confusing, if one is not yet well familiar with basic stuff. E.g. Array#size/Array#length, Array#[]/Array#slice
  Debatable.
• Mutable types like arrays are still hashable. This can cause a hash to contain the same key twice, and return a random value (the first?) when accessing the key.
  
  Valid concern.
• Omitting parenthesis in function calls enable you to implement/simulate property setter, but can lead to ambiguities.
  
  Valid concern, but when you see trade offs I think it's for the better. 
• Minor ambiguities between the hash syntax and blocks (closures), when using curly braces for both.
  
  Valid Concern.
• Suffix-conditions after whole blocks of code, e.g. begin ... rescue ... end if expr. You are guaranteed to miss the if expr if there are a lot of lines in the code block.
  
  Not really.
• The unless keyword (acts like if not) tends to make the code harder to comprehend instead of easier, for some people.
  
  Yep, it takes a bit of practice to gulp it without critical thinking.
• Difference between unqualified method calls and access of local variables is not obvious. This is especially bad in a language that does not require you to declare local variables and where you can access them without error before you first assign them.
  
  True.
• "Value-leaking" functions. The value of the last expression in an function is implicitly the return value. You need to explicitly write nil if you want to make your function "void" (a procedure). Like if you really care about that return value.
  
  It's a design choice and the pros far outweigh the cons.
• pre-1.9: No way to get stdout, stderr and the exit code (all of them at once) of a sub process.
  
• `` syntax with string interpolation for running sub processes. This makes shell injection attacks easy.
  
  The liability is on the programmer in this one, IMO.
• Regular expressions magically assign variables: $1, $2, ...
  
  And?
• Standard containers (Array, Hash) have a very big interfaces that make them hard to emulate. So don't emulate - inherit instead. class ThingLikeArray < Array; end
  True.
• Symbols and strings are both allowed and often used as keys in hashes, but "foo" != :foo, which led to inventions like HashWithIndifferentAccess.
  
  This is indeed my biggest gripe with Ruby. It has landed me into pitfall many a times, specially working with other APIs and API wrapper Gems. Hashes should be indifferent by default or just allow symbols as keys.
• Parser errors could be more clear. "syntax error, unexpected kEND, expecting $end" actually means "syntax error, unexpected keyword 'end', expecting end of input"
  
  Really? is this error that hard for a programmer to decipher? 
• Symbols are unequal if their encoded bytes are unequal even if they represent the same strings.
  
  Indeed a big flaw.