Ruby vs. Python comes down to the for loop (2021)

Original Article ↗ Hacker News Discussion ↗

High-level views on Ruby vs Python

  • Many say the article overstates “for loop” differences; real gaps span imports, blocks, subclassing, chaining, metaprogramming, and philosophy.
  • Some see Ruby as extremely pleasant to write and highly productive; others prefer Python for readability, ubiquity, and its role as “better Perl/BASIC” and teaching language.
  • Several argue language choice mostly affects developer happiness; both are close enough that switching is feasible.

Rails, productivity, and alternatives

  • Strong praise for Rails as the default choice for early-stage SaaS: “use Rails unless there’s a very specific reason not to.”
  • Counterpoint: many new startups, especially YC-style, seem to choose full‑stack JavaScript instead.
  • Some insist Rails performance is generally fine; bottlenecks are usually database or architecture.
  • Before writing custom apps, multiple commenters advocate WordPress, spreadsheets, or vendors—anything that avoids bespoke code—though others warn about WordPress maintenance and security, preferring static sites plus simple workflows.

Async, performance, and implementations

  • One person prefers Python specifically for asyncio; others say Ruby’s async story is comparable and avoids “function coloring,” so asyncio is not a decisive advantage.
  • Python’s performance is criticized as pushing real workloads into C/C++/Fortran extensions; hope is pinned on upcoming JIT work.
  • Ruby is acknowledged as historically slow but improving (e.g., YJIT, alternative VMs like TruffleRuby); many value developer satisfaction over raw speed.

Ecosystem gaps: GUI, NLP, data/ML

  • For GUI work, both Ruby and Python are described as mediocre; using the platform’s primary language or JS/C++‑backed toolkits is recommended.
  • Ruby GUI options like Glimmer and faster runtimes are mentioned, but not widely validated in the thread.
  • Ruby NLP libraries exist but often appear unmaintained; consensus is that Python is the stronger choice for NLP, data science, and ML.

Language design, syntax, and readability

  • Ruby: praised for “everything is an expression,” Enumerable, blocks, chainable collection methods, and Smalltalk‑inspired control flow.
  • Critiques: noisy end delimiters, complex grammar (especially around interpolation), and heavy metaprogramming that can devolve into “magical” code and technical debt.
  • Python: praised as closer to pseudocode, with indentation‑based blocks improving visual clarity.
  • Critiques: inconsistent design (e.g., global sorted() vs list .sort() returning None, free functions vs methods), clunky syntax in places, and evolving “by fashion.”

Iteration, for-loops, and collection APIs

  • Multiple Rubyists say they almost never use for; idiomatic Ruby uses each, map, select, etc., often via Enumerable after defining each.
  • Python has parallel mechanisms (yield, __iter__, collections.abc), and commenters note the article’s “Stuff” examples are unidiomatic in both languages.
  • Some propose that list comprehensions and limited lambdas in Python would have been a more meaningful contrast than for.

Typing, tooling, and maintainability

  • Python: type hints plus tools like Pyright/Pylance are seen as surprisingly effective, improving catchability of mistakes like my_list.sort() assignments.
  • Ruby: Sorbet is praised where used (e.g., for LSP support and method reference finding) but criticized for weak generics and limited adoption; many large codebases remain dynamically typed.
  • Several complain that Ruby’s dynamic features (runtime method creation, method_missing, Rails conventions) hurt grepability and newcomers’ understanding; others argue teams should restrict such patterns via linters and code review.

Numerics and beginner expectations

  • Debate around 1/2 behavior: Ruby returns 0 (integer division), Python 3 returns 0.5 (float), Python 2 used to match Ruby.
  • One side argues languages should match everyday math intuition, especially for novices and scientists; the other side defends integer division as conventional in many languages and stresses that all programmers must eventually learn about integer and floating‑point subtleties.