Rails is better low code than low code

Original Article ↗ Hacker News Discussion ↗

What “low code” means and common tools

  • Defined broadly as drag‑and‑drop / visual tools (Power Apps, Access, SSIS, Zapier, Make.com, Salesforce, FME, APEX) where most work is configuration; often with an “escape hatch” to real code (e.g., JavaScript, VBA, lambdas).
  • Some argue Excel and Access are the original and most successful low‑code platforms; also domain tools like Simulink, Houdini, game/shader node graphs.
  • Others ask for tools that generate clean, ejectable code in a mainstream language, not opaque runtimes.

Strengths and limits of low/no‑code

  • Very fast for simple internal tools, prototypes, or when non‑developers need self‑service automation.
  • Ubiquity and zero‑install friction (e.g., spreadsheets, SharePoint/PowerAutomate) are major advantages.
  • Pain points: duplication-heavy GUIs, poor refactorability, hidden complexity, weak version control, lock‑in, scaling/maintenance nightmares, and security/compliance blind spots.
  • Some see them as effective for organizations where IT can’t meet demand; others say such “shadow IT” later has to be rewritten or absorbed by central IT.

Rails vs low code (and other frameworks)

  • Many agree Rails (and similar frameworks like Django, Phoenix, Elixir, ASP.NET) already feel “low code” due to scaffolding, conventions, batteries‑included features, and rich ecosystems.
  • Rails praised for: rapid greenfield CRUD development, predictable structure, easy onboarding, and Ruby’s metaprogramming/monkey‑patching for extension.
  • Critiques: long‑lived large Rails apps can devolve into tightly coupled “big balls of mud,” especially with fat models and heavy magic; refactoring and upgrades can be risky.

Static vs dynamic typing and LLMs

  • Strong disagreement over dynamic languages (Ruby, Python, JS) vs statically typed ones (C#, Rust, Kotlin, TypeScript, etc.).
  • Pro‑static camp: static types catch LLM hallucinations and library breakages earlier; dynamic ecosystems can hide breaking changes until production.
  • Pro‑dynamic camp: tests plus flexibility suffice; Ruby’s dynamism simplifies testing and monkey‑patching; static typing can feel like unnecessary drag.
  • Some argue LLM‑assisted coding reduces the appeal of low‑code, and may favor languages/models with strong type information and good training coverage.

Broader perspectives

  • Several note that low‑code/RAD ideas (4GLs, VB, Delphi, Access) have cycled for decades; the underlying complexity never disappears.
  • Consensus: right tool depends on who builds/maintains it, expected lifetime, complexity, and organizational constraints; knowing when to stop using low‑code and rewrite is crucial.