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 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.
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 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.
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.
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
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.
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.
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:
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.
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.
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.
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.
>> 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 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.
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.
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.
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.
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.
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.
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.
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. 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.
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?
> 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.
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.
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.
> 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).
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).
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'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...
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.
I've honestly never felt like types have gotten in the way. I also write plenty of tests with plenty of mocking, it's just that the type system means we don't have to write tests for the things the type checker checks for.
I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints. If anything, having a good type system makes it easier to rip out code that isn't used anymore. And Generics can help with keeping your solution from getting too specific.
The only dynamic language I used in production code is Clojure, hence my perspective is probably skewed by it.
> I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints
Think of deprecated methods in a class, unneeded methods in an interface that are stubbed etc.
> I also write plenty of tests with plenty of mocking
This is good. But what happens to mock objects when the underlying class changes its implementation - It needs a large number of changes in tests.
If you are writing micro-services, the guarantees that typed system gives you are more trouble than they are worth. If your average microservice is less than 10k lines of code, it probably reduces to 1000 lines of code in Clojure, and for the codebase of that size, typed systems provide little value for the cost(atleast for me).
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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.
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).
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!)
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
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
https://speakerdeck.com/tehviking/surviving-the-framework-hy...