Rails has won: The Elephant in the Room
akitaonrails.com
akitaonrails.com
My advice: if you have skin in this game and need to make real decisions about what platform/language you use, find an article that reasons soundly about what the questions are and convinces you of its answers. Don't listen to this one. And if this quality of thinking is diagnostic of how Ruby/Rails developers think generally... well I'm glad that's a game my skin is safe from.
The author's main issue with his writing style is he makes logical leaps without bringing the user along. He jumps from topic to topic without letting the user know why he's doing so.
I think the piece can be improved with some structural changes. So I would recommend the author or other readers consider this style for structurally formulating arguments for essays or presentations [1] often used at McKinsey.
(Note: I know McKinsey gets a lot of hate around here sometimes, but given their ability to consult with C-suite leadership, they're probably pretty good at formulating arguments/persuasion)
[1] https://medium.com/lessons-from-mckinsey/the-pyramid-princip...
RE: http://www.thunderbird.edu/article/understanding-high-and-lo...
Do you feel differences in context-type of a language means persuasion techniques differ as well?
Akita is a pretty smart dude. He makes a number of good points, and maybe doesn't tie them perfectly together, but it's a blog post he wrote in a day, not for Harpers.
A few points from his rant:
1. If you don't drink the kool aid, you'll be frustrated if you want something else 2. market forces: you have to follow rails, but if rails changes or goes away, you're stuck (-ish, it's OSS) 3. rails is good at what it does, and provides many with a useful framework, even if, in retrospect, it isn't well architected
If Akita had written:
Sometimes, tools and frameworks, like
Wordpress and Rails, respectively, gain
enough traction that their monopoly
economies of scale keep them afloat
long after their value sunsets.
The general thesis seems to be that The frustration that Solnic felt with Rails is understandable, and quite possibly inevitable, as rails has become mainstream, large, and a ripe target for disruption by other frameworks/libraries. Despite this, Rails is still an excellent framework due to it's easy-rampup for beginners, and flexibility for more experienced developers.
Here is my summary of the sections, as I understood them:
Accepting Reality:
- Ruby is not much without rails.
- Large frameworks are written by entities that can afford to, so they are not held to the whims of other large entities (angular/polymer for google, react for fb, etc). It's just a power struggle.
- Rails can be compared to Wordpress, though wordpress's codebase is worse, rails suffers from similar lockin as tools like wordpress and magento.
- The community of rails is well-connected, and if large enough entities invest in rails & ruby, it will be fine, and will continue progressing through the natural cycles of OSS projects
Laws of market reality:
- Rule 1) Hindsight is 20/20
- Rule 2) No solution is perfect
- Rule 3) You either build tools for yourself or for others, fits-you or fits-the-market
- Avoid building businesses completely on frameworks/platforms made available by large entities, as they may dissapear at a moment's notice (i.e. don't tunnel-vision angular because google might kill it like GWT)
- Beware of churn and external reasons for software projects being put out to pasture.
- There is too much churn, and there are too many companies trying to make the next big thing. This can maek the monopolies provided by ASP.NET and Rails very attractive.
- There are many similarities between rails, asp.net and spring in that they shield you from churn and offer a tyrannical but relatively-unchanging toolset
- Frameworks either die heroes or live long enough to become the villain
Why is this a problem for rails now? What is the history of rails and it's competitors?
- The technical points from Solnic's article mostly have merit
- DHH has flaws, and rails is very much his brainchild. He created it while he had a business to run
- People flocked to rails from various languages/frameworks (.NET, PHP, Java), so they could drop unnecessary abstractions
- People got addicted to writing ruby, for it's simplicity and productivity advantages over PHP, Java, and C#
- 2007-2011 were magical years (the silver age) for ruby adoption, every drinks rails koolaid. Merb tries to capitalize and fails (though it was ahead of it's time).
- 2011-2016 was a bittersweet period (the bronze age). Other languages have created their own frameworks, and are similarly productive to ruby, so they start to gain attention. Languages like Node, rust, clojure, elixir and even haskell.
- The bronze age also sees big companies start to release languages (apple with swift, google with dart and go, microsoft with typescript ASP.NET MVC, facebook with react)
- Rails is having this issue because it was meant to. It is being disrupted just as it's predecessors were. It is inevitable.
- Being the incumbent, rails is vulnerable because it cannot move or change as fast.
- The dominant model has also shifted, from rails-y backends to much simpler APIs talking to SPAs (Single Page Apps). Apis are much smaller cand can be written easily in various other languages
- For small to medium projects that fit rails's model, rails is still king. As wordpress is still king for blogs -- yes you could write a blog with go APIs and using react, but it's not wise.
- If you're using ra ils as a medium sized company, make sure you're using all the lastest rails practices -- it may not make sense to pursue a rewrite right away.
Conclusion:
- Solnic has a point, the rails community has become a frustrating place to be for many people, but it has built lots of momentum. It also common for people to side with the underdog frameworks.
- Rails made the transition from underdog to mainstream in 5 years, and has done a lot for web development. It's hard to offer all of what rails offers and power the web as it has done.
- ActiveRecord is indeed a rough point for rail's architecture, but there's no alternative that offers benefit worth the pain of a rewrite. New applications thould definitely use rails + trailblazer or go straight to the Hanami framework, but most will probably just ditch ruby.
- ActiveRecord could be better, but it looks like even the creator of DataMapper has moved away from ORMs. For the usual case, ActiveRecord is still a good technology to use.
- Other communities will face the same issues rails is having, as they become mainstream. It's inevitable that DHH has chosen not to make large sweeping changes to rails, and although it alienates experienced developers, starting with rails is still easy for beginners.
- People forget the magic of rails that beginners feel when they start, and rails wins because of it's simplicity when learning as a beginner, as well as enabling experienced developers to make tweaks to it.
- It's anyone's guess whether rails will last another 10 years given all the competition it's currently facing
First of all, it's inevitable but I still hate dramatic headlines, even though I
write like this myself sometimes. "My time with Rails is up" like it's saying
"And you should leave Rails now too if you're smart". I dismissed the article
entirely because of that. I was about to post a counter-rant to that without
reading it properly, but now that I have, I wrote this new article from scratch.
If you go over other posts in that blog you will notice the same pattern: spit random (and most of the time wrong) stuff in an attempt that something will make sense (which never does).
I've both seen and spent a lot of time rewriting overgrown Sinatra monstrosities with assorted non-AR ORMs. These apps were generally riddled with XSS since they didn't handle escaping correctly, often had unmaintainable code that sometimes was thousands of lines long crammed into a single file, and lacking any sort of basic structuring principles mixed parameter handling with business logic all over the place.
I've seen several attempts to "build a better Rails" that's "more OO", but even frameworks that solve the problems I've just described in the previous paragraph have one huge drawback: Rails is a lingua franca for web development in Ruby, and whatever incremental gains you get from having a better framework are heavily outweighed by the costs of making people learn a new framework-per-project, the lack of features and documentation, and the lack of the library ecosystem that surrounds Rails.
At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel, which just left me wishing I was dealing with AR (the devil you know...)
ORMs need massive feature sets to jam the proverbial square peg of relational databases through the round hole of objects, and AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in and mature enough to even have a story around database concurrency, even if most Rails developers are getting database concurrency wrong with AR (e.g. http://www.bailis.org/papers/feral-sigmod2015.pdf ) At least AR has any story around things like optimistic and pessimistic locking and lets you build apps where you can read an object and persist your changes without silently clobbering another requests's database writes with your locally cached copy of stale data.
tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby.
Have you never worked on a system big enough to need a service layer?
This is why I use Virtus and ROM.
As it were I wrote the AuthN/AuthZ library Square uses to solve this problem:
https://github.com/square/rails-auth
The objects we build for representing user identities are POROs. No need for every app to have a database connection to a shared user service, or to go through an ORM.
I'm somewhat confused what alternative you're even proposing here: are you doing something weird like Marshalling ORM objects between services?
(In my own case, I have a service architecture because I literally have to; I need to run services in multiple AWS regions. It would be nice to be able to not care and fart everything into a single monolithic application, but them's the breaks. I tend to think that almost every sufficiently complex or sufficiently scaled application ends up in this state, too.)
With Virtus/rom-model (or I guess the newer dry-types, though I haven't used it), I don't, because my--versioned, because my APIs already require compatibility--model objects are aware of their own contents, and I can trivially marshal objects over the wire. (I also don't have to go look at the database schema to know what my object is. Big plus.)
I actually prefer the distinction: serialized domain objects do not have access to the full richness of the ORM API, so having a separate class representing the specific behavior of an API-wrapper makes a lot more sense to me.
Something like ActiveModel::Serializers wraps up a lot of the boilerplate while also letting you retrieve nested object graphs in a single request:
https://github.com/rails-api/active_model_serializers
That said at Square we generally use protobuf-based RPC for our service-to-service requests, because we have a polyglot SOA so it's important for our services to produce and consume protos to support more languages than just Ruby.
Can't you recognize the usefulness of a hammer even if you need a screwdriver for your task?
I don't agree with regards to SOAs and either productivity or maintainability, but I also tend to work on systems that have concrete needs for scale and I also divorce it from the microservice craze (which I regard as a rather pathological case). But that's kind of off-topic.
I seriously would have gotten the job done in half the time, with less problems had I just used Rails...and I've written my own ORMs before - I have somewhat of a clue.
If so the "tl; dr:" sounds strange considering your celluloid-based eco-system.
Edit: which I consider, at least to date, a bit orthogonal to the Rails ways.
That's rather dating your "at points". DataMapper hasn't seen an update since 2011, and Sequel's shipped with optimistic and pessimistic locking since early 2010.
But... wasn't this the underlying point of Solnic's opinion piece?
Due to Rails "well deserved" domination in the web framework space, POROs never had a chance of contributing to friendly and just competition across the Ruby community. We simply ended up with shitty alternatives because no one was given the proper chance to be BETTER Rubyists.
They just kept eating the gluten and feeling the allergy pains, so to speak.
Ah well...
EDIT: shrug quoting...
There was an essay pg wrote where he said that Microsoft was Dead (http://www.paulgraham.com/microsoft.html). He didn’t mean dead as in “Dead," he meant dead as in “Nobody is afraid of them any more,” and the generalization of that is that it was no longer relevant.
I think Rails is there. I think Rails is dead. Obviously, not dead as in dead, but dead as in, it is no longer revolutionizing anything. It is no longer making new things possible. People no longer adopt it and discover a productivity dividend they didn’t expect. It no longer swings business decisions (“How can we get this done in three months? What about using Rails? Let’s try it.”)
I think that’s fine. I can quote “A new perspective is worth 80 points of IQ.” I don’t think that’s true of Rails today, but then again, I don’t think that’s what people want from Rails. If people want 80 points of IQ, they’re off looking at Elixir and Phoenix.
Likewise, I can say that “A language that doesn’t change the way you think about programming isn’t worth learning,” but who is learning Ruby and Rails in order to change the way they think about programming? They’re trying to bang out CRUD apps, and they don’t want to think about programming, that’s why they value a stable community with widely adopted “best practices.”
When you have a stable, mature language and framework, you spend more time thinking about your business and less time thinking about programming.
And thus, Rails (and sorry, but Ruby too) is not for people who want 80 points of IQ or to change the way they think about programming. And thus, in the sense of being influential, in the sense of disrupting anything or changing anything Rails is dead.
It has matured. It is mainstream. It is plumbing, it is concrete, it is rebar, it is infrastructure. Necessary and useful. But not something you want to spend a lot of time thinking about, just something you use if it suits your purposes.
That's not how IQ works. It's not additive.
It’s tautological: You don’t get a new perspective, or an advantage, by adopting the mainstream thing and using it the mainstream way with the mainstream best practices, carefully writing your code to be familiar to the mainstream programmers.
That’s not a bad thing, but it is a different thing from when Rails was first popping up in Reddit’s old days and HN’s early days.
IQ scores reflect the place of a particular person relative to the population rather than a simple score derived from performance. You may mean that IQ doesn't work like decibels, which are intended for the invariant expression of relative loudness. It's a complicated area and I don't think "additive" quite captures the property that you are saying IQ doesn't have...
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
Ruby seemed rather useless outside of Rails and I really, really liked what I saw in the Zen of Python.
Ie. less magic, explicit > implicit. Etc.
Programming languages take off because they show off their power by implementing a great library or by doing a better way of doing things which is what Ruby did using Rails.
The impact of Rails on frameworks/libraries in other languages is also significant since a lot of Ruby developers moved to JS/Elixir/Go and started contributing and implementing the best patterns found in Rails/Sinatra etc.
Django is merely one of the more popular solutions to a larger niche of what Python is used for. The closest equivalent to Rails in Python in terms of dominance is probably SciPy and even that comparison is a stretch.
The Python ecosystem is much more diverse than Ruby. Not because Ruby can't be used for anything other than what Rails is used for, but because there are simply more people doing the different things Python can be used for.
And ultimately the practical usefulness of a language depends not just on the suitability of the language itself for the given task but also on the availability of libraries for the common problems you encounter when solving that task. So the usefulness of a language (for a given task) is at least partially defined by how much it is actually used (to solve that task).
Every few years or so, a bunch of these articles come out shouting from the roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise some new framework, like Hanami, as the answer to all our woes, but they never seem to address documentation.
In my opinion, documentation is where Rails blows every other framework away. I have never been forced to read Rails' source code to understand how something works (I have read some of the source, but for fun, not out of need), and I can't say that about any of the other framework I've worked with. There's always some obscure method or class somewhere in them that does something unintuitive that I always have to look up. In Rails, finding the documentation on that method is as simple as a Google search, but in django, expressjs, or any of the others I've encountered, that documentation usually doesn't even exist at all.
Efficiency, scalability and reliability are all great, but when I'm starting a web app from scratch, they're really not that important. I can worry about those things once I have funding. In the meantime, I only need them to be good enough, and Rails defaults are usually good enough.
What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded. Once I'm funded, then I can think about implementing JRuby or splitting code out into microservices or rewriting with another framework, but by then, I'll have the money to take my time. Until then, Rails is the perfect framework for me and I'll keep using it until it's not.
It gets every...single...dang...decision...right. I may never use another language unless forced because it's what I've spent years trying to find.
No tool is perfect for every situation, and if you find one that is perfect for every situation that you encounter, then that says a lot more about you than about the tool.
I would be hard-pressed to find a case where you'd want to write your web or mobile backend in anything else. So yeah, I'd claim that it's perfect for every web or mobile backend.
Also, no framework is ever going to solve all of your "hard problems", and he didn't claim that at all. It's simply a much better base than Rails.
Short of complex calculations or extreme niche scenarios...it does handle pretty much everything in terms of "around web" work. For niche scenarios use what's appropriate but for the space that Rails has occupied in the general purpose realm it's wonderful.
More seriously, the community just needs to be a lot bigger before it's on par with the Ruby ecosystem. For example, there's currently no Elixir library that will inline CSS in emails before sending.
So "gets decisions right" sounds good as long as you agree with those decisions.
I happen to love working with Elixir and Phoenix. I find working with Ecto frustrating not because of the code, but because of the opinions the framework creators have made about where things go. They have good solid reasons for their opinions. And they are not wrong.
I just don't agree with them. And that's totally ok.
The balance on the database side of things has been most impressive because I didn't expect it at all coming from several years of Rails. In my experience to this point, the idea of letting your database enforce the integrity of your data was generally viewed as heresy. You could do it and the Rails team itself provided all of the tools to do it properly, but it seemed as if the community in general was totally opposed to it. The community shift towards embracing PostgreSQL so heavily has seemed to slowly be steering that trend away but there's still a lot of opposition. I've seen some tragic consequences because of those decisions in the last few years.
The balance encouraged in Programming Phoenix sets an excellent standard for a growing community.
The view + template layer has been a breath of fresh air.
Of course, to each his own.
Phoenix has me more excited about work than I've been in years though and I'm that guy that doesn't shut up about things that he loves. :-)
My experience with earlier versions was that you kinda had to piece it together yourself. Learning Play Framework was 10X easier for me since the docs were already there: https://www.playframework.com/documentation/2.5.x/Home
So I think maybe you're just not considering non-Ruby options. Which is totally your prerogative. Just saying it's not my experience. It may be the best Ruby framework. But that's a different argument.
> What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded.
Aside from syntax, I don't see any reason anyone would be faster with Rails. It's certainly not my experience. I worked with Ruby for 8 years. I've seen some very talented and very enthusiastic Rails developers. I've never seen one that could build an app faster than even an ASP.NET developer from years ago, and I certainly don't see any advantage over Play, which is generally more stable, much faster, projects generally have fewer dependencies.
The performance advantage of other platforms is underappreciated IMO. The fastest code is no code. If I can do something in Scala through brute that would be impractical to do within the request/response cycle in a Rails Action, that's a development speed advantage. If I never need to consider using some sort of background job service like Resque or message queue because I can just say `Future(someComplexOperation)`, that's a development speed advantage. If I don't need to tune my app or worry about my caching strategies because it's just that fast... You get the point I'm trying to make I'm sure.
Outside of performance, deployment (far simpler with Play), language syntax, and ActiveRecord (I'd just use the simpler, faster Lightbend Slick library) they're basically the same framework. Play doesn't chart much new territory. Sure WebSockets integration with Actors is lightyears ahead. But many won't ever touch it. There's some JSON stuff with validations that's very powerful, but embedding the equivalent of a JSON schema in your Action is verbose beyond trivial examples. I'm not sure how much use it gets.
I found Play much easier to learn than Rails (again, this was years ago) and much more consistent. Given the other advantages, all things being equal (familiar with both Scala and Ruby), it's tough to imagine many developers choosing Rails unless they were worried about externalities like building a team or something.
It'd be interesting to hear the thought process of such developers though if they're out there.
> People think that because something is "technically superior" everybody else should blindly adopt. But this is not how the market works.
This is really the citation describing the web development of the last 10-15 years. No surprise it comes from DHH.
This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity.
That rewrite is aimed at making Angular vastly improved - that doesn't equate to giving up on Angular, that is a poor analogy. In fact, Google decided to start investing vastly more resources into the Angular team, rapidly hiring and growing the team into a proper one, as opposed to it being a pet project of the Adwords team. In the next year or two, that ambition will bear much more fruit as mindshare grows with the realization of the technical problems solved & improved upon by ng2 - if React doesn't gear up to evolve, we'll probably see either a lot of defection to Angular, or a competitor that disagrees with the complexity that Angular introduces appearing to swallow React, just as React has done the same to grab disenchanted Backbone/Angular/etc. users.
Otherwise, the article does a good job explaining a lot of things, but it is very defeatist, as if it is futile to try to improve upon things. I can't say I agree with that sentiment, it goes against the heart of research/trailblazing/experimentation/etc.
It also makes some weak assertions, such as "One rarely benefits from big bang rewrites from scratch.", which is a generality being applied to every single situation, a fallacy. Confusing commonly accepted wisdom in development with an overextension of their meaning can lead to bad conclusions, as well as bad decision making.
So you were quick to call somebody wrong based on complete heresay? Do you have any conclusive proof that they use it? Gmail? Analytics?
One told me about the broken release at one point last year bringing Google to a halt until that got fixed, since Google runs off of the master branch of Angular. Google has a lot of apps, most of them internal (I have seen some external ones too, such as a Nexus site in the past, and Google Domains. Google App Engine and Adwords also use it, as given in talks in the past - the Angular team is grouped under the Ads group within Google). Your original question for proof was completely misguided when accounting for that - examples of external facing apps does not confirm or deny percentage, it was a poorly conceived attack.
Certain apps like Gmail/Inbox go through very long development cycles and have specialized requirements. An Angular team member has explained to me that sometimes some teams think they can do better with vanilla JS - none of the popular web frameworks really met Google's perf/business requirements for those behemoth apps, although with the way Angular 2 is shaping, it likely will hit the bar (the Angular team has managed to get a hello world app smaller than a react-based one, and this is before they extract out the template compiler to allow tree shaking of that for builds - very impressive perf numbers were also thrown at Google I/O last week). Google has a lot of resources they can throw at big consumer facing apps, so they can build homespun frameworks if they need to (for big sites like YouTube, Inbox, Calendar, etc.).
I should also detail that I'm not someone unknowledgable about Angular and how it is used - I am one of the biggest Angular experts outside of Google, a core maintainer of one of the three most largest third party Angular libraries & involved in another top three most used third party library (UI Bootstrap and UI Router, respectively) and a contributor to many projects across the ecosystem. I am very aware of all of the things that are Angular's strengths, and its shortcomings (especially 1, and 2 to a lesser degree...but nobody is really an expert at 2 yet, excepting maybe Tobias Bosch on the Angular 2 team with his crazy work on it).
I'd only start worrying if they move that away from Angular.
Of course, Angular is OSS and is likely to live on into obsolescence no matter what Google ends up doing with it.
Is there any large company or, heck, any somewhat organized group of people outside of Google supporting Angular or using Angular at a scale that warrants the investment of maintaining the project rather than migrating to a different technology?
Here's a piece to deflate any ego issues http://www.paulgraham.com/identity.html.
As one of those beginner programmers who had graduated from a development bootcamp, I fell in love with Sinatra much more than I did with Rails. Part of that love may be due to our curriculum...we have to master Sinatra first before you can start learning Rails. But I also liked the finer control that Sinatra provided to me. I suppose you can translate this to the current buzzword jargon of "hating Rails' magic", but writing out simple authentication using Bcrypt is just as much an accomplishment as using the Devise library.
But your bigger point still remains intact. Passion should take a backseat towards choosing the right tool for the job. If you need Wordpress, use Wordpress. If you need Rails, use Rails. And so on and so forth. I may not like a certain tool...in fact, I may hate it, but I should still go ahead and use it anyway. You're here to complete a job. And you should make sure you do it well.
What is bloat, and what is a useful feature you haven't quite grown into yet, is all a matter of perspective.
I haven't yet found a project where you know 100% of what you're going to need upfront, so having a bit of depth in the toolbox is serving me well.
Very few bootcamps get this right, I feel, but a few do.
Sinatra picked up the REST torch from Rails (and from Camping) and sparked a significant change in how web apps are built and a cultural shift from monolithic frameworks to micro-frameworks.
Node and Flask picked up from there, and gathered steam because both the Python and Node dependency management systems are less broken than Rubygems, allowing more practical use of smaller, orthogonal modules.
Now Elm and React are focused on improving the reliability and reducing the incidental complexity of web applications.
Aside from the occasional PR stunt rant from 37 Signals, Rails does not really have a thought leadership role in the development community anymore, aside from a loyal following of career rails programmers, who likely adopted Rails after v3 and would have been just as happy with nearly any monolithic framework and authoritative pundit.
None of this is good or bad. Who knows what the future has in store. Rails pre v3 inspired a lot of the thinking that came after, but has not really embraced any of the ideas that emerged subsequently.
I think the best analogy is Windows. It's a cash cow, it's not going to change quickly, and many people consider it the only sensible tool for the job.
How can one say "Rails won"? It's not like people will stop making web frameworks. Like any other software it will eventually be made obsolete by something newer and better.
Maybe I am just nitpicking.
as a nodejs dev, it is super annoying managing the asynchornicity of node and the horrifying dependencies. I suppose rails had stability issues as well. If you read rails is a ghetto by zed shaw, it is interesting (albeit super biased) look at how and why rails developed.
edit: As noted, elixir isn't comparable to rails the framework in that arena is phoenix which is similar (at least in function). Thanks!.
Edit: I don't mean comparable as similar per se, but that one set are languages and the other are web frameworks
Hilarious! :D
Now, that doesn't apply to any language other than Ruby. But this post might well be aimed at Rubyists exclusively.
It's become what J2EE was when Rails was new. Decades from now, even if it's completely fallen out of favor for new development, there'll be people getting paid handsomely to maintain legacy Rails apps. It's won an important spot in history.
But technology moves on. And just as the Java stack dominant when Rails emerged has lost ground to Rails, other non-Java stacks, and even newer Java stacks, is wire likely Rails will lose ground to other Ruby and non-Ruby stacks.
mount MySinatraApp => '/some_path'
Even after using rails for so many years, learning something new every day!
This is the real elephant in the room. Everyone is looking for the "next Rails." There will be no "next Rails" because the web is not what it was when Rails came out. It's not "dead" or "dying," but it is just not the same.
> Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy.
I always like to say Rails is for those kids who used to read the players' guides and instruction manuals for video games first, so they know all the secret moves and bonus areas before they even start playing.
Some people prefer the challenge and power of discovering and designing things on their own, and they are never going to enjoy Rails because they'll be too caught up negotiating with themselves about how they would have done it.
Yes Rails wins the popularity contest, but it doesn't mean it's the best thing for Ruby.
Someone once wrote something like, "An engineer is a person who can do for $1.50 what any damn fool can do for $5.00."
I admit I don't actually have much experience with Rails itself; we had a couple of Rails apps that, after a couple of months of painful deployment and uptime teething, we moved to JRuby running on the same architecture as the rest of our apps. Then, after a couple of years of deferred maintenance and no updates (and a long list of security vulnerabilities) we rewrote them as plain, no framework, no ORM, Java and Javascript.
But this quote rubs me the wrong way. Building small to medium web apps is what we do. A lot. We ought to be able to build them cheaply and quickly. But we also ought to be able to build them to be efficient and to not waste resources unnecessarily.
In my experience, Rails succeeded because it's easy to go from nothing to a demoable proof of concept. And the Rails environment succeeded because it's possible to teach someone up from nothing to building a pretty application in six weeks.
So why are we still fascinated with a tool that makes something easy that wasn't hard to begin with? That makes the first 10% trivial while leaving the other 90% alone, if not making it harder? That is optimized for the wrong thing?
And it soaks up resources like crazy?
The thing is, I knew fuck all about programming then and now, I have the luxury of knowing very slightly less than fuck all. Which gives me the perspective that this article has, rails is pretty fucking awesome for building a crud application that uses a relational datastore. The author indicated ~80%.
Wordpress is also something I swore off when I was learning because it straight up wasn't programming. I installed wordpress on a server for the first time last week to setup a blog. I browsed a few thousand themes, it took me a while to find a theme for a blog. The just a blogging platform is actually more ironic now, than it ever was.
So, I agree with the author the design patterns shape the community and then the community shapes the design patterns. You can pretty much build any type of app with any language if you are motivated and talented, however, from my observation, the following languages seem to give you the highest leverage in the domains the community has evolved them for:
PHP/Wordpress: Blogging sites & CMS building.
Node/JS: Applications and APIs typically with a noSQL database.
Ruby/Rails: Building CRUD apps with relational datastores.
Python: Data intensive applications & programming.
erlang/elixir: Never used this, but seems ideal for highly scalable concurrent architecture and highly scalable process choreography.
So in essence, I agree with the author. I would love to switch from node to Rails as I like the framework aspect where you can just get productive super quick. I also see rails as going away, so I wouldn't make the time investment. I think learning node was the right thing to do ~3 years ago, but I wish I spent another 6 months using rails and got really comfortable with it first.
> This is not serious programming/you aren't a serious programmer
fairplay. I am a jr. web developer, explaining my conception of some frameworks/communities/languages, so I agree with you that I am not a particularly talented programmer (it isn't my core skillset) and I am not solving hard problems in this arena(as I don't conetend that I am). I disagree that I claimed any of the above was my definition of serious programming. Of the hard problems I will work on/what I think needs to be solved, I have spoken of at length elsewhere.
> Wordpress is also something I swore off when I was learning because it straight up wasn't programming
> Python: Data intensive applications & programming.
I would love to hear your definition of programming.
Rails/Ruby was very popular bit it was a framework. You could do a massive amount with very little work. You could build an entire app without any knowledge of what Rails did for you under the hood. NodeJS was a developing technology of which I could gain massive leverage, both learning why asynchronous processes work(I still have trouble with these)/general programming concepts as well as double down on a front end language. The v8 compiler and ryan dahl seemed to provide a good avenue for which to learn lower level(at least than rails) about programming and it seemed to embody the unix philosophy. This seemed like a good place to be and I could grow within a community that was going to be influential. HTML, CSS and SCSS were pretty easy to learn, so by learning a single database technology and javascript I could be a full-stack developer. Not in the sense of how I would market myself, but that I could go out and build a full application if I wanted to and that was poweful and awesome from a learning experience. Given the proliferation of nosql The database, front-end, orm, and back-end were entirely javascript so I didn't pay a high context switching penalty.
wordpress: I dislike wordpress. I don't think it would make any sense to tell someone interested in programming front or back end software to learn "wordpress". Wordpress is a great convenience for setting up a blog, but I presume they have a CMS as well. I don't know much about it, only doing the most basic PHP stuff, but PHP & Wordpress seem to be synonymous with client facing software that requires a CMS/non-technical user to make updates.
python. I mean, python at least from my understanding is a great language for processing data. It is why tensorflow ships as a python library and numpy is used for a lot of data work. The communities using R and python work with data at scale and thus those communities have developed a lot of tooling to accomplish this, not that this stuff needs to be done in python, but machine learning, textual parsing and classification libraries and some NLP stuff all seem to hit python first. However, oython does have a great community writing secure applications. Django and Flask, sqlalchemy ORM as well as zeroDB exist and there are communities using python for apps, data parsing, and microservice deployments.
However, I define prgramming (like most people) as a schedule of television or radio broadcasts.
"Going away" was said about .NET and PHP and they don't seem to be going anywhere, albeit they are less popular than they use to be.
Too many discussions on HN have this paranoia lurking around of whether or not "I chose the right path". I find it unhealthy, and find that the longer life of a product exposes the weaknesses of any language/framework.
However, I totally agree that the longer life of a product exposes the weaknesses of any language/framework. and there are multiple paths. Just that, if you want to get good at writing software you probably need to pick a starter language with a versatile community. People still write cobol, and wherever there is code in production, there will be demand for a language, but .NET and PHP are probably not growing in demand. I actually don't know about .NET tbh.
However, there is such thing as choosing a path as, without extensive time investment, skill and knowledgebase, it would be difficult to be a truly capable python, .NET, javascript and rails dev.
It would be wise to be capable in those languages, but to be a master or attempt mastery of the one most likely to embody your interests/career would likely be a better move than being able to be less than mediocre in numerous languages. I think we are largely in agreement, and I hope I didn;t mischarachterize you.
I think rails is cool, and I now regret not learning it as I do like the scaffolding nature and I am sure I could pick it back up quickly, I just do not have a need to right now. Elixir looks super cool though and if I do learn a new language that is markedly different it is a toss up between Go and Elixir. I am messing around with python right now, but javascript and ruby are pretty similar, and pyton seems fairly similar. A functional language or a compiled language will be a radical departure from what I am used to.
Enterprise only cares about Java and .NET as standard backend stacks, regardless of the technology of the day HN posts how everyone is doing Go and node.js.
* How much it would teach me about programming/software design, e.g. just as a general learning excercise?
* What does Java lend itself best to/is a typical set of programs a beginner could build after say 1 month?
* Is google planning on phasing Java out and using Go?
2. I'd say the set of programs can be pretty sparse in that it doesn't tend to play well with its native computer environments (partially be design), so it's more work to generate stuff with a GUI, somewhat more work to handle CLI programs (but not that much more), and it has an interesting set of web tools that have hopefully been updated in the 8+ years since I played with them.
3. I have no idea what Google is doing, but it doesn't matter as Java will live a very long life in Enterprise land if nothing else.
For example, most languages eco-systems lack tooling like VisualVM, Mission Control, JITWatch on their canonical implementations.
http://www.oracle.com/technetwork/java/javaseproducts/missio...
https://github.com/AdoptOpenJDK/jitwatch
Also note that although many seem to be focused on Java being Oracle JVM or OpenJDK, there is a pleothora of JDKs both open source and commercial to choose from. With many other features.
For example, most commercial JDKs support AOT compilation to native code.
Or targeting micro-controllers with a few hundred KBs.
Also Java gets bashed by being all about a specific OO model, but VB.NET, C#, Eiffel, Smalltalk follow exactly the same model.
> Is google planning on phasing Java out and using Go?
Until they embrace Go in Android, ChromeOS, their Google Developer SDKs and Google IO sessions, I would say no.
2. Im going to read that as "... 1 month after finishing studies".
I will recommend starting somewhere where you get good colleagues. When I finished school I was sure I could never work with Java: it was hard and unforgiving compared to VB and PHP that I had picked up on my own.
After getting introduced to ides and working build systems however I was starting to get work done within a week and within a year I was confident enough to make a real difference.
Also I picked up a feel for just how annoying it is to be left with maintaining code based on abandoned commercial tools (old Delphi code).
3. No idea, but IMO no way banks are leaving it anytime soon so plenty of jobs and momentum for the next few years:-)
I'd say you should start in a good team anyway because real life experience IMO is crucial and getting on a good team is a way of getting it fast and as painless as possible (I.E. without breaking your bank.)
If you just want to make "something" go with whatever is less friction for you (for me it was php), just be prepared that there will be friction in any language as soon as you step outside of the tutorials.
Also keep in mind that if you get a good job you can do quite a lot on your spare time. I used to code a utility program in php while commuting. It never became a commercial success but a rewritten version became a major hit with the church I belong to, was maintained and in use for years and gave me both experience in sw architecture as well as bragging rights in job interviews for several years. (Oh and it totally helped in getting my head ready for my paid work in the morning as well as unwinding after work.)
But I also think Java has come a far way towards beginner-friendly. If you do just accept that in Java land IDEs are a must. Getting used to IDEs was were Java "clicked" for me. Use either Netbeans (all features free, my preferred choice), IntelliJ (lots of features free) or Eclipse (all features you'll ever want is free but takes some getting used to, I would never picked it as my first IDE if it wasn't the preferred choice on my first team and they where happy to help me up to speed.) And dismiss everyone who tells you that one of them is crap or way better: it is just a matter of preference in most cases. (Notable exception: android development where IntelliJ is the officially supported alternative.)
Also learn to use Maven or gradle.
Great thing about Java is that it lets you solve wide variety of problems, right from Mobile, to Desktop to Big Data. For Machine Learning, Image Processing, some of the best libraries and SDKs are available in Java.
It's a good skill to know which I recommend to all new programmers. One important thing I like about Java is that it's low on features and it's possible to master almost all aspects of the language in relatively short period. This is not possibles with languages like C++, C# and Swift. I think simplicity is one of the reason Java and Go are popular.
Erlang's primary reason for existence is fault tolerance. High concurrency and scalability is just a bonus. Consider hot code reloading, supervision trees, links and monitors, D/ETS and Mnesia, location-agnostic message passing. These have nothing to do with scalability. You use Erlang when you absolutely have to have the system continue to work 24/7/365 in perpetuity even in the presence of software errors.
so, we won't be jobless anytime soon.
As Larry Wall and countless others have noted, great programmers are creatively lazy. Mediocre-to-average devs are lazy in less creative ways, like sticking to one language/toolchain for years and not diversifying. Anything that lives, including your career, either grows or it dies. Anything that grows within an impenetrable walled garden will eventually crush itself to death within those walls. It's sad when I see people do that to their careers, and over nearly 40 years in this craft, I've had ringside seats to multiple such bouts.
I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in my area. I work at a lower level; robotics, image processing/analysis, and general systems level stuff. We worry about what technologies we use for a given task as far as it impacts our design goals, i.e., "which technology is best suited for the job" (and there are more options nowadays than there used to be). Our customers couldn't care less about how we got there as long as the final product kicks ass.
Once we arrive at a conclusion we move on and spend the remaining 99% of development solving actual problems. Hard problems. Often times unsolved problems. Our number one priority is reliability and accuracy (ok, that's two priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant. What matters is that we built a system which works as it is supposed to and was engineered correctly.
I don't understand this 'programming for programming's sake' mentality. At the end of the day these are just tools, not an end goal. Help me to understand.
Human nature, maybe?
People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups.
My favorite example is the following trivia from the "Planet of the Apes" movie:
"During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."
No, not really, and I don't think I assumed that at all. I think it is objectively true that debating the merits of e.g. Python v Ruby for years on end is an utter waste of time. This is not engineering, it's vanity. I can get behind the occasional spirited debate. Of course there are pros and cons to every tool, and we should know what those are, but at the end of the day that's all they are; tools. They're middle men in the problem solving process, not the end result.
BTW, your current web protocols and frameworks are going to change again, just like your decrepit old desktop technologies did. Be prepared to denounce your current toolset and fervently embrace another in the near future.
I honestly think this is it. Webdev has an inordinate amount of "let's rewrite it... again!" But the thing that really cinched the webdev community isn't ready for primetime was the whole left-pad debacle. Auto updating of dependencies is bush league bullshit, and the whole rotten edifice came predictably crashing down because of it.
For some, the tools they work with doesn't matter or doesn't affect their enjoyment. Great for them. But for me it does. Working in a language or with a framework I don't like is a constant stress factor because I keep hitting things that annoy me.
Personally, I don't touch Python projects if I can avoid it, for example, because I don't enjoy working with Python. It's got nothing to do with objective issues with it, and everything to do with subjective issues that affect my enjoyment. If I work with something I enjoy, I will be more motivated and put in a better effort, and will overall be happier.
> Be prepared to denounce your current toolset and fervently embrace another in the near future.
Awesome. While I like my current stack, I've changed it many times during my career because I found something I liked better. And sometimes I've had to put my preferences aside and pick something for more pragmatic reasons, and that's ok, but I most of the time have the luxury of being able to turn down work if I don't thnk I'll enjoy it.
So you're almost never spending 99% of your time solving unsolved, hard problems. You're building custom solutions to relatively common but special-snowflake problems. And in that context, you need a framework because in effect you're building a 1000 hour project but only spending 40 hours doing some configuration, customization and polish on top of a framework. Could you spend 1000 hours and build something from scratch and forget a framework? Sure, but no one wants to pay for that. So the framework you use is the giant's shoulders you stand on.
Rails didn't beat PHP and Java for webdev because hipsters think it's cool. It's because developers delivered projects better and faster with Rails, because it lets you spend less time re-solving the same solved problems which still comprise a lot of modern web development.
That's a fair point; my project plans are usually measured in years, not hours. Of course there is ongoing maintenance, but that's not where I spend most of my time.
I didn't mean to imply that tools aren't important, or that we shouldn't care. We absolutely should care, and I do as well. The difference is that I don't feel the need to spend copious amounts of time defending my tools, or debating their merits with other people who will never agree with me.
I evaluate them, use them, and move on. They are an integral part of my process, but not nearly as important as building something that solves real problems.
It's the same old issue of religion v enthusiasm, belief v fanaticism. That line gets crossed too often and it's just a waste. I think some lose sight of what's important.
Now, sometimes, they have a legitimate need to have it integrate with a larger system and using that tool has external advantages. But most of the time it is just a vague notion that if it is in WordPress it will be easy to use, cause you know, anyone can edit a WordPress site. But when you bolt a hundred plugins and custom business logic into WordPress, it makes no difference that it has any easy blog editor. That should have been a separate project to begin with. Half the time they have built 10% of what they need with a dozen plugins, think they are 90% done and that I can just make the rest of it work. This because someone told them there were plugins that could do everything they needed in WordPress and with WordPress they'd get good SEO.
The point is that if we want to use a particular tool, we better evangelize for it, because clients never want something built in a framework they haven't heard of. It's not even irrational for the clients, since 50% of the time their developers disappear before the project is done and they have to find someone else who can pick it up and finish.
"Python, Java or <something else>" Python and Java are relatively opposite ends of the web dev spectrum, and he didn't code so it was likely based on rants from the programmers around him.
In the end his project failed because he couldn't find any Django devs to continue the project for a relatively low wage. He might have found some PHP devs if he had chosen that.
Of course - the counter-argument is "a good PHP dev is no cheaper and just as hard to find" but for maintenance tasks you might only need an average (or even mediocre) dev - and it's a hell of a lot easier to find an average PHP dev than an average (insert less popular choice here) dev.
doesn't mediocre mean average?
"good < average < mediocre < bad"
sounds about right to me.
It also is if they don't have a years-long working relationship with you, because who is going to maintain all of this when you're gone? At least if they have to dump your work and build a new theme, they don't have to worry about figuring out a whole new data model (most of the time).
WordPress done the right way uses plugins sparingly to get the job done, outside of obvious ones like Advanced Custom Fields Pro and Post 2 Post Links.
WP isn't bad per-se, it's just the majority of people who work on it (and let's be honest, who built it) are/were rank amateurs.
From a data standpoint, yes, WP is bad. Really bad. The poor quality code base of WP is only one half of the equation. The other half is the downright awful, novice database schema that ships with it. I've never seen a database schema that is so tightly coupled with the parent application that it essentially hijacks your data into always needing itself simply to extract and render data. WP takes the "relational" out of relational database and flushes it down the toilet. To add to the mess, instead of fixing the rot of its database schema and data handling functionality, WP developers, in their infinite wisdom, merge a woefully incomplete, faux-API system into WP's core, thereby further sealing the door of ever having a clean, thoughtfully designed database that one can access outside of WP and PHP.
We don't give credit to how good some plugins are, either.
In my current web app I've had to add user-defined custom fields to a few entities. It's been a nightmare (Symfony2's form library isn't designed with this in mind) and the user experience is nowhere near as nice as ACF.
And for web apps, the user experience is as important as what it does. I wouldn't want to build this application on WordPress, but having components like ACF already present, so I don't have to reinvent the wheel, is making me seriously consider it for the next project.
To be competitive, web devs need to be working with the most popular framework, which has the most modules which are maintained (for stuff like "log in with facebook" or "publish photo to twitter" or "get weather for visitor's geo-ip location").
All this pre-packaged functionality does require some time to get familiar with, it's an ecosystem on top of a language with many DSLs.
So they need to make their team win, or join the winning team early. Or else they don't feel like they can compete.
It's a really big marketplace for web sites/apps out there, many small businesses get new-from-scratch websites every 2 years or less ... new shiny design drives consumer interest, it's not like they could afford for the old one to be maintainable anyway.
All the orange crops just froze over from the chills running down the backs of all the Agile\Lean practitioners.
I despise Ruby, PHP, and Java, but there is no objective argument that Ruby has "beaten" PHP or Java. It hasn't even beaten Python. It's tiny compared to the largest back-end languages.
Edit: evidence below:
- Ruby is used by 0 of the top 15 most-visited sites[1] (Twitter doesn't use it anymore). Java is used by 7 of them. PHP is used by 3.
- Job listings on Indeed asking for Ruby skills are far behind Java and PHP[2].
- W3Techs shows that 82.2% of all websites reporting their backend language are using PHP. Ruby is 0.6%.[3]
- Ruby is not even in the ballpark of Java on Github. It has a similar number of repos as PHP.[4]
1. https://en.wikipedia.org/wiki/Programming_languages_used_in_...
2. http://www.codingdojo.com/blog/9-most-in-demand-programming-...
3. https://w3techs.com/technologies/overview/programming_langua...
PHP developer salaries lag well behind market average for pretty much the same skillset. The tooling around PHP on the web is a wreck because you get what you pay for. Java isn't that much different -- I see tons of Java jobs I don't want in NYC for $60k wanting 5 years experience.
Who is taking all of these jobs we don't want? More is not necessarily better.
The real reason PHP is everywhere is because PHP is everywhere. It used to be that the only major host that didn't offer it was Google App Engine but that was resolved ~3 years ago. Since it's everywhere - and the vast majority of people don't care about the technology under the hood - they just choose the first thing that works.
Odds are that's a one-click install of WordPress. They do that. They add their content. Then they move on to their actual business.
Other than software developers, people don't care about the code under their website as long as it a) keeps working and b) no, that's it. Even security is an afterthought for most of these people.
The majority of projects are not the next twitter or facebook, but something with a limited scope to be done as fast as possible
If you look at the existing web frameworks, how many of those are RoR clones? That's what I see when somebody says "Rails won".
It should be more self-evident now.
When there are many tools which meet the minimum requirements for doing a job, then the focus becomes not on which tool can do the job, but which tool you feel does the job the best (or you enjoy using). Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker.
You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.
True, but I do my homework too. My code needs to be maintainable for the next guy. We can't invest inordinate amounts of time on V2 where it isn't necessary. I don't want unrelated parts of the program breaking because I fix a bug. The next set of features should be easy to implement from an architectural perspective. All of this is important to the customer and my business.
I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.
Sure, but that line is in a different place depending on how important the tools are. If you're doing a project where the functionality is 40% custom code and 60% tooling, that will naturally give you a very different attitude to a project where the functionality is 1% custom code and 99% tooling.
Is that actually true? I can't think of a single example of such an argument. I have heard recommendations, and heard various trendy tools being promoted (at least for music), but never an argument.
I think it has to do with transferability of skill. In music, carpentry, and painting, skill readily transfers to different tools even if it causes annoyance or a stylistic change in the result.
The stakes are much higher for web development; at least that's the perception. Skills probably transfer better than people think, but it's scary to have 10 years of experience and a high billing rate and then go back to "hello world".
It's much more comfortable to try to promote what you already know so that you don't have to do that. And it also avoids wasting time on a new framework that seems promising but never gets critical mass.
The fundamentals are transferable, I don't even mention specific technologies or stacks these days if I don't have to.
And lots of people hire based on the assumption that expertise in a particular stack is the most important thing (perhaps in part as a result of the preceding point).
But there is a big difference between discussing tools and arguing about them like your career depends on a particular opinion being right.
The kind of tool-centered identification and tribalism seen in large segments of the development community is not only rare among other professionals, it's seen (usually correctly) as a sign of being an amateur that doesn't know the craft well in other fields.
I see a lot of the same thing when people argue over programming tools. Just go build stuff in whatever tool you feel comfortable in. Do not lose site that building stuff is the goal, not using some tool.
Seems everyone's trying to squeeze problems into fitting their solution/framework rather the other way around.
Blog posts are a way of status signaling but also of fitness signaling. People that have the capability of always learning new things and writing about them should be really good programmers while lower quality individuals can't afford to keep up and drop out of the game. Only the former are able to reliably secure mates and reproduce, thereby perpetuating the cycle.
Start again. Burn it all down, and do it properly this time.
Because writing web apps / CRUD apps is soul-destroying, boring, and always perceived by the client as easy (no matter how much business value they bring) so there's pressure to do them fast, as others have said. Any distraction is welcome, and any framework that makes the task less painful is welcome.
Both of which foster this fairly pointless set of discussions :)
32 year old curmudgeon here, in the middle of a large web app project...
Almost every language provides you with sufficient tools for writing algorithms, doing calculations, storing and accessing data, but almost none gives you solutions for avoiding mess.
There are many ideas on how to avoid mess but none of them works and people are left to their own devices to figure out how not to get lost.
That's why webdevelopers are so fascinated with frameworks. They promise solution to their one hard problem. And some even deliver it to a degree.
Kind of a strange way to put it but I think I agree with the gist. Scaling is the web's hard problem. Building an ever expanding list of features while measuring if users like them and delivering them via cheap computers and tiny pipes is surprisingly difficult. Scaling a rigidly defined web system on it's own generally isn't so hard at this point. One off Twitter clones with a few of T's killer features can be knocked out in a few days with pretty good load scaling properties. But scaling the codebase and architecture from 1 dev, 0 users, and 1 OK feature to XXX users and YYY features users love is really hard to get right. Ideally the 100th feature is as easy as the 10th and you can just add more engineer hours, but more commonly it seems to get exponentially harder to add features as the codebase expands.
> At best you can avoid shooting yourself in the foot
At best we can keep our systems simple, agile, and cut bad features as quickly as we test new ones (every damn day!).
PS: A single 1ghz CPU with a very fast connection could serve the simplest possible webpage to every single person on the planet in less than 1 day. Scaling is only an issue as you add complexity.
> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it.
> We worry about what technologies we use for a given task as far as it impacts our design goals
I don't see the difference.
Basically stuff like Image Processing is trivial from an software design/architecture point of view since it's 90+% math and computer science so the the software 'architecture' tools don't matter. Non-trivial web apps on the other hand are 90+% an architecture problem so there those tools matter a great deal.