11 ms·

Today I accept that Rails is yesterday’s software

197 points by zimbu668 10y ago

mooreds 10y ago
So, Rails has warts. What system that is used to build real world software doesn't? I've built systems in a number of languages and frameworks and they all had warts and issues. How much research has the author done to find other solutions? The plea at the end seemed very lazywebish to me. Or maybe ghost of Christmas Future-esque?
rahimnathwani 10y ago
The article seems to be lamenting three things: 1) Batteries-included web frameworks (like Rails and Django) 2) Interpreted languages without strict typing (like Ruby and Python) 3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you want to write web software you can reason about, you can still use web frameworks (maybe Flask or Sinatra) and you can still use third party packages (gems or things from pypi). If you import a library (left pad or whatever) and call it from your code, then you can still reason about what's going on. The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running.
- vosper 10y ago
  > The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running I think this is where the lack of strict typing can make things harder to figure out. Especially if you're trying to understand middleware functions with opaque signatures (like kwargs in Python). IDEs like PyCharm do their best at providing "Find all references", "Go to defintion" etc, and that helps, but it's not quite the same. Putting the info in the docstring is better than nothing, but it's still harder to parse (and maybe not machine parseable) and who knows if it's really correct? Personally I'm really hoping mypy or type-hinting really takes off in Python 3, and makes everyone's life easier.
  - elcapitan 10y ago
    But is that really a problem of non-strict typing, or rather a problem of metaprogramming? I could imagine even a very strongly typed system in Haskell or Scala would probably be hard for an IDE to support if it uses a lot of complex abstractions to create internal DSLs (like Rails and I guess Django as well do).
    - geofft 10y ago
      IDEs can typically query a strongly-typed language for useful information without actually running the code. As long as the DSL uses static types, the IDE can just ask the compiler / type-checker to tell it what's going on and what portions of the source contribute to that meaning. This is where the fuzziness of the phrase "strongly typed" becomes a bit of a problem, but the fundamental idea is that there are two levels of meaning in the program, one static, and one dynamic, and the static level produces useful info. There are lots of levels this can take. The most common is in an IDE for a language like C or Python; it compiles or style-checks the file, warning you about issues, but it doesn't have any sense of what the program means. Another very common one is where you have non-code configuration files for GUI layout. You usually don't need a Turing-complete language to describe your GUI, so putting it in some other format like XML means the IDE can render the GUI and let you make changes to it without having to actually run your code. Strong typing for DSLs is just another example of the same sort of thing. If you're able to e.g. describe your models to the ORM entirely statically, it can figure out what a ton of your code means without running any of it. I think this is basically what you mean by metaprogramming, except with the constraint that one of the two languages is pure and Turing-incomplete and doesn't rely on external input. Then the IDE can safely run that language.
    - vosper 10y ago
      I can't speak for Rails, but at least with Python (primarily Flask) it's not internal DSLs that have caused me problems. I don't think Flask attempts to be a DSL at all, actually. From what little I've seen of Django it isn't trying to be a DSL either (unless I'm misunderstanding that term). It's more when I have 2 or 3 Flask libraries or middleware and they each are documented as if they exist in a vacuum but I want to use them all together and I wish it was easier to see that all 3 have functions that take a Flask Blueprint object, so they're probably all related, or that these functions work with URL objects, etc... It's a general complaint about Python and the tooling I suppose, not specific to web application frameworks.
- bluedino 10y ago
  >> 3) Programmers relying on large numbers of dependencies (e.g. ruby gems) So many gems are either not written well, or not maintained well. How many times have you seen the case where you update gem to fix a bug, and then cause two more? It's not Rails or Ruby's fault, it's the community.
  - astrodust 10y ago
    Ruby's got a lot of software that's been produced over the years, and one of the risks here is that people burn out on projects and move on. A slow accumulation of dangerous deadwood occurs over time and unless people work to clear the brush it can be catastrophic when problems strike. Consider: ImageMagick and OpenSSL. Newer platforms haven't had this problem because they've already broken all their old software (Rust) or because they're still changing rapidly enough that new software is still emerging (Swift). It's not the community's fault. It's that it gets harder and harder to keep things clean the longer your language has been around.
    - askyourmother 10y ago
      Ruby gems in particular host a lot of abandonware and basically little turds that entice "I read pragprog, watch screencasts, and am now leet Rails dev!" Folks into using them with the promise of easy Lego style coding. It never ends well.
      - astrodust 10y ago
        Do you have a scat fetish? What is it with you and turds? People get hyped about any language the same way. How many Erlang "experts" or Node.js "ninjas" are there out there? Give it a rest. If people want to get excited about something don't shit all over them.
        caconym_ 10y ago
        > Do you have a scat fetish? What is it with you and turds? Right about now is when you should go ahead and read his username, ideally out loud in your best Sean Connery voice.
- hellofunk 10y ago
  All 3 of those lamentations could also apply to Clojure, but I don't think anyone who used Clojure would lament it.
  - smrtinsert 10y ago
    Yes they would. The rumblings of clojure and the dynamic language trap are already out there.
    - hellofunk 10y ago
      Haven't heard them myself and I'm quite involved with the community. Some disappointments about core.typed not being what some would have liked, but other than that...
- mirekrusin 10y ago
  Assembler solves all 3 of those problems, right?
- outworlder 10y ago
  > The last paragraph then goes on to suggest that different languages are required. This seems wrong. I feel that the programming languages are being used here as proxy for something else: the community surrounding them.
cplanas 10y ago
I agree with some of the issues that the author points in Rails; but, at the same time, he is unable to name what is "today's software" using his words. Until then, I will stay with Rails. Until then. Moreover, the author seems to be imagining Rails as a huge monolithic piece of software. That does not need to be true.
- jmstickney 10y ago
  Doesn't the author end by saying Swift, Rust and Go are "tomorrow's languages"?
  - collyw 10y ago
    Yet he gives absolutely no justification for why those are "tomorrows languages". You don't use third party libraries or frameworks in any of those languages? Personally I design my Django code to be as simple as possible. I use third party libraries, and don't see too many of the problems he talks about.
    - nicops 10y ago
      Probably because the author doesn't use them and thus has no idea of what their problems are, so they seem "perfect" from a distance.
  - cplanas 10y ago
    That's the issue: he calls them tomorrow's languages, implying that they need to change ("can you marry modern thinking, build a community [...]) before getting there, or being "today's languages". So far, I still haven't seen anything better than Rails to solve yesterday's (and today's) problems.
calcsam 10y ago
Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity. https://speakerdeck.com/tehviking/surviving-the-framework-hype-cycle https://speakerdeck.com/tehviking/surviving-the-framework-hy...
- mooreds 10y ago
  Thank you, that was a wonderful slide deck.
  - dopamean 10y ago
    Brandon is a really awesome guy. His talks are always funny and informative.
    - brhays 10y ago
      I don't often visit Hacker News, but when I do, it's to receive compliments. But srsly, thank you, that's very kind to say.
- astrodust 10y ago
  Nails it. There's nothing shameful in using a "boring, not cool" platform to get work done. The pioneer lifestyle is full of risks. Sometimes you want that excitement, other times you have different priorities.
  - maaku 10y ago
    Sometimes you want to read the article.
    - astrodust 10y ago
      I did. It was full of shit. These are the ramblings of someone who's never worked with a mature framework where, as always, there will be lots of legacy stuff laying around just begging to be fixed. But no, fixing stuff is hard. Let's write bitchy blog posts and blame everyone else.
tangue 10y ago
I was dubious when I saw the Medium.com tld and a clickbaity title but it actually puts word on what I feel after 16 (ouch) years of web development. The difference was that I was blaming the tools and screaming "#fail" with the other rather than thinking like the author that we're in a conceptual dead-end (at least with popular tools).
mml 10y ago
While it's true that Rails is sinking under the weight of its own cleverness, and is clearly the old hotness, this has nothing to do with Ruby the language. Rails' problems are its own, and Ruby's limitations and problem domain are well known. This is a terrible blog post by someone without much perspective. I award it no stars.
- MaxfordAndSons 10y ago
  The author of the post at no point blames Ruby for Rails' failings... But also I'd contest your argument that they're unrelated. Ruby is what enables the too-clever metaprog that make Rails stack traces so opaque. Also Rails has almost certainly been the single largest drive of Ruby's growth and popularity - observe the significant overlap of core contributors to both projects.
polysaturate 10y ago
I…don’t understand the point of the article? Ok Ruby is duck typed and has a dynamic runtime. It has for…all of the time since it was created. Rails has magic… since…all of the time since it was created. I’m not even defending Ruby or Rails here. Use at your own benefit/risk…as with every other programming language and framework.
- crdoconnor 10y ago
  The emphasis on magic was a particularly bad decision. It looked wonderful in the original screencasts that let you build a webapp in 5 minutes. It causes terrible pain when you're trying to do something complicated. This was one of the mistakes Django made and - to their credit - got over relatively quickly. It began as a kind of imitation of Rails but they stripped out the magic pretty quickly and made it a lot more explicit.
- VLM 10y ago
  Its the culture. My first RoR application a decade ago had basically no dependencies. The medium article implies the cool kids won't build an app unless it has enough dependencies to be unmaintainable and undeployable. So either you can't use the cool kids or you can't use the tool, the combo is no longer sustainable, its just done. The high time preference people will insist you install GEMs until the crash, its a technological bubble of sorts. Also my first CRUD app was very small and boring. That means un-debuggable isn't a big deal. Now apps are huge, therefore undebuggable. Even if you limit external dependencies that doesn't help internal dependencies. You can prototype things quickly, as long as they're small, featureless, no one uses them, and you don't care how difficult the are to deploy or debug. Other than that, no problem. Hmm.
elcapitan 10y ago
While I agree with many of the individual points he makes (rails dev myself), I think there is a kind of fundamental issue there that we have seen with most web framework/language combinations and will see with future ones, and that is that they usually come to life when one concept or idea they embody the best (for example mvc for crud apps with Rails, frontend/backend unification with node, native concurrency with Erlang, puristic http for microservices with Go) is becoming prevalent at some point, and then people put stuff on top of stuff which they put on top of other stuff, and then they realize that the problem they still have to solve is good architecture. And they need to balance that with business needs and developer availability. I don't think any of that is going to change by switching to the next fashionable concept to base a web app on.
askyourmother 10y ago
I remember early Rails, around 0.13, pre RC, the community was small the future seemed bright. Little did we know the horrors of what it would turn into. Most of the professional people left when they saw the security circus, the endless holes and design flaws. I learnt then - avoid any web framework which has pragprog pushing a book behind it. The new one to avoid because the masses are already circling around it is 'phoenix', and sure enough, pragprog is hawking a book on it.
- astrodust 10y ago
  That's a pretty shitty attitude to have. What framework is sufficiently irrelevant that Pragmatic Press or O'Reilly can't be bothered to write a book about it?
  - askyourmother 10y ago
    Actually O'Reilly published a good book on Rails in the early days 'enterprise rails', which was a very well written book. The pragprog web books seem to be a bell weather, the shiny web crowd flowed into Rails, node and soon probably phoenix. The early start and promise and phoenix will soon sink under the weight once hex packages bloat in number like the festering turds within ruby gems.
    - carsonreinke 10y ago
      You are really pushing the turd argument [https://news.ycombinator.com/item?id=11661834 https://news.ycombinator.com/item?id=11661834]
    - astrodust 10y ago
      Rejecting a platform just because a publisher has written a book about it is like turning down a job because your astrologer said it was a bad fit. You sound out of your mind. Please try and make a rational argument.
- dimgl 10y ago
  Silly way to think in my opinion. Elixir has made me super productive, regardless of a Dave Thomas book existing for it.
gsmethells 10y ago
Know your dependencies well. Keep them few and far between -- and well vetted.
draw_down 10y ago
Everyone who uses software older than your preferred framework is an out-of-touch fuddy duddy, and everyone who uses software newer than your preferred framework is a clueless hipster.
icpmacdo 10y ago
I am thinking about completely stopping reading Hacker News. I enjoy the community a lot but every time I am learning something new I read about how its old and shitty and will cause hair loss when you try and invest any time in it. It puts the breaks on actually learning with the distraction of going and trying to find that new ambiguous stack that the author is hinting at.
- askyourmother 10y ago
  If you learn a library, you will always be in the driving seat. If you learn a framework, well, better buckle up, because it is a bumpy ride. Frameworks are like hamburgers at maccy ds - consumption for the masses, no thinking required. Later in life those decisions can be a problem.
  - petepete 10y ago
    Given the choice between hand-rearing cattle and growing wheat versus buying a ready-made burger, well, it depends on whether you want to eat slightly less well, sooner or slightly better, later.
  - meekins 10y ago
    It's exactly the attitude you describe what gets people into trouble with frameworks. Getting up and running and building things on a huge foundation like Rails is easy but you should also act responsibly and take the extra steps required to understand what's going under the hood. The effort of understanding a set of well defined "small" libraries is less daunting than a whole monolithic framework (probably with tons of bells and whistles you rarely even use) but both approaches (compare for example the style of the Clojure web app community vs Rails) have their benefits. A set of libs can be adapted more easily to specific needs and development of each of the individual dependencies can move fast without worrying about the others. On the other hand Rails changes relatively slowly but each Rails app being just another Rails app with all the pieces where you expect them to be can be considered a big plus in maintenance.
- scj 10y ago
  Wouldn't you rather be told upfront what a tool's flaws are before you invest years of effort into them? Even if you decide to embrace a tool despite flaws, isn't it best to recognize / minimize them? For example, C is a great tool. But heaven help someone if they ignore its' sharp edges. There is no silver bullet. So the best you can do is find something that suits you, and the task(s) you are trying to accomplish.
scolfax 10y ago
Don't blame your tools for an over-engineered project.
zippergz 10y ago
Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.
- disease 10y ago
  Scala and c#. Great tooling, static typing, functional and OO paradigms covered, fast (Scala runs fast once complied), flexible with tons of existing code already out there to be used or learned from.
- emodendroket 10y ago
  I have no complaints about C# and Webapi. Well, "no complaints" isn't exactly right but I like it.
- spinlock 10y ago
  Pheonix looks promising. It's basically Erlang on Rails.
  - bobwaycott 10y ago
    Or Rails on Erlang (even though I see what you did there).
- crdoconnor 10y ago
  Django has always been relatively pleasant for me to develop in. Flask has been okay too. I almost learned Rails in 2007 when it was at the peak of its hype cycle but after reading a series of (not very well publicized) tirades about pain that Rails' magic caused I learned Django instead. I think node is at the peak of its hype cycle right now.
- sotojuan 10y ago
  Elixir's Phoenix: https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails
bluedino 10y ago
The question is where do you go from here if you're a Rails shop? The last place I worked had 80% of their products running Rails 2 and 20% of them running on Rails 3. No product was ever both completed AND caught traction since. Do you stick with Rails 5 for the next project? Do you meander over to Python or Node?
- askyourmother 10y ago
  Where from Rails? Anywhere looks better - personally, our firm uses falcon on python and lightweight Go web services with native std libs, and it works very well.
- sotojuan 10y ago
  Dockyard, a Rails agency, is moving to Phoenix I think.
omarforgotpwd 10y ago
1. The first software wave was system level software. Developers wanted something but made their lives easier, but also wanted control and speed. C and then Java were the stars 2. In the second wave, we got languages like Ruby and Python which are flexible and easy for developers to work with. Sometimes it's more important to be able to iterate quickly than execute quickly. Server software, app backends, etc were all implemented in whatever language was easiest using HTTP as an interchange with other languages 3. In the third wave, developer experience enhancements that scripting languages pioneered trickled down to systems programming with new languages like Swift and Go. These give you most of the benefits of the second wave languages without their significant overhead. Since they are better suited to building small light services, old bulky Ruby / Rails app are starting to look antiquated pretty quickly. I also used to go to Rails first for web projects... I use Go now because it's more lightweight. I used to do native apps in Objective-C... I now use Swift because it's easier to write.
tootie 10y ago
Just use Java people. You can bootstrap a Spring project in 10 minutes and it will have every feature (ORM, security, caching, MVC) available with just a maven dependency or you can roll your own and it will work fine. Strong typing, good performance, sensible stack traces (if you don't overdo annotations) and all the testing and monitoring tools you could ever dream of.
- markbnj 10y ago
  And namespaces like com.me.mine.whatever.toolong.to.type, and checked exceptions, and Oracle.
- humbleMouse 10y ago
  This comment is what I feel like replying with to every article about some "fast iterating" language. IMO the only reason to use rails if you don't actually understand how web development actually works. Why would you pick a slower language and platform like ruby/rails when java/spring is right there available to anyone?
  - olavgg 10y ago
    And Grails is very similar to Rails, and you get the full power of the JVM/Spring technology stack. And Groovy is a fantastic language that gives you the flexibility everyone like to dream about.
    - humbleMouse 10y ago
      Groovy is amazing. It's like javascript and Java had a beautiful baby that lets you compile either dynamically or statically.
      - vorg 10y ago
        The static compilation doesn't quite work properly. Groovy is good for scripting though, similar to the way Bash is used in Linux, so test your Java classes with it, or use it as a DSL in Gradle builds. For building systems on the JVM, use a language designed for that purpose from the ground up, e.g. Java, Scala, or Kotlin.
deleted 10y ago
[deleted]
tomc1985 10y ago
Well, the situations with coffeescript exceptions and exceptions-from-the-depths-of-hell are avoidable (hint: don't use coffeescript)... indeed Rails makes it easy but just because crazy amounts of gems are on offer doesn't mean one has to use them. Ruby/Rails certainly has its quirks, and while Rails certainly does seem to be taking on more and more unnecessary dependencies, some are still plenty productive in day-to-day Rails. A lot of pain avoidance in Rails is following its opinions up-and-until it takes you further than you need to go
hartator 10y ago
Rails seems to become bloated for sure, but I think there is not a no brainer alternative out there. When I first switched from PHP to Rails it was a natural choice whereas i don't feel Rails to Node.js is in its current state.
- max_ 10y ago
  i wish someone could say the same for bootstrap
mattmcknight 10y ago
A couple of things seem off on this perspective, mostly that modern web development has gotten weird, irrespective of Rails. "The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple." First, I found Rails simple and easy, but it has become more complex over time as it has grown to support a variety of uses. The simplicity is not just because of Ruby, which is a low ceremony language, but rather because of the simple structure of the application, with a clear separation of concerns, very easy to find where a particular code item went. "The meta-programming and object injection that makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug. " Dependency oriented development is a real problem, but it is insane to blame that on Ruby. I was working with an enterprise Java team last year that had over 1000 .jars in their build. It doesn't necessarily make it hard to debug, but it does mean you have understand a wide variety of different libraries. People are willing to load a library for the simplest of functions (as the leftpad npm case showed). Again, nothing to do with Rails or Ruby in particular. "The magic of active record, the crazy levels of duck typing and the expressiveness of ruby, are exactly why it runs poorly even on your development box." This is highly dubious- it's very fast on my dev box. The Ruby interpreter keeps getting better, even taking lessons from V8, and you can compile to JRuby if you think that interpreted runtimes aren't ever going to keep up. "It’s why you have to build a caching strategy in as a requirement from first line of code." This seems like a good strategy regardless, and caching is nicely handled in Rails. "Competitors to Rails seemed subject to the same problem — basing themselves on interpreted, slow languages that favoured ‘easy to learn’ over ‘easy to maintain’." As opposed to compiled, fast languages like C++ that are hard to learn and hard to maintain? If anything, duck typing makes maintenance lot easier in some cases, where you can add in new types which support existing behavior, without making changes throughout the dependency tree. Even some 8 year old Rails apps we have are quite maintainable. JavaScript code does have a tendency towards messiness, as there are such a variety of schemes for organizing code, but it keeps getting better. "I should be spending time writing code, not debugging a haystack of mutable, dependency-wired mess." This is your choice! I think it's nice to have toolsets that give people the ability to assemble things quickly, but no one is forcing you to use a gem to do something. "Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself?" This seems like barking up the wrong tree. The thing making web development complex is largely the complexity of the front end. You can turn your back-end application into a separate API and isolate this problem. At some point, these become browser capabilities, and the polyfill approach has promise. (http://bitworking.org/news/2014/05/zero_framework_manifesto http://bitworking.org/news/2014/05/zero_framework_manifesto) In reality none of the stuff mentioned in this article is really a shortcoming of Rails as compared to anything else. The biggest change is the move away from the basic nature of REST-ful, URL driven applications. Single page apps are a lot more like desktop applications. Many applications are looking for web sockets. These changes to the basic structure of what a web application is are much more of a challenge to Rails than the Ruby language itself.
emodendroket 10y ago
Yeah, yeah. Nothing is going to magically solve all your problems; I don't necessarily think that means we need to go back to hand-rolling everything.
miloshadzic 10y ago
It's today's software which -- being almost a synonym for enterprise software -- can be a problem for a culture built on it's difference from Enterprise Java.
aaronwidd 10y ago
It's not Rails. Web software development in general has simply plateaued across the board. We're out of new frontiers to innovate around and the work from now on is about playing custodian to the innovations of the past. Unless something spectacularly interesting comes along, the priorities of the web are now all about supporting what's already been built. Either by maintaining something hastily built and cracking at the seams with patches and fresh coats of paint - or replacing it with something more stable for the long haul. Rails was designed around rapid innovation, not the long haul. So it's in maintenance mode.
- sotojuan 10y ago
  What about stuff like Elixir? Not innovative but it's interesting to explore the applications of Erlang's VM (fault tolerance, high availability, the concurrency model, stuff like supervision trees) to web applications.
- smrtinsert 10y ago
  We finished the web guys, you heard it here first on hacker news.
hardwaresofton 10y ago
For those that are feeling fatigued from working with and around the magic of Rails, Sinatra is a great choice (in python land Django has an alternative called Flask). http://www.sinatrarb.com/ http://www.sinatrarb.com/ That said, you will have to re-implement machinery that rails gave you for free. If you're building a simple API, there will be obvious simplicity benefits. If you're trying to build a server-side rendered web application, you may long for some things that rails provided (of course, you can use libraries and create simpler patterns than rails provided). Note that going the sinatra+libs (or any "micro" framework for that matter) route places a higher burden on the development team when it comes to documentation. If you implement a scheme for server side templating/rendering outside of what is provided, you will be in a world of pain in a relatively short time if you do not maintain good documentation.
- bphogan 10y ago
  You will indeed have to re-implement stuff Rails gives you. But more importantly, you will have to maintain it. I maintain a large-ish Sinatra app that should've been done with Rails. Update cycles on the gems are a nightmare. It feels cobbled together. it's a "half baked homegrown version of Rails." Someday I will just move the logic to a new Rails app and be done with it. It was a terrible idea. * your experience may vary. :)
  - elliotec 10y ago
    My experience was exactly the same. Sinatra is for super tiny things. Rails is for most things.
  - tchow 10y ago
    What is a large-ish app? Just for comparison's sake? What makes it large-ish? The number of tables? The number of views? What is the problem that large-ish apps give that Rails solves? Genuine questions, I only do small projects and I honestly don't see a huge benefit to using rails, despite having used it before.
  - hkarthik 10y ago
    Any sufficiently complicated Sinatra app contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Rails.
avitzurel 10y ago
Today I learned that not everything you read on Medium is true and should be considered anecdotal and smart.
tunesmith 10y ago
I've been doing enterprise backend development (java/spring, scala, akka) for a while and occasionally miss the practice of sitting down and creating a fullstack app myself, which I used to do with php and crappy html. But then I sit down and try to work with existing Ruby/Rails codebases and hit a mental block. I guess example #1 is method_missing. I get it, it's a huge time-saver and lets you do all kinds of cool things like specify a default behavior for an API if someone sends a random command, or, define the behavior of a method dynamically by the name of the phantom method. But then the rest of me is reflexively saying, "Seriously??" And I get that Spring Data does sort of the same thing, but at least there it's limited by domain. If I'm in a Ruby codebase that is taking regular advantage of that, my first instinct would be find calls that eventually go to method_missing, and then just define the damn method somewhere so that my IDE's "Find Usage" will work again. How the heck do you explore a codebase quickly if your IDE doesn't work? I guess for me it just reinforces the same rules of thumb. Dynamic languages are fine if you're prototyping or doing an MVP. But as soon as you find that your codebase is being read/maintained more often than it's being written (which will happen sooner than you think), or as soon as you start finding weird production runtime bugs that don't happen in your local environment, you're better off with something strong or static or compiled. As for how to get that safety full-stack these days, I'm still poking around. Scalajs seems interesting, or Angular2 with Typescript, or something that uses RxJs...
- abc_lisper 10y ago
  How about writing tests that enforce invariants? I have been doing clojure dev for a little bit, and here's what I do - - Run tests in the background continuously (lein expectations will give you that. or you can write your own shell script) - Do small checkins, frequently to git - Write tests that enforce invariants. Haven't gotten to test check yet - but I guess that would be even better. The trouble with types is they push you into a corner early, and after a while people will be coding to zombie constraints - the constraints that were there before, but not true anymore. They are also verbose, and need tooling to get you out of the corner. If the requirements change a little bit, it could be that, your old solution goes against the grain of the new problem, which is very hard to get rid of without rewriting the code. With dynamic languages, I find that I think more about the problem, than trying to do constraint satisfaction with other entities in the code, not to mention the language itself.
pbowyer 10y ago
Previously posted at https://news.ycombinator.com/item?id=11658356 https://news.ycombinator.com/item?id=11658356, with great comments
hgh 10y ago
From Stroustrup of C++ fame: There are only two kinds of languages [frameworks]: the ones people complain about and the ones nobody uses.
- uptownJimmy 10y ago
  I think Rails might be a framework that nobody complains about, in the mid-term future. It is showing signs of age. And, though I say this with strong respect in my heart, the Rails governance is as opinionated and inflexible as the framework itself.
mnarayan01 10y ago
There's certainly a lot of truth in this (I especially like the duck-typing image), but the example feels like it throws it all away. You can, after all, have a _super_ fast and simple asset pipeline by keeping things...simple (to say nothing of skipping it entirely); having CoffeeScript compiling to JavaScript is not really relevant to either Ruby or Rails.
spriggan3 10y ago
> Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself? Go is great for plumbing, you can get network utilities up and running pretty fast with no dependencies so it's easy to deploy, that's its niche. Now try writing a complex eCommerce website, a news site, or any large app backed by a complex data model in Go... I started to use Asp.net CORE on Linux with Postgres the other day and frankly, I don't want to hear about Go and its "simple" type system anymore when I can just use C# and do projects in minutes without fighting the language. Go is at at most a safe C with channels (without macros which make it worse than C in term of features). My point is neither Swift,Rust or Go are silver bullets which will fit every use cases in Web Development. Neither is asp.net core,but for my use case there is no debate as to what I should be using. Rust,Go and Swift aren't tomorrow languages. They are languages that fit a specific use case like every other language.
lmm 10y ago
I've been using Scala for 5+ years now, so for me it's definitely today's software. Spray for REST backends, Wicket for HTML UIs. Clean syntax that can be as expressive as Python or Ruby, but coupled to a type system more powerful and effective than any of Swift, Rust or Go, light enough that you can lift things that had to be "magic" (like database-session-in-view) right up there into the type system.
tankerdude 10y ago
So my question would be, what's the difference between Rails and other frameworks, especially since we are doing RESTful APIs from the start? It would seem to me that Rails is just not the tool to use going forward for writing APIs for websites at scale. There are much better tools out there. Rails' sweet spot is server side rendered pages that are quick to bring up and to add features. It seems great for certain types of websites so it does have its niche. But moving forward, Rails for API vs. other frameworks in other languages is really a wash in terms of productivity, while other frameworks in those other languages are much more highly performant.
btilly 10y ago
The problem comes from this. 1. The costs of any layer of abstraction and magic that we have internalized seem free to us. So we feel free to add a more marginal one. 2. We have little visibility into any layer of the stack above or below ours. 3. As people migrate between languages, they take what they did previously and recreate it. Only "better". As a result, complexity grows over time. And programmers are really bad at noticing/correcting it. And when they try, they will come up with different prescriptions. Often opposing ones. Explicit is good. (Go.) Don't let people mutate state. (Functional languages.) Convention over configuration. (Rails.) Move work from programmers to IDEs and tooling. (Java.) Make programmers productive so more gets done with less code. (Most scripting languages from Perl on.) Over my lifetime, I've watched the resulting slide into complexity. Reading up on history I recognize that it had been going on for decades before I learned how to program. And it shows every sign of continuing to accelerate going forward.
cryptos 10y ago
I had similar experience with Grails. Discovering Grails and seeing how fast the first version of the application is up and running was fascinating. But sooner or later almost all generated code has to be replaced. It's not bad for the first iterations, but no time save in the long run. But the Grails magic was really awful! It cost so much time to find all the hairy bugs (in my own code or in Grails itself). Finally I stopped using Grails. I perfer static typed languages now (not only because of Grails and Groovy). And I prefer to compose some specialized frameworks. For example JAX-RS (Jersey) is a very good REST framework. There is no need to force the user to use it with a certain ORM (if at all), a certain way to validate objects and so on. Just take what fit's best. Java is not the most elegant or productive language but there are other static typed JVM languages like Kotlin or Scala. To come back to the article: I don't think that we need new languages, but another way to use existing frameworks and maybe statically typed languages.
smrtinsert 10y ago
I'm always tickled by the mythology that was sold thanks to a macbook and a textmate theme - that creativity is inherent to it, and that it is a pioneers tool, for craftmenship etc. That might all matter if the first thing people did once deploying it was to port off of it. For software that has such a rapid expiration date, none of it selling points matter. You might as well have written it in php or perl. Rails continues to be a favorite joke of mine.
SeanDav 10y ago
So if Ruby and Python frameworks are not suitable web development platforms - what is? The OP gives no alternatives, just a long rant about the problems of web development with dynamic languages.
heyts 10y ago
While I hear the argument, I'm tempted to think that the framework is largely irrelevant and that it actually is the ecosystem (package management and lack of quality control) that is harming platforms at large from Rails to Django to, obviously, node. I was very interested to hear of Elm enforcing Semver at the package manager level and I believe that this is a step in the right direction.
gjvc 10y ago
Web development techniques are crying out for an "emperor's new clothes" moment. Approaches like GWT (+ a toolkit such as GXT) seem to be a far saner approach for many enterprise applications. On the other hand, there are large classes of problems for which Rails / Django / et al have shown good results. Vive la difference!
MrBra 10y ago
If Rails, as of now, would've been a very fast framework, the post author would have never published such post, despite all the other "defects" he underpins. Rails could eventually get very fast, but it can be frustrating that it's not right now! This is the same kind of problem of Ruby not having a proper x-platform GUI toolkit or binary packager: you have such a expressive and powerful language and still you feel you are limited by the lack of speed and tooling. That's why, IMO, a Ruby/Rails dev frustration can explode in such a strong way at some point. Sadly Ruby isn't backed by a big corporation, so you can only wait for the language and frameworks to get more mature. Personally I've dealt with this frustration by learning C#. It allowed me to overcome all the current limits of Ruby, while avoiding the Java ShitFactory. At the same it feels great to get back to Ruby when you want to explore ideas! It's still an unbeatable tool for prototyping. Being aware that I have knowledge of another language, makes me feel better, less frustrated, and I browse Ruby weekly news with much less "anxiety" for a revolutionary Ruby improvement (but still I browse it because I know it will happen sooner or later!). I'm quite sure that the OP after having vented with this post, and having found what for him is a solution, then he will peacefully embrace Ruby or Rails again under a different light (but again, I wouldn't be so surprises to see big improvements soon, so maybe it could even be a better light!)

197 points by zimbu668 10y ago

So, Rails has warts. What system that is used to build real world software doesn't? I've built systems in a number of languages and frameworks and they all had warts and issues. How much research has the author done to find other solutions? The plea at the end seemed very lazywebish to me. Or maybe ghost of Christmas Future-esque?

rahimnathwani 10y ago

The article seems to be lamenting three things: 1) Batteries-included web frameworks (like Rails and Django) 2) Interpreted languages without strict typing (like Ruby and Python) 3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you want to write web software you can reason about, you can still use web frameworks (maybe Flask or Sinatra) and you can still use third party packages (gems or things from pypi). If you import a library (left pad or whatever) and call it from your code, then you can still reason about what's going on. The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running.

vosper 10y ago
> The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running I think this is where the lack of strict typing can make things harder to figure out. Especially if you're trying to understand middleware functions with opaque signatures (like kwargs in Python). IDEs like PyCharm do their best at providing "Find all references", "Go to defintion" etc, and that helps, but it's not quite the same. Putting the info in the docstring is better than nothing, but it's still harder to parse (and maybe not machine parseable) and who knows if it's really correct? Personally I'm really hoping mypy or type-hinting really takes off in Python 3, and makes everyone's life easier.
- elcapitan 10y ago
  But is that really a problem of non-strict typing, or rather a problem of metaprogramming? I could imagine even a very strongly typed system in Haskell or Scala would probably be hard for an IDE to support if it uses a lot of complex abstractions to create internal DSLs (like Rails and I guess Django as well do).
  - geofft 10y ago
    IDEs can typically query a strongly-typed language for useful information without actually running the code. As long as the DSL uses static types, the IDE can just ask the compiler / type-checker to tell it what's going on and what portions of the source contribute to that meaning. This is where the fuzziness of the phrase "strongly typed" becomes a bit of a problem, but the fundamental idea is that there are two levels of meaning in the program, one static, and one dynamic, and the static level produces useful info. There are lots of levels this can take. The most common is in an IDE for a language like C or Python; it compiles or style-checks the file, warning you about issues, but it doesn't have any sense of what the program means. Another very common one is where you have non-code configuration files for GUI layout. You usually don't need a Turing-complete language to describe your GUI, so putting it in some other format like XML means the IDE can render the GUI and let you make changes to it without having to actually run your code. Strong typing for DSLs is just another example of the same sort of thing. If you're able to e.g. describe your models to the ORM entirely statically, it can figure out what a ton of your code means without running any of it. I think this is basically what you mean by metaprogramming, except with the constraint that one of the two languages is pure and Turing-incomplete and doesn't rely on external input. Then the IDE can safely run that language.
  - vosper 10y ago
    I can't speak for Rails, but at least with Python (primarily Flask) it's not internal DSLs that have caused me problems. I don't think Flask attempts to be a DSL at all, actually. From what little I've seen of Django it isn't trying to be a DSL either (unless I'm misunderstanding that term). It's more when I have 2 or 3 Flask libraries or middleware and they each are documented as if they exist in a vacuum but I want to use them all together and I wish it was easier to see that all 3 have functions that take a Flask Blueprint object, so they're probably all related, or that these functions work with URL objects, etc... It's a general complaint about Python and the tooling I suppose, not specific to web application frameworks.
bluedino 10y ago
>> 3) Programmers relying on large numbers of dependencies (e.g. ruby gems) So many gems are either not written well, or not maintained well. How many times have you seen the case where you update gem to fix a bug, and then cause two more? It's not Rails or Ruby's fault, it's the community.
- astrodust 10y ago
  Ruby's got a lot of software that's been produced over the years, and one of the risks here is that people burn out on projects and move on. A slow accumulation of dangerous deadwood occurs over time and unless people work to clear the brush it can be catastrophic when problems strike. Consider: ImageMagick and OpenSSL. Newer platforms haven't had this problem because they've already broken all their old software (Rust) or because they're still changing rapidly enough that new software is still emerging (Swift). It's not the community's fault. It's that it gets harder and harder to keep things clean the longer your language has been around.
  - askyourmother 10y ago
    Ruby gems in particular host a lot of abandonware and basically little turds that entice "I read pragprog, watch screencasts, and am now leet Rails dev!" Folks into using them with the promise of easy Lego style coding. It never ends well.
    - astrodust 10y ago
      Do you have a scat fetish? What is it with you and turds? People get hyped about any language the same way. How many Erlang "experts" or Node.js "ninjas" are there out there? Give it a rest. If people want to get excited about something don't shit all over them.
      - caconym_ 10y ago
        > Do you have a scat fetish? What is it with you and turds? Right about now is when you should go ahead and read his username, ideally out loud in your best Sean Connery voice.
hellofunk 10y ago
All 3 of those lamentations could also apply to Clojure, but I don't think anyone who used Clojure would lament it.
- smrtinsert 10y ago
  Yes they would. The rumblings of clojure and the dynamic language trap are already out there.
  - hellofunk 10y ago
    Haven't heard them myself and I'm quite involved with the community. Some disappointments about core.typed not being what some would have liked, but other than that...
mirekrusin 10y ago
Assembler solves all 3 of those problems, right?
outworlder 10y ago
> The last paragraph then goes on to suggest that different languages are required. This seems wrong. I feel that the programming languages are being used here as proxy for something else: the community surrounding them.

cplanas 10y ago

I agree with some of the issues that the author points in Rails; but, at the same time, he is unable to name what is "today's software" using his words. Until then, I will stay with Rails. Until then. Moreover, the author seems to be imagining Rails as a huge monolithic piece of software. That does not need to be true.

jmstickney 10y ago
Doesn't the author end by saying Swift, Rust and Go are "tomorrow's languages"?
- collyw 10y ago
  Yet he gives absolutely no justification for why those are "tomorrows languages". You don't use third party libraries or frameworks in any of those languages? Personally I design my Django code to be as simple as possible. I use third party libraries, and don't see too many of the problems he talks about.
  - nicops 10y ago
    Probably because the author doesn't use them and thus has no idea of what their problems are, so they seem "perfect" from a distance.
- cplanas 10y ago
  That's the issue: he calls them tomorrow's languages, implying that they need to change ("can you marry modern thinking, build a community [...]) before getting there, or being "today's languages". So far, I still haven't seen anything better than Rails to solve yesterday's (and today's) problems.

calcsam 10y ago

Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity. https://speakerdeck.com/tehviking/surviving-the-framework-hype-cycle https://speakerdeck.com/tehviking/surviving-the-framework-hy...

mooreds 10y ago
Thank you, that was a wonderful slide deck.
- dopamean 10y ago
  Brandon is a really awesome guy. His talks are always funny and informative.
  - brhays 10y ago
    I don't often visit Hacker News, but when I do, it's to receive compliments. But srsly, thank you, that's very kind to say.
astrodust 10y ago
Nails it. There's nothing shameful in using a "boring, not cool" platform to get work done. The pioneer lifestyle is full of risks. Sometimes you want that excitement, other times you have different priorities.
- maaku 10y ago
  Sometimes you want to read the article.
  - astrodust 10y ago
    I did. It was full of shit. These are the ramblings of someone who's never worked with a mature framework where, as always, there will be lots of legacy stuff laying around just begging to be fixed. But no, fixing stuff is hard. Let's write bitchy blog posts and blame everyone else.

tangue 10y ago

I was dubious when I saw the Medium.com tld and a clickbaity title but it actually puts word on what I feel after 16 (ouch) years of web development. The difference was that I was blaming the tools and screaming "#fail" with the other rather than thinking like the author that we're in a conceptual dead-end (at least with popular tools).

mml 10y ago

While it's true that Rails is sinking under the weight of its own cleverness, and is clearly the old hotness, this has nothing to do with Ruby the language. Rails' problems are its own, and Ruby's limitations and problem domain are well known. This is a terrible blog post by someone without much perspective. I award it no stars.

MaxfordAndSons 10y ago
The author of the post at no point blames Ruby for Rails' failings... But also I'd contest your argument that they're unrelated. Ruby is what enables the too-clever metaprog that make Rails stack traces so opaque. Also Rails has almost certainly been the single largest drive of Ruby's growth and popularity - observe the significant overlap of core contributors to both projects.

polysaturate 10y ago

I…don’t understand the point of the article? Ok Ruby is duck typed and has a dynamic runtime. It has for…all of the time since it was created. Rails has magic… since…all of the time since it was created. I’m not even defending Ruby or Rails here. Use at your own benefit/risk…as with every other programming language and framework.

crdoconnor 10y ago
The emphasis on magic was a particularly bad decision. It looked wonderful in the original screencasts that let you build a webapp in 5 minutes. It causes terrible pain when you're trying to do something complicated. This was one of the mistakes Django made and - to their credit - got over relatively quickly. It began as a kind of imitation of Rails but they stripped out the magic pretty quickly and made it a lot more explicit.
VLM 10y ago
Its the culture. My first RoR application a decade ago had basically no dependencies. The medium article implies the cool kids won't build an app unless it has enough dependencies to be unmaintainable and undeployable. So either you can't use the cool kids or you can't use the tool, the combo is no longer sustainable, its just done. The high time preference people will insist you install GEMs until the crash, its a technological bubble of sorts. Also my first CRUD app was very small and boring. That means un-debuggable isn't a big deal. Now apps are huge, therefore undebuggable. Even if you limit external dependencies that doesn't help internal dependencies. You can prototype things quickly, as long as they're small, featureless, no one uses them, and you don't care how difficult the are to deploy or debug. Other than that, no problem. Hmm.

elcapitan 10y ago

While I agree with many of the individual points he makes (rails dev myself), I think there is a kind of fundamental issue there that we have seen with most web framework/language combinations and will see with future ones, and that is that they usually come to life when one concept or idea they embody the best (for example mvc for crud apps with Rails, frontend/backend unification with node, native concurrency with Erlang, puristic http for microservices with Go) is becoming prevalent at some point, and then people put stuff on top of stuff which they put on top of other stuff, and then they realize that the problem they still have to solve is good architecture. And they need to balance that with business needs and developer availability. I don't think any of that is going to change by switching to the next fashionable concept to base a web app on.

askyourmother 10y ago

I remember early Rails, around 0.13, pre RC, the community was small the future seemed bright. Little did we know the horrors of what it would turn into. Most of the professional people left when they saw the security circus, the endless holes and design flaws. I learnt then - avoid any web framework which has pragprog pushing a book behind it. The new one to avoid because the masses are already circling around it is 'phoenix', and sure enough, pragprog is hawking a book on it.

astrodust 10y ago
That's a pretty shitty attitude to have. What framework is sufficiently irrelevant that Pragmatic Press or O'Reilly can't be bothered to write a book about it?
- askyourmother 10y ago
  Actually O'Reilly published a good book on Rails in the early days 'enterprise rails', which was a very well written book. The pragprog web books seem to be a bell weather, the shiny web crowd flowed into Rails, node and soon probably phoenix. The early start and promise and phoenix will soon sink under the weight once hex packages bloat in number like the festering turds within ruby gems.
  - carsonreinke 10y ago
    You are really pushing the turd argument [https://news.ycombinator.com/item?id=11661834 https://news.ycombinator.com/item?id=11661834]
  - astrodust 10y ago
    Rejecting a platform just because a publisher has written a book about it is like turning down a job because your astrologer said it was a bad fit. You sound out of your mind. Please try and make a rational argument.
dimgl 10y ago
Silly way to think in my opinion. Elixir has made me super productive, regardless of a Dave Thomas book existing for it.

gsmethells 10y ago

Know your dependencies well. Keep them few and far between -- and well vetted.

draw_down 10y ago

Everyone who uses software older than your preferred framework is an out-of-touch fuddy duddy, and everyone who uses software newer than your preferred framework is a clueless hipster.

icpmacdo 10y ago

I am thinking about completely stopping reading Hacker News. I enjoy the community a lot but every time I am learning something new I read about how its old and shitty and will cause hair loss when you try and invest any time in it. It puts the breaks on actually learning with the distraction of going and trying to find that new ambiguous stack that the author is hinting at.

askyourmother 10y ago
If you learn a library, you will always be in the driving seat. If you learn a framework, well, better buckle up, because it is a bumpy ride. Frameworks are like hamburgers at maccy ds - consumption for the masses, no thinking required. Later in life those decisions can be a problem.
- petepete 10y ago
  Given the choice between hand-rearing cattle and growing wheat versus buying a ready-made burger, well, it depends on whether you want to eat slightly less well, sooner or slightly better, later.
- meekins 10y ago
  It's exactly the attitude you describe what gets people into trouble with frameworks. Getting up and running and building things on a huge foundation like Rails is easy but you should also act responsibly and take the extra steps required to understand what's going under the hood. The effort of understanding a set of well defined "small" libraries is less daunting than a whole monolithic framework (probably with tons of bells and whistles you rarely even use) but both approaches (compare for example the style of the Clojure web app community vs Rails) have their benefits. A set of libs can be adapted more easily to specific needs and development of each of the individual dependencies can move fast without worrying about the others. On the other hand Rails changes relatively slowly but each Rails app being just another Rails app with all the pieces where you expect them to be can be considered a big plus in maintenance.
scj 10y ago
Wouldn't you rather be told upfront what a tool's flaws are before you invest years of effort into them? Even if you decide to embrace a tool despite flaws, isn't it best to recognize / minimize them? For example, C is a great tool. But heaven help someone if they ignore its' sharp edges. There is no silver bullet. So the best you can do is find something that suits you, and the task(s) you are trying to accomplish.

scolfax 10y ago

Don't blame your tools for an over-engineered project.

zippergz 10y ago

Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.

disease 10y ago
Scala and c#. Great tooling, static typing, functional and OO paradigms covered, fast (Scala runs fast once complied), flexible with tons of existing code already out there to be used or learned from.
emodendroket 10y ago
I have no complaints about C# and Webapi. Well, "no complaints" isn't exactly right but I like it.
spinlock 10y ago
Pheonix looks promising. It's basically Erlang on Rails.
- bobwaycott 10y ago
  Or Rails on Erlang (even though I see what you did there).
crdoconnor 10y ago
Django has always been relatively pleasant for me to develop in. Flask has been okay too. I almost learned Rails in 2007 when it was at the peak of its hype cycle but after reading a series of (not very well publicized) tirades about pain that Rails' magic caused I learned Django instead. I think node is at the peak of its hype cycle right now.
sotojuan 10y ago
Elixir's Phoenix: https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails

bluedino 10y ago

The question is where do you go from here if you're a Rails shop? The last place I worked had 80% of their products running Rails 2 and 20% of them running on Rails 3. No product was ever both completed AND caught traction since. Do you stick with Rails 5 for the next project? Do you meander over to Python or Node?

askyourmother 10y ago
Where from Rails? Anywhere looks better - personally, our firm uses falcon on python and lightweight Go web services with native std libs, and it works very well.
sotojuan 10y ago
Dockyard, a Rails agency, is moving to Phoenix I think.

omarforgotpwd 10y ago

1. The first software wave was system level software. Developers wanted something but made their lives easier, but also wanted control and speed. C and then Java were the stars 2. In the second wave, we got languages like Ruby and Python which are flexible and easy for developers to work with. Sometimes it's more important to be able to iterate quickly than execute quickly. Server software, app backends, etc were all implemented in whatever language was easiest using HTTP as an interchange with other languages 3. In the third wave, developer experience enhancements that scripting languages pioneered trickled down to systems programming with new languages like Swift and Go. These give you most of the benefits of the second wave languages without their significant overhead. Since they are better suited to building small light services, old bulky Ruby / Rails app are starting to look antiquated pretty quickly. I also used to go to Rails first for web projects... I use Go now because it's more lightweight. I used to do native apps in Objective-C... I now use Swift because it's easier to write.

tootie 10y ago

Just use Java people. You can bootstrap a Spring project in 10 minutes and it will have every feature (ORM, security, caching, MVC) available with just a maven dependency or you can roll your own and it will work fine. Strong typing, good performance, sensible stack traces (if you don't overdo annotations) and all the testing and monitoring tools you could ever dream of.

markbnj 10y ago
And namespaces like com.me.mine.whatever.toolong.to.type, and checked exceptions, and Oracle.
humbleMouse 10y ago
This comment is what I feel like replying with to every article about some "fast iterating" language. IMO the only reason to use rails if you don't actually understand how web development actually works. Why would you pick a slower language and platform like ruby/rails when java/spring is right there available to anyone?
- olavgg 10y ago
  And Grails is very similar to Rails, and you get the full power of the JVM/Spring technology stack. And Groovy is a fantastic language that gives you the flexibility everyone like to dream about.
  - humbleMouse 10y ago
    Groovy is amazing. It's like javascript and Java had a beautiful baby that lets you compile either dynamically or statically.
    - vorg 10y ago
      The static compilation doesn't quite work properly. Groovy is good for scripting though, similar to the way Bash is used in Linux, so test your Java classes with it, or use it as a DSL in Gradle builds. For building systems on the JVM, use a language designed for that purpose from the ground up, e.g. Java, Scala, or Kotlin.

deleted 10y ago

[deleted]

tomc1985 10y ago

Well, the situations with coffeescript exceptions and exceptions-from-the-depths-of-hell are avoidable (hint: don't use coffeescript)... indeed Rails makes it easy but just because crazy amounts of gems are on offer doesn't mean one has to use them. Ruby/Rails certainly has its quirks, and while Rails certainly does seem to be taking on more and more unnecessary dependencies, some are still plenty productive in day-to-day Rails. A lot of pain avoidance in Rails is following its opinions up-and-until it takes you further than you need to go

hartator 10y ago

Rails seems to become bloated for sure, but I think there is not a no brainer alternative out there. When I first switched from PHP to Rails it was a natural choice whereas i don't feel Rails to Node.js is in its current state.

max_ 10y ago
i wish someone could say the same for bootstrap

mattmcknight 10y ago

A couple of things seem off on this perspective, mostly that modern web development has gotten weird, irrespective of Rails. "The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple." First, I found Rails simple and easy, but it has become more complex over time as it has grown to support a variety of uses. The simplicity is not just because of Ruby, which is a low ceremony language, but rather because of the simple structure of the application, with a clear separation of concerns, very easy to find where a particular code item went. "The meta-programming and object injection that makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug. " Dependency oriented development is a real problem, but it is insane to blame that on Ruby. I was working with an enterprise Java team last year that had over 1000 .jars in their build. It doesn't necessarily make it hard to debug, but it does mean you have understand a wide variety of different libraries. People are willing to load a library for the simplest of functions (as the leftpad npm case showed). Again, nothing to do with Rails or Ruby in particular. "The magic of active record, the crazy levels of duck typing and the expressiveness of ruby, are exactly why it runs poorly even on your development box." This is highly dubious- it's very fast on my dev box. The Ruby interpreter keeps getting better, even taking lessons from V8, and you can compile to JRuby if you think that interpreted runtimes aren't ever going to keep up. "It’s why you have to build a caching strategy in as a requirement from first line of code." This seems like a good strategy regardless, and caching is nicely handled in Rails. "Competitors to Rails seemed subject to the same problem — basing themselves on interpreted, slow languages that favoured ‘easy to learn’ over ‘easy to maintain’." As opposed to compiled, fast languages like C++ that are hard to learn and hard to maintain? If anything, duck typing makes maintenance lot easier in some cases, where you can add in new types which support existing behavior, without making changes throughout the dependency tree. Even some 8 year old Rails apps we have are quite maintainable. JavaScript code does have a tendency towards messiness, as there are such a variety of schemes for organizing code, but it keeps getting better. "I should be spending time writing code, not debugging a haystack of mutable, dependency-wired mess." This is your choice! I think it's nice to have toolsets that give people the ability to assemble things quickly, but no one is forcing you to use a gem to do something. "Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself?" This seems like barking up the wrong tree. The thing making web development complex is largely the complexity of the front end. You can turn your back-end application into a separate API and isolate this problem. At some point, these become browser capabilities, and the polyfill approach has promise. (http://bitworking.org/news/2014/05/zero_framework_manifesto http://bitworking.org/news/2014/05/zero_framework_manifesto) In reality none of the stuff mentioned in this article is really a shortcoming of Rails as compared to anything else. The biggest change is the move away from the basic nature of REST-ful, URL driven applications. Single page apps are a lot more like desktop applications. Many applications are looking for web sockets. These changes to the basic structure of what a web application is are much more of a challenge to Rails than the Ruby language itself.

emodendroket 10y ago

Yeah, yeah. Nothing is going to magically solve all your problems; I don't necessarily think that means we need to go back to hand-rolling everything.

miloshadzic 10y ago

It's today's software which -- being almost a synonym for enterprise software -- can be a problem for a culture built on it's difference from Enterprise Java.

aaronwidd 10y ago

It's not Rails. Web software development in general has simply plateaued across the board. We're out of new frontiers to innovate around and the work from now on is about playing custodian to the innovations of the past. Unless something spectacularly interesting comes along, the priorities of the web are now all about supporting what's already been built. Either by maintaining something hastily built and cracking at the seams with patches and fresh coats of paint - or replacing it with something more stable for the long haul. Rails was designed around rapid innovation, not the long haul. So it's in maintenance mode.

sotojuan 10y ago
What about stuff like Elixir? Not innovative but it's interesting to explore the applications of Erlang's VM (fault tolerance, high availability, the concurrency model, stuff like supervision trees) to web applications.
smrtinsert 10y ago
We finished the web guys, you heard it here first on hacker news.

hardwaresofton 10y ago

For those that are feeling fatigued from working with and around the magic of Rails, Sinatra is a great choice (in python land Django has an alternative called Flask). http://www.sinatrarb.com/ http://www.sinatrarb.com/ That said, you will have to re-implement machinery that rails gave you for free. If you're building a simple API, there will be obvious simplicity benefits. If you're trying to build a server-side rendered web application, you may long for some things that rails provided (of course, you can use libraries and create simpler patterns than rails provided). Note that going the sinatra+libs (or any "micro" framework for that matter) route places a higher burden on the development team when it comes to documentation. If you implement a scheme for server side templating/rendering outside of what is provided, you will be in a world of pain in a relatively short time if you do not maintain good documentation.

bphogan 10y ago
You will indeed have to re-implement stuff Rails gives you. But more importantly, you will have to maintain it. I maintain a large-ish Sinatra app that should've been done with Rails. Update cycles on the gems are a nightmare. It feels cobbled together. it's a "half baked homegrown version of Rails." Someday I will just move the logic to a new Rails app and be done with it. It was a terrible idea. * your experience may vary. :)
- elliotec 10y ago
  My experience was exactly the same. Sinatra is for super tiny things. Rails is for most things.
- tchow 10y ago
  What is a large-ish app? Just for comparison's sake? What makes it large-ish? The number of tables? The number of views? What is the problem that large-ish apps give that Rails solves? Genuine questions, I only do small projects and I honestly don't see a huge benefit to using rails, despite having used it before.
- hkarthik 10y ago
  Any sufficiently complicated Sinatra app contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Rails.

avitzurel 10y ago

Today I learned that not everything you read on Medium is true and should be considered anecdotal and smart.

tunesmith 10y ago

I've been doing enterprise backend development (java/spring, scala, akka) for a while and occasionally miss the practice of sitting down and creating a fullstack app myself, which I used to do with php and crappy html. But then I sit down and try to work with existing Ruby/Rails codebases and hit a mental block. I guess example #1 is method_missing. I get it, it's a huge time-saver and lets you do all kinds of cool things like specify a default behavior for an API if someone sends a random command, or, define the behavior of a method dynamically by the name of the phantom method. But then the rest of me is reflexively saying, "Seriously??" And I get that Spring Data does sort of the same thing, but at least there it's limited by domain. If I'm in a Ruby codebase that is taking regular advantage of that, my first instinct would be find calls that eventually go to method_missing, and then just define the damn method somewhere so that my IDE's "Find Usage" will work again. How the heck do you explore a codebase quickly if your IDE doesn't work? I guess for me it just reinforces the same rules of thumb. Dynamic languages are fine if you're prototyping or doing an MVP. But as soon as you find that your codebase is being read/maintained more often than it's being written (which will happen sooner than you think), or as soon as you start finding weird production runtime bugs that don't happen in your local environment, you're better off with something strong or static or compiled. As for how to get that safety full-stack these days, I'm still poking around. Scalajs seems interesting, or Angular2 with Typescript, or something that uses RxJs...

abc_lisper 10y ago
How about writing tests that enforce invariants? I have been doing clojure dev for a little bit, and here's what I do - - Run tests in the background continuously (lein expectations will give you that. or you can write your own shell script) - Do small checkins, frequently to git - Write tests that enforce invariants. Haven't gotten to test check yet - but I guess that would be even better. The trouble with types is they push you into a corner early, and after a while people will be coding to zombie constraints - the constraints that were there before, but not true anymore. They are also verbose, and need tooling to get you out of the corner. If the requirements change a little bit, it could be that, your old solution goes against the grain of the new problem, which is very hard to get rid of without rewriting the code. With dynamic languages, I find that I think more about the problem, than trying to do constraint satisfaction with other entities in the code, not to mention the language itself.

pbowyer 10y ago

Previously posted at https://news.ycombinator.com/item?id=11658356 https://news.ycombinator.com/item?id=11658356, with great comments

hgh 10y ago

From Stroustrup of C++ fame: There are only two kinds of languages [frameworks]: the ones people complain about and the ones nobody uses.

uptownJimmy 10y ago
I think Rails might be a framework that nobody complains about, in the mid-term future. It is showing signs of age. And, though I say this with strong respect in my heart, the Rails governance is as opinionated and inflexible as the framework itself.

mnarayan01 10y ago

There's certainly a lot of truth in this (I especially like the duck-typing image), but the example feels like it throws it all away. You can, after all, have a _super_ fast and simple asset pipeline by keeping things...simple (to say nothing of skipping it entirely); having CoffeeScript compiling to JavaScript is not really relevant to either Ruby or Rails.

spriggan3 10y ago

> Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself? Go is great for plumbing, you can get network utilities up and running pretty fast with no dependencies so it's easy to deploy, that's its niche. Now try writing a complex eCommerce website, a news site, or any large app backed by a complex data model in Go... I started to use Asp.net CORE on Linux with Postgres the other day and frankly, I don't want to hear about Go and its "simple" type system anymore when I can just use C# and do projects in minutes without fighting the language. Go is at at most a safe C with channels (without macros which make it worse than C in term of features). My point is neither Swift,Rust or Go are silver bullets which will fit every use cases in Web Development. Neither is asp.net core,but for my use case there is no debate as to what I should be using. Rust,Go and Swift aren't tomorrow languages. They are languages that fit a specific use case like every other language.

lmm 10y ago

I've been using Scala for 5+ years now, so for me it's definitely today's software. Spray for REST backends, Wicket for HTML UIs. Clean syntax that can be as expressive as Python or Ruby, but coupled to a type system more powerful and effective than any of Swift, Rust or Go, light enough that you can lift things that had to be "magic" (like database-session-in-view) right up there into the type system.

tankerdude 10y ago

So my question would be, what's the difference between Rails and other frameworks, especially since we are doing RESTful APIs from the start? It would seem to me that Rails is just not the tool to use going forward for writing APIs for websites at scale. There are much better tools out there. Rails' sweet spot is server side rendered pages that are quick to bring up and to add features. It seems great for certain types of websites so it does have its niche. But moving forward, Rails for API vs. other frameworks in other languages is really a wash in terms of productivity, while other frameworks in those other languages are much more highly performant.

btilly 10y ago

The problem comes from this. 1. The costs of any layer of abstraction and magic that we have internalized seem free to us. So we feel free to add a more marginal one. 2. We have little visibility into any layer of the stack above or below ours. 3. As people migrate between languages, they take what they did previously and recreate it. Only "better". As a result, complexity grows over time. And programmers are really bad at noticing/correcting it. And when they try, they will come up with different prescriptions. Often opposing ones. Explicit is good. (Go.) Don't let people mutate state. (Functional languages.) Convention over configuration. (Rails.) Move work from programmers to IDEs and tooling. (Java.) Make programmers productive so more gets done with less code. (Most scripting languages from Perl on.) Over my lifetime, I've watched the resulting slide into complexity. Reading up on history I recognize that it had been going on for decades before I learned how to program. And it shows every sign of continuing to accelerate going forward.

cryptos 10y ago

I had similar experience with Grails. Discovering Grails and seeing how fast the first version of the application is up and running was fascinating. But sooner or later almost all generated code has to be replaced. It's not bad for the first iterations, but no time save in the long run. But the Grails magic was really awful! It cost so much time to find all the hairy bugs (in my own code or in Grails itself). Finally I stopped using Grails. I perfer static typed languages now (not only because of Grails and Groovy). And I prefer to compose some specialized frameworks. For example JAX-RS (Jersey) is a very good REST framework. There is no need to force the user to use it with a certain ORM (if at all), a certain way to validate objects and so on. Just take what fit's best. Java is not the most elegant or productive language but there are other static typed JVM languages like Kotlin or Scala. To come back to the article: I don't think that we need new languages, but another way to use existing frameworks and maybe statically typed languages.

smrtinsert 10y ago

I'm always tickled by the mythology that was sold thanks to a macbook and a textmate theme - that creativity is inherent to it, and that it is a pioneers tool, for craftmenship etc. That might all matter if the first thing people did once deploying it was to port off of it. For software that has such a rapid expiration date, none of it selling points matter. You might as well have written it in php or perl. Rails continues to be a favorite joke of mine.

SeanDav 10y ago

So if Ruby and Python frameworks are not suitable web development platforms - what is? The OP gives no alternatives, just a long rant about the problems of web development with dynamic languages.

heyts 10y ago

While I hear the argument, I'm tempted to think that the framework is largely irrelevant and that it actually is the ecosystem (package management and lack of quality control) that is harming platforms at large from Rails to Django to, obviously, node. I was very interested to hear of Elm enforcing Semver at the package manager level and I believe that this is a step in the right direction.

gjvc 10y ago

Web development techniques are crying out for an "emperor's new clothes" moment. Approaches like GWT (+ a toolkit such as GXT) seem to be a far saner approach for many enterprise applications. On the other hand, there are large classes of problems for which Rails / Django / et al have shown good results. Vive la difference!

MrBra 10y ago

If Rails, as of now, would've been a very fast framework, the post author would have never published such post, despite all the other "defects" he underpins. Rails could eventually get very fast, but it can be frustrating that it's not right now! This is the same kind of problem of Ruby not having a proper x-platform GUI toolkit or binary packager: you have such a expressive and powerful language and still you feel you are limited by the lack of speed and tooling. That's why, IMO, a Ruby/Rails dev frustration can explode in such a strong way at some point. Sadly Ruby isn't backed by a big corporation, so you can only wait for the language and frameworks to get more mature. Personally I've dealt with this frustration by learning C#. It allowed me to overcome all the current limits of Ruby, while avoiding the Java ShitFactory. At the same it feels great to get back to Ruby when you want to explore ideas! It's still an unbeatable tool for prototyping. Being aware that I have knowledge of another language, makes me feel better, less frustrated, and I browse Ruby weekly news with much less "anxiety" for a revolutionary Ruby improvement (but still I browse it because I know it will happen sooner or later!). I'm quite sure that the OP after having vented with this post, and having found what for him is a solution, then he will peacefully embrace Ruby or Rails again under a different light (but again, I wouldn't be so surprises to see big improvements soon, so maybe it could even be a better light!)