> RoR is an extremely powerful tool

The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application, and then I would end up with something that felt like a hack to circumvent Rails' default behavior. That, or I would want to do something which is very simple conceptually, but I would have to add some unnecessary complexity and/or ceremony around it to fit into Rails' interfaces.

Also I'm not a huge fan of the Rails' model of having everything from request handling to routing to DB access in one big framework. The needs of each application can be quite varied, and I'd rather plug whatever components together I want to for a given project than to be limited by some outer structure.

> Ruby statements look more like natural language statements than those in other languages

The more I program, the more appreciative I am of a strict compiler. What I've always found with interpreted languages is, while they seem convenient at first, projects inevitably start to slow down under the accumulated "squishiness" due to lack of strictness. I find it's pretty easy to get used to syntax, but there can be a lot of hidden "gotchas" in interpreted code which tend to outweigh any benefits.

Also as far as the natural-language-like syntax, I find that Swift offers a similar benefit, with the added benefit of strong compile-time checks.

> The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application, and then I would end up with something that felt like a hack to circumvent Rails' default behavior.

As a Rails developer for over 10 years now, I definitely agree that going off the rails (see what I did there?) is nearly always painful. Especially if Rails doesn't totally click for you. I can see why that would drive a lot of people totally nuts.

I think that if Rails really clicks for you then it's possible find a way to solve those problems within the same sort of way of thinking that Rails is coming from. But not everyone works the same way, and that's ok!

> Also as far as the natural-language-like syntax, I find that Swift offers a similar benefit, with the added benefit of strong compile-time checks.

Life is short, if at all possible write code in whatever language makes you happy. If that's Swift for you, well then cheers!

> The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application,

I think this is the first part of the insight needed.

The second part, which by far the most productive full stack web dev I know has got completely nailed, is that mostly the right answer to that is to push back on the business/requirements with a good alternative to what they _think_ they want that _is_ in "the blessed path".

A good Ruby dev who has the ability/skill/respect to do that is maybe the closest thing I've ever seen to the mythical "10x engineer" on a consistently repeatable basis...

And this goes for other things besides RoR too, I've got a Python/Django guy who can build amazing stuff in weeks, but he'll tell me why I am not getting what I asked for but this other thing that does the same job (sometimes better) because "that's the right way to do it with Django".

I guess the problem I have with this is that in other toolsets, I can achieve exactly the result I want without compromising for the tool, so Rails and similar frameworks feel restrictive in this way.

Perhaps you should do a bit more reading on these tools. With life experience you will learn that these tools really help you get your work done, and right now you're likely solving what they have already solved for you. Rails is a highly modular architecture with some sane implementations by default, but I promise you there are many pluggable pieces that exist that do just about everything you could ever dream of.

I don't like the suggestion that if I don't care for rails I must be using it wrong. I have worked with many technologies over the years and I know which ones I like and which ones I don't.

I suspect it is an issue of preference. I am sure it is possible to be productive using Rails, but the interface style and overall structure is a bit heavy handed for my taste. I prefer tools which stay out of my way and I'm not terribly fond of working inside an "ecosystem".

I am starting to ignore syntax when I read code now. It doesn't register in my mind most of the time unless I see a sudden paradigm shift or odd dependency behaviour(I think this causes me to snap more than language syntax. Dependencies don't have clear code navigation guidelines, proper structure or docs than the language they are in).

From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. If there are more js developers, then that means you can hire more for less overall. Obviously things are more complicated.

If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Anything trendy will get too many breaking changes or fixes. Heck, having visible source code can be liability too in future. I may as well choose something that will be hard to decompile. Not to mention the external dependencies that you will need to mirror or even maintain.

I think most businesses that are dependent on tech can be divided into short lived and very long lived ignoring certain type of software and industries.

For short lived businesses or customers, your stack shouldn't matter much compared to the responsiveness of development. What incentive are there to provide quality software to companies that will live 5 years at best? (Note - quality here refers to ideal stack/code that programmers expect. Eg - unnecessarily performant, kubernetified, micro architecture)

None.

For long term businesses, software is an ongoing cost. They can afford to renew their software every 10 years so why should you write something that is expandable, easy to migrate and another team to take over. Beside, their requirements change drastically over time. It will end up being a monolith.

I don't have to work right now but if I ever do, I am gonna work on the interesting bits while hiring someone in a third world country to outsource parts that I don't from my job.

I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.

I like your post a lot. I don't disagree with anything in it per se, but I think there are a couple qualifications worth making.

> From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price.

That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there.

> If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons.

Roughly speaking I agree. However, two comments:

1. This is a very broad critique. You can say exactly the same thing about python, bash, perl, etc. It applies to Ruby, but it's not endemic to Ruby.

2. Not everyone is looking at the same time scale. If you are building software for an enterprise that's been around for a few decades, I can totally see the argument for eg Java. But in many cases, the landscape 10 years from now is the wrong thing to optimize for. For some, building a software product that actually lives long enough to have dependency issues is an amazing problem to have.

> I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.

I could have been more explicit in my original post. What I'm lauding about Ruby is more than pretty syntax. I'm arguing that the the whole language dovetails really well with the application framework, both in terms of routing and in terms of db operations. Particularly the latter. There was a recent thread here that was something like "What should I learn in 2020?" and hands-down the winner was "Learn how to use a DB." I think that Rails is a powerful way to approach this.

Yeah, my original comment is disorganised. Essentially, I meant to distinguish between two business sides (there are others) rather than making point for any language or situation.

The compiled language part was an example to long standing businesses where you are aware of many details like software sweeping cycles, culture, goals, requirement changing tendencies, etc.

> That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there.

Yes, see this puts you into short standing business bucket.

> Syntax doesn't provide enough value on its own in a general programming language.

I actually didn't mean this literally. I think of tools as a means to move around and give shape to a product, team, business or yourself. Syntax can be relevant to that while relying on syntax in seldom is a bad idea.

Examples:

People who like ruby syntax and are attracted to it is a different bunch than those who are attracted to java. While you may prefer to use java, you don't necessarily want programmers attracted to java in your team.

Using statically typed language may provide more friction to think about the structure or slow you down a bit which may be important for shaping the product.

In short, you don't want tools to decide your fate. Sometimes, using less than the 'best' is a better choice.

> I think that Rails is a powerful way to approach this.

I strongly disagree with that thought. AR is the best tool to get around properly learning SQL. That's both its greatest strength and it's most fatal weakness.

IMO it's still worthwile learning AR after learning and understanding SQL, but the other way around will just be a headache.

> From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price.

I honestly think there's a sweet spot. I have seen brilliant people expertly build massive systems in Java, but there is no doubt in my mind that if they had attempted those in almost any other popular high level language, they would have been more productive. I know I've been very productive in Clojure, for things that I can afford to write in it (performance-wise), and much more productive than I have been in languages I have a lot more experience with.

Definitely.

Your comment proves my point though. You don't need experienced 'java' programmers but simply experienced programmers.

The more time I spend in the industry, the more I tend to believe you should just hire programmers who have a demonstrated ability to produce a high-quality product. Any product. Programming languages and domain-specific knowledge can be learned quickly, and all the best practices and process controls in the world can't replace talent and experience solving problems.

Those things can sometimes be learned quickly, but it takes time. If your company can't have, or doesn't want, productive developers to be spending a lot of time mentoring, then it can be worth it to hire people trained in your working language, possibly even familiar with your style of program or library ecosystem (if you have one of those).

I think focusing on the syntax level is a bit superficial. While Ruby (especially in the context of RoR) lends itself very well to making DSLs and making abstractions, and thus writing superficially good looking, concise, easy to follow (on a syntax level) application code, it really breaks down when the abstraction does not work perfectly the way you want it.

If you have debugged a Rails app and tried to find where in the 10 level call stack a side effect is introduced, knowing that at each level a 'method_missing' could've changed things, and thus you're really looking at a non-linear call stack since each function call can branch out, you'll know the beautiful looking syntax is not free and in fact very costly.

And don't get me started on poorly documented (if any) CoC (black magic)..

I think the syntax is very important. It is the aesthetics of a wood floor versus a vinyl floor. Sure, both may get it done, but clean and beautiful syntax that resonants with your brain makes the job more delightful.

> And don't get me started on poorly documented (if any) CoC (black magic)..

I have never liked the idea of (framework-enforced) CoC.

First of all, RoR isn't as CoC as it claims; many things can be configured, which defeats the purpose entirely, and all that remains is the a CoC philosophy.

If Rails would actually enforce CoC, it'd be too restrictive to build anything new with it, so true framework-enforced CoC is not really viable in the real world.

So what people really mean when they say is "Convention over Configuration" they really just mean that the framework doesn't generate a default configuration, but instead the defaults are all encoded within the framework code and its documentation. This is bad. The only benefit is that an empty project looks less cluttered, but that is really only an aesthetic advantage to draw in new users.

The downside is that the project loses documentation. Ideally, I want to jump into a new project, open a config file and be able to have a look at all of its configurations. In Rails I can't do this; I have to either memorize or look up the defaults and then check if they're changed in the current project.

Ultimately, its idea of CoC makes rails easier for starters to get into, but a total pain for people who don't care to get into it and just want to make some specific change and for anyone with a specific goal in mind that doesn't align neatly with how the framework thinks you should do things.

I agree with you on the comment about abstractions, but I think I would rather have Rails with esoteric code than something less "conventional" with esoteric code.

yeah, esoteric is bad, whether Rails or others. But that's just my impression with Rails, and I'm much more comfortable using other less magical libraries. I guess Ruby is just too good at making abstractions, and I tend to believe that 'making and using abstractions feel great and productive, unless it's made by others'

CoC means many things. What do you use it to mean here?

Yeah, sorry for the abbreviation. I meant 'Convention over Configuration'

Probably "convention over configuration".

my best bet: Convention over Configuration (had to google tbh)

I don't understand why the Node community doesn't have an analogous to Rails. I love the Ruby language, but given that much of my work is on the front-end, I'd love to avoid context-switching between two languages for my stack. Also, with some requirements like server-side rendering, being able to natively do that in my web server is nice. I haven't used Rails since the early 2010s.

Because Rails is a huge mega framework that tries to do everything in a very opinionated way. We need guys love to compose bigger things out of small things. :-)

They do have Sails but it's nowhere as good as as RoR. At least prefer something fast like Fastify or Koa if using Node.js.

Doesn't this kinda prove the point that Node.js is only more performant when used with micro-frameworks like Express? That Sails failed to match Rails should tell you something. A fair comparison with Express would be something like Grape or Rhoda. Node.js itself should be compared with Rack which is pretty fast.

The fact that Sails never caught on to match or exceed Rails usage doesn't mean the main problem was primarily performance. Rails, for one, has a huge incumbency advantage (2004). Second, Rails is just easier than throwing together a pile of NPM modules. Imagine if you had 0 knowledge of the NPM ecosystem. It'd be quite a lot of decision making to evaluate a basket of modules that could emulate all of what rails provides.

Thworing together a pile of third party NPM modules is a bad decision anyway. This is precisely why we picked Mojolicious to use as a Perl web framework: minimal dependencies, minimal breakage, reimplements some functionality. It turned out to be a good decision as it's also actively maintained compared to the others.

Sails was not in a good way when I used it...

So on one hand, adonisjs, feathers, etc., but a lot of nodejs users consider express+npm to be their "rails".

I just didn't like the tooling,it's quite messy. Python is similar enough, I would hate to do things in both.