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?
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.
> 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.
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).
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.
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.
Thanks, now I have a better idea of what constitutes a DSL. It had occurred to me that the ORM might be one, but I forgot about Jinja2 which clearly is.
Though, being pedantic, Flask doesn't bundle SQLAlchemy (though it's what you end up using) unless things have changed recently.
It sounds to me like a complaint about stupid metaprogramming. Every kind of programming can be done badly: there is stupid imperative, stupid OOP, stupid functional, stupid declarative, stupid pattern matching, stupid reactive, stupid aspect-oriented, ...
I'm not saying that Rails is stupid anything (I'm not familiar with it), but maybe that's the way it is in the blog author's view.
Here is an example of stupid: someone writes some class framework or whatever. It's open-source. Yet, the next someone wants to extend it---but instead of a proper source code patch, they implement some monkey patch which relies on mutating things in the original framework after it's loaded. Then the next someone after that does the same thing to the second someone's customizations, and so on. Then to find out what is being called you have to trace through to understand the side effects of several run-time patches.
The problem is accepting/returning a wide and disjoint type set, together with metaprograming itself.
Static typed languages tend to require that code deals with only a restrict set of types, and avoid metaprograming in exchange of other kinds of code abstraction.
I don't think this specific problem is big, tough. The dependencies one, by its turn, is huge.
The key is consistency I think. For matplotlib (which is probably one of the most commonly used modules that heavily uses args and kwargs), it's really useful. On the other hand it's only useful because their web documentation is really good and most of the time the args/kwargs are consistent between functions.
It also helps that most matplotlib kwargs can be controlled using an additional function, if you have a reference to the line/plot you want to modify. So you could do:
>> 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.
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.
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.
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.
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.
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.
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.
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.
1. extensive speaker notes included as an addendum
2. all of the content on the slides (which usually makes for a bad presentation)
Some presenters will have 2 versions of their decks -- one minimal version for the presentation, and one extended or enhanced version for later reference.
I've been pestering the SpeakerDeck folks to allow me to paste in my notes, even slide by slide. I have extensive notes but it makes for an ugly export. It'd be awesome if I could tag it as metadata somehow.
Nothing wrong with yesterday's technology if you're solving yesterday's problems! I don't mean that in a sarcastic or glib way, most of your problems really are yesterday's problems. Or even yesteryear's problems…. now that I think of it, when I depart from rails in a rails project (which is common), it's usually to use raw sql, unix, various networking protocols, or other programming languages that predate rails and ruby.
There was a good book out recently from pragmatic bookshelf called "rails angular postgres and bootstrap". Not saying you should necessarily use this stack (I don't), but the idea that you don't need to do everything in rails to use rails is worth listening to.
Generally, you're going to want to go back in time, to use tools that were designed for even older problems. For instance, why reinvent sql in a new language? If it's convenient to use active record and there's no performance hit, ok, use it, but don't go into contortions to avoid sql.
On a similar note, for those parts of a project where you really should go forward in time and start using tools that haven't withstood the test of time, by all means, go for it. But you aren't obligated to write the other 95% of the project in some new framework.
And... a lot of awful boilerplate code too. Not to put too fine a point on it, but much of what I see people write in the effort to avoid using an ORM is insanely poor, but they saved 2ms off of a report query that's run 3x per day. Nevermind that I can delete your entire database by modifying URL structure - ORMs are inefficient!
Activereord certainly saves me a lot of time. I think the reason orms get a lot of flak is that people see them usedin wildly inefficient ways that could have been solved with a simple join or other basic sql operation. Or alternatively people to to comical levels of twister to stay within the framework and create a parallel implementation of Sal.
But yeah if you use them judiciously they can remove some drudgery.
I can't think of an orm that can't handle joins. I can think of way that relatively inexperienced devs might use an orm in a day that doesn't take proper advantage of it though (seen it). I don't see this as a reason to avoid an orm of course. In rails it's pretty trivial to load associations most of the time.
There are also some queries that I think are best handled by find by sql oreven just raw sql. Sometimes this is performance othertimes it's for clarity.
Overall if you use an form properly I think it can save time and improve clarity.
Any ORM can handle joins. There are certain types of joins / aggregations / whatever that are harder for ORMs to support, and thinking that this is the fault of the ORM births monstrosities like Hibernate.
ActiveRecord for me hits a sweet spot in that it covers most of what you would need to do day-to-day in SQL and gives you easy ways to bypass it if you need to do something more complicated.
The biggest issue with ActiveRecord IMO is Rails devs who feel that falling down to raw SQL when it's warranted is wrong, and end up building insanely unreadable garbage using ARel (which in and of itself isn't a bad library, but should almost never be used in "high-level" code.)
I feel the problem is people go to extremes: either all handmade SQL or all ORM. Mixing both is pragmatic.
Take today's example, using the Doctrine2 ORM. I needed something simple: For every user, find the number of articles belonging to them with a specific status code.
Seems simple. Except the dumb ORM way of count($user->articles) lost the JOIN conditions, and counted every article.
So the 50% way was to use COUNT(article.id) in the query via the ORM. Unfortunately, because it doesn't know where to put the COUNT() value, the ORM destroys the easy usage, and returns a collection of the user object and a scalar value for the COUNT().
I worked with it, but TBH going back to raw SQL in this case would've been much easier.
After 30+ years of coding, my first encounter with Rails, a summer morning I received a ripped draft of a very early book on it remains one of the seminal moments of my career - so many elegant solutions to so many issues I'd grappled with since the mid-90s
As with any tool it's got some quirks and areas I could criticise - but it's got a place in my toolkit and will have for some time
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).
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.
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.
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.
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.
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.
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.
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.
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.
Author here. Hawking a book? Are you kidding me? I'm also the creator of Phoenix. I spent two years of my life outside of a FT job to get Phoenix to 1.0. We started a book because first class learning materials outside of the basic online guides is necessary on any platform. I make $3/copy from the book sales, so "hawking" a book does a disservice to me because if this was about money, I wouldn't have spent 8 months of late nights and hundreds of hours working on a book. Please reconsider your argument.
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.
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.
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.
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.
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.
I completely agree with you. But when it comes to developing web apps rapidly, Rails is about as close a silver bullet as you can get.
If your entire purpose is to ship a product quick, you should be ignoring the "too much magic, too many dependencies" narrative and building something, which Rails is wonderful at.
With Rails 5 just coming out now does it make sense to just start learning there. Is the material like the "Ruby on Rails Tutorial" book that uses 4.2 still worth reading or is it a large change, something like the python 2.7 to 3 where tutorials and reference material are largely dependent on the software version you use.
There will be some major changes, but not as drastic as the Python version upgrade. I'd think the 4.2 book will be totally fine, and when 5 is out, just look at the changelog and start adding what you need from it.
FYI, one of the big changes is in integration tests on controllers... it's not a huge difference, but if you try to copy from the book instead of generating your controller you might have issues. Also only the 5.1 RC is out.
If I was learning, I'd build an app with the current stable version of 4, a toy crud app with 100% test coverage, then try to convert that to 5. Then compare that to building 5.0 using it's generators. You are likely to work with legacy code, so learning 4 is not bad. May well do that myself, so I'm catching gotchas like the integration test changes in my toy and not at work on a deadline.
But yeah, coding, at least for me, is all about trade offs, and as long as you understand the rails trade offs and mitigations, you are fine.
Eh, there will be a large market for Rail & Ruby for a long time. One of the first things to come out of Rust & Golang was a Rails style framework.
And honestly when it comes to learning languages ideas are transferable, the only thing that changes is the wrapping around it. Learn what seems interesting and useful, and use the right tool for the right job.
Perhaps you might consider completely stopping reading Medium posts. Much of what is wrong with HN is the fact that people here think Medium gives them instant credibility.
(To be more specific, I object with how professionally-done Medium posts look, in contrast with their content, which often seem amateurish at best.)
That is the other conclusion I came too. The click bate title of it is enough to cause issues though. There is a consensus on this website though that Rails is good enough for ideas I want to get out there so I will stick with learning it, so far it has been fun.
Rails has a bright future ahead despite what this article states.
Consider for a moment that most projects just need to figure out product-market fit before we know where to throw the money to scale. Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language.
> Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language.
This is why I continue to use Rails despite being interested in this that and the other new thing. It's very productive in terms of getting something up and running.
I mean, heck, Twitter started with Rails, and despite some hiccups, managed to grow. And Twitter is pretty much the poster child for something that has to scale massively. Odds are, you won't have the same problem.
Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.
Getting to market quickly is often more important than contemplating about handling Twitter like traffic.
Also, I haven't heard of an application that never had to be rewritten partially/optimised after X years in production. Some problems just don't present themselves in the first couple of years.
Your statement is too cautious. At the start of a project, getting to market quickly is VIRTUALLY ALWAYS more important than handling Twitter-scale traffic. People are simultaneously confident their idea will be popular and afraid of failure, so we have a strong tendency to over-engineer for scale.
If it does scale, don't be surprised if you have to toss out your v1 and rebuild. The difference between a good framework and a bad one isn't about whether it survives scaling; it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.
> it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.
So the important questions are:
1. Does Rails performance degrade gracefully under load?
2. Can you gradually shift away from a quick-and-dirty Rails-based implementation to something more scalable without the dreaded "rewrite-while-hair-on-fire" scenario?
In my experience, the answer to both of these is 'no'.
(But these challenges are hardly unique to Rails.)
Given the example of Twitter I'd say that the answer to the second question is yes. They rewrote the Ruby (not Rails) backend and continued serving tweets. Did they have theirs hairs on fire? Maybe, but I don't think you're never in hurry when you rewrite parts of a popular service.
About question number one: no idea, but you can add more machines and scale horizontally. Then you might ask if you want more efficient code between the web server and the database. You can optimize up to C. Finally, Twitter is still using Rails for the front end AFAIK, so it shouldn't be so bad.
Plus I hate the forced corporate atmosphere. I've noticed anyone with strong philosophical opinions on software are typically shunned in favor of the corporate narrative.
I feel like a couple of years ago HN had a pretty diverse culture when it came to OS and software stacks, the past few months it seems EVERYONE is shoving corporate shit down my throat: VSCode, "Bash on Linux", Azure, TypeScript, Windows 10, and don't forget real programmers spend 90% of their time editing decades old MSWord files so they can't possibly go without MS office.
If it has a big corporation behind it HN will shove it down your throat, if it's a small open source project HN will circlejerk around it like it's the next big thing, if it's an OSS project that threatens some big corporate project you can bet money that HN will shit all over it.
You'll probably be happier with your life if you let go of that, because this cycle has been part of software as long as I've been involved with it, and I expect that it will always be so.
For any given technology which manages to take off at all, there's generally at least a ten year span during which some groups of early adopters are calling it "old and busted" and moving on, while other people are just discovering the "new hotness" and piling in. Just because this guy has switched from one group to the other doesn't mean you need to follow him; if the technology is good and meets your needs then hey, take it on, it'll be great.
The other thing that happens is... well, most of what this article is talking about has nothing to do with technology in the first place; it's more about the community built around that technology, and the fact that the author no longer feels like that community is going in a direction compatible with his needs.
I'm not part of the ruby community at all so maybe he's right and the "roadmap for rails is bleak" - but I'd bet that it's really more that it has developed further but not in a way that suits this author's needs, so he feels disappointed and alienated from the community, and he is observing that he and the rails community are drifting apart and will soon get divorced.
This says nothing whatsoever about the compatibility of the current rails community's direction with your direction, and it makes no useful predictions about the future development of the rails technology and its potential compatibility with your needs. It could be that the same forces driving this author away from rails are the ones which have brought it to your attention as something worth learning about and investing in.
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.
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.
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.
Node.js, it's a great fit because it doesn't try to be much more than a thin framework for web services. The value of code JS sharing between server and client is a bit overblown imho, but sharing same language skills is nice.
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?
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.
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.
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.
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?
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.
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.
It works quite well in the 1.5 million code line application written in groovy that I work on. I am sure Scala and Kotlin are nice languages, but groovy static compilation seems to work great in my experience.
> the 1.5 million code line application written in groovy
That's quite big for Groovy. There's a lot of exaggerated claims coming out of that ecosystem. Most JVM apps that size are actually written in Java, perhaps with the codebase duplicated a few times, and counting testing copies of the code in the LOC count. If the harness for testing is written in Groovy, you could call it a "1.5 million line Groovy app". If some of that Java code is compiled or run as Groovy code in some testing framework, you could call it all "Groovy code". If the Groovy code is called from some app written in Java, such as Grails, you could get creative and call it a "Groovy application".
> groovy static compilation seems to work great
And just what proportion of that Groovy code is really compiled statically and run in a production app?
To be fair - only about 2/3 of the code in the app I mentioned is written in groovy. We strictly enforce static compilation with all of our groovy files. The app is used daily by 35,000 users concurrently @peak time.
My last personal experience of programming in Apache Groovy was with version 1.8. Often I tried recompiling some Java code from Groovy's codebase into Groovy, and even after changing it to allow for occasionally different semantics, it wouldn't work. It could be that Groovy 2.4 has improved a lot since v 1.8, but with the history of exaggerated claims associated with Groovy's backers, I'd need more evidence for your claim. For example, if the next version of Groovy ships having translated its own codebase into statically compiled Groovy, I'll happily look at it again for building systems. In the meantime, I'll only trust it for scripting.
Then there's their governance problem -- nowadays, a single person owns the groovy-lang.org website, whereas until early last year it was governed by 5 "despots" at Codehaus. It's never good when leadership becomes less consensual.
Apache Groovy is a dynamically typed language so performance can't be "top notch". And the static compilation is an addon that only works when used sparsely. If it worked at scale, the Groovy codebase itself would have been translated into statically compiled Groovy, but that's not happening because Groovy's static compilation doesn't scale. Groovy's good for scripting, nothing more, which isn't a bad thing. Just use it to script/test systems built with Java (or Scala or Kotlin or whatever).
> you get the full power of the JVM/Spring technology stack. And Groovy
If Groovy and Grails are technology "to dream about", one wonders then why VMware (the Spring backers) retrenched their 6 developers working on Grails and (what is now Apache) Groovy early last year, and why Sun Microsystems (the JVM backers before Oracle) wanted nothing to do with Groovy in its day (despite supporting the JRuby and Jython developers).
Fast-iterating is only useful when you have a small team and are getting off the ground. Every project spends 90% of it's life in maintenance and will be handed off between dozens of developers who will just ask "WTF is this?" no matter what you do. Java provides a lot more traceability and determinism as well as verbose idioms that make it easier to deal with. Like I've said many times, Java doesn't solve programming problems, it solves organizational problems.
> IMO the only reason to use rails if you don't actually understand how web development actually works.
I'm not following your reasoning. Just because Ruby/Rails runs slower than Java/Spring, why does that mean you "don't understand how web development actually works" if you choose Ruby/Rails?
That's a serious question. Runtime performance of a language/framework is only one small sliver of the overall performance of a large system. And overall runtime performance of a system is only one factor, among many, when choosing the right stack for a business.
To expand on my offhanded comment: If you are well versed in OOP design principles/database design - I don't see why you would choose rails. I suppose if I didn't have so much experience with java I might want to try something like ruby. Java just gives you so much freedom to design things how you want and use whatever framework you feel like.
I don't feel comfortable with all these behind the scenes scaffolding things happening. I prefer to design back-ends as data endpoints that feed a separate business logic layer. I feel like I have the most control of these things using java.
> Java just gives you so much freedom to design things
> how you want and use whatever framework you feel like.
This lack of flexibility is precisely the reason that people choose Rails. It is a very opinionated solution and the Rails community doesn't hide that fact. The power of a Rails project is anyone familiar with Rails can walk up to it and get productive in minutes. All the code is in a standard place, the tests are run the same way, the deployment is familiar, etc.
On the contrary, look at 100 different Java projects and you would find 100 very different solutions. Getting up to speed on an existing Java project would take multiple times longer than a Rails project, even if you were generally familiar with Java + Spring.
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
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)
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.
+1 but about REST and the websockets: I'd keep using REST to query data and send data (and get a response). I'd use a websocket only for those cases where I should poll the server for updates. Reimplementing most of the semantic of HTTP into a websocket looks weird. Basically it would be tunneling HTTP into the websocket, which is already an upgrade of a HTTP connection.
Exceptions: I won't POST to a chat, even if there is nothing so wrong with that. Rationale: I'm already using that websocket for receiving messages, but only the messages for that chat.
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.
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.
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.
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).
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.
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.
165 comments
[ 4.8 ms ] story [ 233 ms ] threadHow 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?
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.
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.
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.
It's a general complaint about Python and the tooling I suppose, not specific to web application frameworks.
Django bundles two DSLs - the ORM (filter, etc.) and the templating language.
>I don't think Flask attempts to be a DSL at all
Flask bundles jinja2 and sqlalchemy which perform the same purpose.
Though, being pedantic, Flask doesn't bundle SQLAlchemy (though it's what you end up using) unless things have changed recently.
I'm not saying that Rails is stupid anything (I'm not familiar with it), but maybe that's the way it is in the blog author's view.
Here is an example of stupid: someone writes some class framework or whatever. It's open-source. Yet, the next someone wants to extend it---but instead of a proper source code patch, they implement some monkey patch which relies on mutating things in the original framework after it's loaded. Then the next someone after that does the same thing to the second someone's customizations, and so on. Then to find out what is being called you have to trace through to understand the side effects of several run-time patches.
Let's not dump dynamic because of stupid dynamic.
Static typed languages tend to require that code deals with only a restrict set of types, and avoid metaprograming in exchange of other kinds of code abstraction.
I don't think this specific problem is big, tough. The dependencies one, by its turn, is huge.
It also helps that most matplotlib kwargs can be controlled using an additional function, if you have a reference to the line/plot you want to modify. So you could do:
or equally: But in the end it comes down to documentation. I think Python traces are generally pretty good at telling you what you did wrong.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.
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.
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.
Right about now is when you should go ahead and read his username, ideally out loud in your best Sean Connery voice.
Some disappointments about core.typed not being what some would have liked, but other than that...
I feel that the programming languages are being used here as proxy for something else: the community surrounding them.
Moreover, the author seems to be imagining Rails as a huge monolithic piece of software. That does not need to be true.
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.
So far, I still haven't seen anything better than Rails to solve yesterday's (and today's) problems.
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
But srsly, thank you, that's very kind to say.
The pioneer lifestyle is full of risks. Sometimes you want that excitement, other times you have different priorities.
But no, fixing stuff is hard. Let's write bitchy blog posts and blame everyone else.
As an aside, how do people consume slide decks? It doesn't seem as interesting without the associated lecture...
Nothing wrong with yesterday's technology if you're solving yesterday's problems! I don't mean that in a sarcastic or glib way, most of your problems really are yesterday's problems. Or even yesteryear's problems…. now that I think of it, when I depart from rails in a rails project (which is common), it's usually to use raw sql, unix, various networking protocols, or other programming languages that predate rails and ruby.
There was a good book out recently from pragmatic bookshelf called "rails angular postgres and bootstrap". Not saying you should necessarily use this stack (I don't), but the idea that you don't need to do everything in rails to use rails is worth listening to.
Generally, you're going to want to go back in time, to use tools that were designed for even older problems. For instance, why reinvent sql in a new language? If it's convenient to use active record and there's no performance hit, ok, use it, but don't go into contortions to avoid sql.
On a similar note, for those parts of a project where you really should go forward in time and start using tools that haven't withstood the test of time, by all means, go for it. But you aren't obligated to write the other 95% of the project in some new framework.
But yeah if you use them judiciously they can remove some drudgery.
There are also some queries that I think are best handled by find by sql oreven just raw sql. Sometimes this is performance othertimes it's for clarity.
Overall if you use an form properly I think it can save time and improve clarity.
ActiveRecord for me hits a sweet spot in that it covers most of what you would need to do day-to-day in SQL and gives you easy ways to bypass it if you need to do something more complicated.
The biggest issue with ActiveRecord IMO is Rails devs who feel that falling down to raw SQL when it's warranted is wrong, and end up building insanely unreadable garbage using ARel (which in and of itself isn't a bad library, but should almost never be used in "high-level" code.)
Take today's example, using the Doctrine2 ORM. I needed something simple: For every user, find the number of articles belonging to them with a specific status code.
Seems simple. Except the dumb ORM way of count($user->articles) lost the JOIN conditions, and counted every article.
So the 50% way was to use COUNT(article.id) in the query via the ORM. Unfortunately, because it doesn't know where to put the COUNT() value, the ORM destroys the easy usage, and returns a collection of the user object and a scalar value for the COUNT().
I worked with it, but TBH going back to raw SQL in this case would've been much easier.
Pragmatism, the lost art (TM)
After 30+ years of coding, my first encounter with Rails, a summer morning I received a ripped draft of a very early book on it remains one of the seminal moments of my career - so many elegant solutions to so many issues I'd grappled with since the mid-90s
As with any tool it's got some quirks and areas I could criticise - but it's got a place in my toolkit and will have for some time
As you say, the actual article is about how Rails has all of yesterday's flaws, which is pretty much the opposite of "reliable and boring".
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.
I’m not even defending Ruby or Rails here. Use at your own benefit/risk…as with every other programming language and framework.
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.
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.
I don't think any of that is going to change by switching to the next fashionable concept to base a web app on.
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.
What framework is sufficiently irrelevant that Pragmatic Press or O'Reilly can't be bothered to write a book about it?
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.
You sound out of your mind. Please try and make a rational argument.
https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails
Frameworks are like hamburgers at maccy ds - consumption for the masses, no thinking required. Later in life those decisions can be a problem.
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.
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.
If your entire purpose is to ship a product quick, you should be ignoring the "too much magic, too many dependencies" narrative and building something, which Rails is wonderful at.
If I was learning, I'd build an app with the current stable version of 4, a toy crud app with 100% test coverage, then try to convert that to 5. Then compare that to building 5.0 using it's generators. You are likely to work with legacy code, so learning 4 is not bad. May well do that myself, so I'm catching gotchas like the integration test changes in my toy and not at work on a deadline.
But yeah, coding, at least for me, is all about trade offs, and as long as you understand the rails trade offs and mitigations, you are fine.
And honestly when it comes to learning languages ideas are transferable, the only thing that changes is the wrapping around it. Learn what seems interesting and useful, and use the right tool for the right job.
(To be more specific, I object with how professionally-done Medium posts look, in contrast with their content, which often seem amateurish at best.)
Consider for a moment that most projects just need to figure out product-market fit before we know where to throw the money to scale. Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language.
This is why I continue to use Rails despite being interested in this that and the other new thing. It's very productive in terms of getting something up and running.
I mean, heck, Twitter started with Rails, and despite some hiccups, managed to grow. And Twitter is pretty much the poster child for something that has to scale massively. Odds are, you won't have the same problem.
Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.
Implying that Twitter reached success under Rails, even if it was _not_ the best fit for the problem set.
Dumping Rails when you have won the market is a nice luxury to have, one that most people on HN do not have.
Also, I haven't heard of an application that never had to be rewritten partially/optimised after X years in production. Some problems just don't present themselves in the first couple of years.
If it does scale, don't be surprised if you have to toss out your v1 and rebuild. The difference between a good framework and a bad one isn't about whether it survives scaling; it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.
So the important questions are:
1. Does Rails performance degrade gracefully under load?
2. Can you gradually shift away from a quick-and-dirty Rails-based implementation to something more scalable without the dreaded "rewrite-while-hair-on-fire" scenario?
In my experience, the answer to both of these is 'no'.
(But these challenges are hardly unique to Rails.)
About question number one: no idea, but you can add more machines and scale horizontally. Then you might ask if you want more efficient code between the web server and the database. You can optimize up to C. Finally, Twitter is still using Rails for the front end AFAIK, so it shouldn't be so bad.
Plus I hate the forced corporate atmosphere. I've noticed anyone with strong philosophical opinions on software are typically shunned in favor of the corporate narrative.
I feel like a couple of years ago HN had a pretty diverse culture when it came to OS and software stacks, the past few months it seems EVERYONE is shoving corporate shit down my throat: VSCode, "Bash on Linux", Azure, TypeScript, Windows 10, and don't forget real programmers spend 90% of their time editing decades old MSWord files so they can't possibly go without MS office.
If it has a big corporation behind it HN will shove it down your throat, if it's a small open source project HN will circlejerk around it like it's the next big thing, if it's an OSS project that threatens some big corporate project you can bet money that HN will shit all over it.
For any given technology which manages to take off at all, there's generally at least a ten year span during which some groups of early adopters are calling it "old and busted" and moving on, while other people are just discovering the "new hotness" and piling in. Just because this guy has switched from one group to the other doesn't mean you need to follow him; if the technology is good and meets your needs then hey, take it on, it'll be great.
The other thing that happens is... well, most of what this article is talking about has nothing to do with technology in the first place; it's more about the community built around that technology, and the fact that the author no longer feels like that community is going in a direction compatible with his needs.
I'm not part of the ruby community at all so maybe he's right and the "roadmap for rails is bleak" - but I'd bet that it's really more that it has developed further but not in a way that suits this author's needs, so he feels disappointed and alienated from the community, and he is observing that he and the rails community are drifting apart and will soon get divorced.
This says nothing whatsoever about the compatibility of the current rails community's direction with your direction, and it makes no useful predictions about the future development of the rails technology and its potential compatibility with your needs. It could be that the same forces driving this author away from rails are the ones which have brought it to your attention as something worth learning about and investing in.
Oh, the irony: https://news.ycombinator.com/item?id=8787117
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.
https://dockyard.com/blog/2015/11/18/phoenix-is-not-rails
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?
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.
That's quite big for Groovy. There's a lot of exaggerated claims coming out of that ecosystem. Most JVM apps that size are actually written in Java, perhaps with the codebase duplicated a few times, and counting testing copies of the code in the LOC count. If the harness for testing is written in Groovy, you could call it a "1.5 million line Groovy app". If some of that Java code is compiled or run as Groovy code in some testing framework, you could call it all "Groovy code". If the Groovy code is called from some app written in Java, such as Grails, you could get creative and call it a "Groovy application".
> groovy static compilation seems to work great
And just what proportion of that Groovy code is really compiled statically and run in a production app?
Then there's their governance problem -- nowadays, a single person owns the groovy-lang.org website, whereas until early last year it was governed by 5 "despots" at Codehaus. It's never good when leadership becomes less consensual.
If Groovy and Grails are technology "to dream about", one wonders then why VMware (the Spring backers) retrenched their 6 developers working on Grails and (what is now Apache) Groovy early last year, and why Sun Microsystems (the JVM backers before Oracle) wanted nothing to do with Groovy in its day (despite supporting the JRuby and Jython developers).
I'm not following your reasoning. Just because Ruby/Rails runs slower than Java/Spring, why does that mean you "don't understand how web development actually works" if you choose Ruby/Rails?
That's a serious question. Runtime performance of a language/framework is only one small sliver of the overall performance of a large system. And overall runtime performance of a system is only one factor, among many, when choosing the right stack for a business.
I don't feel comfortable with all these behind the scenes scaffolding things happening. I prefer to design back-ends as data endpoints that feed a separate business logic layer. I feel like I have the most control of these things using java.
This lack of flexibility is precisely the reason that people choose Rails. It is a very opinionated solution and the Rails community doesn't hide that fact. The power of a Rails project is anyone familiar with Rails can walk up to it and get productive in minutes. All the code is in a standard place, the tests are run the same way, the deployment is familiar, etc.
On the contrary, look at 100 different Java projects and you would find 100 very different solutions. Getting up to speed on an existing Java project would take multiple times longer than a Rails project, even if you were generally familiar with Java + Spring.
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
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.
"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)
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.
Exceptions: I won't POST to a chat, even if there is nothing so wrong with that. Rationale: I'm already using that websocket for receiving messages, but only the messages for that chat.
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.
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.
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. :)
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.