But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you.

With a framework, "works for me" is a perfectly valid reason to keep using it and to dismiss criticisms with. That's the whole point, to get you up and running with as little fuss as possible.

I personally hate CSS frameworks, I'd rather retain more control over the markup and selector semantics. That's a choice I make, and I'm aware of the tradeoffs. I would not make the same choice with web dev, because choosing the other side of that tradeoff involves way too much work.

But I'm a working coder, I'm not trying to make my mark on the world. I just want to get shit done and move on. Solnic obviously wants to make something bigger than just a website. He's looking for a bluer ocean to tame. Which is cool, we need all kinds of coders.

What this is really about is that Rails isn't for him. I can accept that. But his rationale is all wrong, it expects Rails to be something it isn't and never could be. Rails is absolutely the best at what it does for the kinds of coders it's intended to do it for. It tracks the state of the art of web development and boils down most of the complexity with user-friendly abstractions.

It's not terribly flexible, but Rails doesn't want to be flexible. It wants to be productive. He wants to go help build the next Rails. Godspeed. I hope he succeeds so that I can go use his framework when it's finally ready in 10 years or so.

You are more than free to re-implement anything Rails does yourself and release it as a gem. Modularity and flexibility are built right in.

And right here, you also mentioned:

I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you.

So which one is correct here?

Oh please stop treating your favorite tech like a religion.

Who said that? Who carved that in stone? There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries.

This is just repeating "this is how it always used to be" as an argument.

>It's not terribly flexible, but Rails doesn't want to be flexible.

That's his whole point.

You certainly can use each individual part of Rails without having to bring in the rest of Rails. I bring in ActiveSupport all the time on non-Rails projects. For ORM I prefer Sequel, curious why solnik didn't mention Sequel, the creator of DataMapper even said that Sequel was everything he wanted DataMapper to be and I can't help but think that played a big role in the decision to not continue developing it.

You can use Sequel in Rails, I personally prefer ActiveRecord as I'm not aware of a Form Helper gem that works with Sequel, though to be honest I never really looked. Way more people use AR than Sequel, so Stack Overflow debugging goes much smoother.

I'm not saying he's wrong for leaving the Ruby / Rails ecosystem. I'm saying his stated reasons are inconsistent with his course of action. I'm fine with his real reasons, I just wish he wouldn't frame it as a slight to Rails.

From the article:

> It would be unfair not to mention that Sequel showed up already around the same time and till this day it’s being used way less than ActiveRecord despite being a superior solution.

Just because something was called "Session" (ala Hibernate) instead of "Unit of Work", people would claim it wasn't "pure".

The only real compromises for purity were for performance. You saw the same thing play out with ActiveRelation. Ruby is (or was at least) just too slow for complex patterns unless you wanted to pay a huge performance penalty. The kind of slow that materializing 10,000 models in an O/R Mapper would bring your app to it's knees and use hundreds if not gigabytes of RAM.

And since a large reason for writing DM in the first place was AR's miserable performance at the time, it needed to be fast.

Most of the community wasn't that interested in closing open issues. Not that I blame them. It's not fun. But I was burnt out.

During the end, ActiveRelation started development, making many of the same mistakes early DM did in the quest for purity. By that point I just wasn't feeling it anymore. I'd spent orders of magnitude more effort on writing an O/R Mapper than I'd ever hope to recover, and I felt like some of the ideas were fundamentally flawed. So I moved on.

If I were still doing Ruby, I'd be using Sequel though.

The convenience methods were just wrappers. Earlier versions were even more true to the PoEAA version of a DataMapper with a Unit of Work in the Session class.

Turned out this was a bad idea if your primary motivation is performance.

The fact that it didn't bother to abstract away DataObjects was by design. Nobody would claim NHibernate (of the time, 2.x) wasn't a Data Mapper implementation just because it didn't have an adapter for treating an XML file as a database. That's a parlor trick.

The real effort is in making it work and making it fast. Porting Java designs to Ruby just didn't scale in the Ruby implementations of the time and conscious decisions were made to ensure DM would actually solve the problems it was developed to address (#1 being performance as I had a large set of data to migrate that initial experiments with AR projected to take a month(!)).

The primary concern turned out to be Ruby method dispatch performance. The shorter you could make the stack, the better. Since loading 1,000 objects might be operating on a 10,000 row set, and another order of magnitude more fields, the materialization pipeline had to be streamlined as much as possible. (AR implemented a nasty abomination of a hack for this by round-tripping to the database multiple times). When it's faster to round-trip to the database multiple times than it is to iterate a large object in memory, you've got a real problem.

The lazy loading, explicit fields, dirty tracking in the Unit of Work, (which at the time were all fairly controversial ideas in rails-core) etc were all an effort to address performance. The PoEAA was an inspiration for sure, but it turned out to be a prescription for poor performance on Ruby 1.8.x.

You didn't yet you did? You've said the same thing twice here

https://en.wikipedia.org/wiki/Data_mapper_pattern

https://en.wikipedia.org/wiki/Active_record_pattern

I think the mention in the article of the User.Create(params[:name]) one liner is really instructive. Creating a user is one of the most important things you're going to do in an application! The business logic rules are incredibly important, the security implications are huge, everything. Trying to make it "easy" is ridiculous, because as a developer, you should be thinking about these things. That's the kind of thing that should contain absolutely zero magic, the logic should be upfront and visible.

I've worked as a web dev, and I've also worked outside of web development, and the number one thing that drove me insane doing web development was never knowing if any one line of code was doing some severe amount of impossible-to-debug magic. I'd rather just write javascript against the browser APIs with a lightweight http server.

As far as I can tell, the vast majority of frameworks aren't really about providing functionality, they're thought experiments in how to write software. That's fine, but they should bill it as such. I'm not going to say web development is easy, there are parts that are legitimately difficult on their own accord, but I think the web development community has made things massively harder on themselves by pretending all these abstractions are actually simplifying the task they've set out to do.

Use case: you're a solo developer and you need to build a proof of concept web application based on a fairly complex set of requirements. You probably want to use a framework like Rails and focus your time 100% on the specific project requirements, and use the framework to generate the common parts of the web app for you.

Another use case: you're on a large, multi-year project for a huge client where each developer has his/her own specialty area. Here it may well make sense to go with a Java Enterprise app and wire your own persistence layer or write your own SQL queries.

The mantra of Rails has always been "don't repeat yourself." Don't waste time rebuilding the same 90% skeleton every time you need a CRUD app with a postgres database.

Want absolute granular control over all parts of your application? Then almost by definition, you really don't need a framework. So great, don't use one and roll your own web app from the ground up. But there are many times it makes complete sense.

>things. That's the kind of thing that should contain

>absolutely zero magic, the logic should be upfront and visible

No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases?

Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better?

Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.

This attitude is really pervasive in web development, and I think it's kind of bizarre. If you're building something as a developer, you need to understand what it's doing, because at some point something will break and you will have to debug it.

When you get to the point you have to debug it, are you going to want to figure out some sort of insane meta-object protocol where you can't figure out where or why a method is dispatched, at what point inputs get santized, etc., or do you want to walk down a simple function chain?

Keep in mind I'm not advocating rolling everything yourself, I'm saying if you use a library it shouldn't be treated as a black box. I'm advocating avoiding abstractions that obscure your ability to understand what's happening (what I call magic). Use a library for user authentication, for sure, but if you can't explain how it works well enough that you could replace it, you shouldn't use it.

"Magic" is good for beginners, because there's just too much they don't know.

Not thinking about all these things because the community of thousands should have done it better I did, is just lazy.

This is the kind of thinking that leads to unnecessary layers of abstraction and bloat.

Just because you aren't hand-coding it doesn't make it "magic" or "lazy," it makes it efficient. I'm perfectly happy to use Bootstrap for my web application's styling because they've handled most of the exact same styling problems I will have to, and quite well. I am quite confident I could replicate a lot of that functionality every time I needed to build a web app, but why would I do that when it's already been done and I can focus on other problems?

As an aside I'm curious why you think that "magic" is good for beginners. When you don't have a clue what is going on at all, you really should spend some time learning what happens when you create a user via ActiveRecord, which can easily be done if you study the log files for a bit and read the Rails documentation. Once you are comfortable with what's going on, then you can use the framework to auto-generate code for you.

It's about reading the code, and having a good mental model of what is happening. This is the point Rich Hickey tried to drive home with his talk "Simple Made Easy".

https://www.infoq.com/presentations/Simple-Made-Easy

If you are a developer and haven't watched this yet, you really, really should. Very important distinction to keep in mind any time you are writing software.

Haven't read the Active Record source code, but would be interesting to find out where it falls on the "Simple vs. Easy" continuum.

I was referring to absolute beginners with little prior background. To them, technical documentation is a bunch of gobbly gook. For these people it's usually better to be somewhat opinionated and just tell them "there are other ways, but this is the tried and tested way and it works". A nice side effect is that they don't suffer analysis paralysis and panic attacks.

They don't know what they don't know, so it's sometimes useful to just tell them "this is the syntax to do X" (aka "magic") and gloss over the finer details. I've found that the time to unveil the magic is when they poke around under the hood, read up, and start asking questions about how things work.

And as for leaving for what, the author identified both the other Ruby-based stacks and the noon-Ruby languages and frameworks that he sees as valuable. And, no, Java is not on the list.

Your rant looks like a reflexive defense of Rails from someone who hasn't read the source article more than superficially; the article doesn't dismiss the web as a serious domain, it just sees Rails as locked into a dated approach to the domain.

I get it, tight coupling and forced architecture aren't ideal. I accept those limitations so I can get Rails' productivity superpowers. I don't just accept them, I embrace them, I've learned the wonderful joy of having everything you coded 6 months ago just slide right back into your mind because it didn't try to buck the convention. I spent extra time understanding that convention and why it exists when I wrote that code, I think most Rails devs don't do that, and so overcomplicate their applications.

I've been on the other side of that tradeoff, so I can see where you're coming from. There's a lot of appeal in making and using your own abstractions that fit the domain better. But the web is a complicated domain in its own right. The right approach is to use one DSL for the web, and make your own for your domain. DHH was right, Rails is your application. To do otherwise is to over-complicate your architecture.

> locked into a dated approach to the domain.

Ugh, seriously? Is this fashion or engineering?

The abstractions Rails uses are fine for a relatively small app (up to 10 models). Beyond that is where the complexity mushrooms and the framework starts dragging down the project.

Solnik's points about create() are very subtle. Think about coercion, validation, and all the potentially invalid or confusing states an app can end up in.

The approach Rails takes with ActiveRecord is fine for a small project, and often benefits consultants who leverage the boilerplate to show superb progress after one month of development, but it fails in the real world.

To be fair to Rails, most approaches to input validation and the creation of multiple levels of nested objects are implemented poorly. Solnik's point is just that Rails serves up a lot of these flawed approaches into one toolkit, and so the resulting ecosystem is plagued by the sum of all the flaws, and the core team is not really seeing the big picture about how to improve the overall state of the ecosystem (why would they, they are getting paid a lot from the Rails status quo).

DataMapper was superior to ActiveRecord. When Merb got merged into Rails, I was certian DM would be the ORM of choice for new projects, but when it wasn't I personally stopped using Rails on new projects. Sinatra + DataMapper is such a superior approach to full-boat Rails too, fwiw. How many thousands of developer hours are spent upgrading to the latest Rails every couple of years for no benefit. How many useful gems are nearly obsoleted, etc.

Rails has had the worst kind of cargo cult success. Most of the gems are weekend projects that lead to a blog post and a bunch of speaking engagements for the writer, and then get left to wither after the community has naively embraced them. This is not the case for all, but it happens way too often.

There are also many, many subtle bugs that are introduced by ActiveSupport. I've personally wasted at least two weeks of time dealing with them over the past 5 years.

Ruby is a great language, but I'm glad someone as talented as Solnik is branching out.

I've worked on several rails applications with a lot more models than that. Some with over 100 models. ActiveRecord has flaws, but I never felt it was a great impediment to getting things done.

A bigger issue (as you mentioned) is the large number of gems that are abandoned or sporadically maintained. I don't see that as a rails specific issue, but it seems to rear its head most often with gems that interact with rails.

Very experienced developers can create a usable codebase in Rails with over 100 models, but it is highly unlikely to happen if someone in Rails' target audience uses it.

Once you grok pattern matching you'll never want to see another Ruby case statement again. Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions. There's really no such thing as functional Ruby.

You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.

Un uncached Play Framework app will probably outperform a highly tuned Rails app out of the box, even with hundreds of person-hours spent in tuning the Ruby app.

Which leaves you more time to work on actual features.

And then you have Akka. Which is a whole other paradigm to master (but with it's own rewards).

And then you have deployment. Which is a huge breath of fresh air.

Sure, you'll miss some few things in Rails. Like Inflection. Add a dependency for one of the ported versions (like: https://github.com/backchatio/scala-inflector. It's just a single file).

The learning curve isn't the smoothest (though API docs for Java/Scala libs in general and the Play Framework guide is far more complete than anything I ever experienced in Ruby-land). But the rewards.

Come to the dark side. :-)

Then I'd have to learn Scala. I do not want to have to learn an entirely new stack. It took years for me to learn Ruby's eccentricities. Sure it would take me less time to learn Scala, but I already know Ruby. You seem like quite the masochist, spending years in one ecosystem trying to build something, then burning it all to the ground and starting all over. Just looks like so. much. effort.

> you'll never want to see another Ruby case statement again

I never write case statements in Ruby. What I do when I find myself needing a case statement is to go looking for the missing class. I'm missing a domain element and OO programming to me is all about clarifying a domain.

> Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions.

I pipeline all the time in Ruby. A lot of times I'll wrap a data pipeline in a class so I can encapsulate the logic and manage it better. When you wrap a pipeline in a class, you can do things like add immutability to the instance variables. Sure, it's not true functional, but I don't want true functional.

> You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.

Let's take these in turn.

> more maintainable code

I love maintaining my code. I fail to see how learning a new stack could actually improve on this for me.

> lower LoC count

Mostly aids in maintainability. Again not at the top of the list of things to improve.

> easier testing

I've changed my approach to testing over the years. Again, this is not anywhere close to the top of the priority list.

> More mature libraries

Again, this is something I've fixed by changing my approach to the problem. Whenever I introduce a gem, I put an interfacing class between the rest of the app and the gem. That way it's easy to swap out if it becomes a problem.

> And then you have deployment.

Deployment sucks in Ruby, not gonna lie. But again, problems are indicators of overcomplication and I've tuned my workflow to drive more simplicity over time. I know Capistrano very well, seeing it evolve over time has given me a keen eye for how to keep it manageable.

On the whole, I like the idea of functional programming and am not opposed to coding in a functional style once in awhile. HtDP changed the way I thought about programming, though I eventually switched back over to OOP. I strongly disagree that there's any kind of magic to functional. Everything in programming involves tradeoffs, and OOP better fits my mind than functional does. I look at pure functional as math-heavy and harder to grok. I want stateful objects, because humans think in terms of objects and not data pipelines.

> The learning curve isn't the smoothest

That one issue outweighs all the purported benefits of all the others. I would much rather spend my time thinking about domains than learning new tricks.

If you like what you're doing, more power to you. I picked up Ruby because I thought it showed promise as a good scripting language and web development tool (this was pre-Rails) at a time c# didn't really excel at either.

> You seem like quite the masochist

Maybe. DM was created to solve a problem. I didn't burn anything down. I just walked away. The best time to do the right thing is yesterday. The next best time is now.

After 8+ years, I realized I'd spent much of it trying to work around limitations in Ruby. It was just time to open myself up to the idea that there is more to programming than what I knew.

The writing has been on the wall for Rails for a while now, we're just seeing an increasingly large number of people publicly moving on from it.

> It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.

Back when Java was introduced, it was partly taken up because the features it introduced made developers more productive - hardware agnostic code, network programming out of the box...

Nowadays a lot of developers have moved on from Java. Maybe the same thing will happen to Rails...

> It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.

If projects such as Merb were more common, maybe Solnic could leave Rails without abandoning Ruby.

I've been there, done that--was part of a team that owned a java application that grew over a decade (and eventually ran the team). A year or so after I left, they retired the application.

Why? Because we owned all the complexity and couldn't support it.

Maybe that was my failing. Maybe the team's failing. But I don't think that having control of how the whole codebase fits together means you necessarily have more control over complexity.

Maybe they never need to do that, in which case that's a bargain. But I tend to think that any old enough codebase continually accrues edge cases that must be solved.

At one point I realized, I should not stick into one language and one framework. Ruby is good to know, but I'm better if I can also tackle Scala, Java, Rust, OCaml, Haskell, Python and so on. Also happier, I'd say... I can now choose the best tool for the job.

I might even go so far as to say that a lot of where JVM has strength is that contexts are pretty measurable... Spring containers, Akka systems. You instantiate them and hold them basically in the palm of your hand, you understand your scopes. Any technology that allows application scope to slip out of your fingers and intermingle with everything else under the sun is something I'd be wary of.

I call this "magic" and I dislike it very much. I'm a very explicit person. I like the ability to jump into any project, regardless of language, and be able to figure out how it works. This is typically possible with Python, Node and PHP with most web frameworks. Ruby with Rails? Not at all and for precisely this reason.

I'm fine with abstracting things but only to a degree. If you're doing a laundry list of complex things with a single statement, and I'm referring to web server specific stuff not ASM instructions, then your framework is going to require more ramp-up time than any other explicit one.

> you'll also end up writing Ruby code to accomplish what the database is already capable of.

This is for the best. Usually, you have only a few database servers, while you have lots and lots of web servers. If you have a computationally intensive task, it's better to perform it on those web servers, which you can scale horizontally.

In our environment, the problem is usually the opposite -- it's way too easy in ActiveRecord to ask the database to do computation like sorting for you. Also, it can be hard to predict what impact an additional clause will have on the server's use of indexes. We try to get engineers new to Rails to write the simplest, most performant queries and then use ruby to do any soft of complicated transformation or computation.

Actually the right tool for this is plain old SQL. Even with nice formatting this is probably a 10-liner at most.

If you have a computationally intensive task, it's better to perform it on those web servers, which you can scale horizontally

It's only computationally intensive if you're doing it wrong.

When I post job adverts, a large portion of applicants balk at the SQL questions: "just use PDO, or ActiveRecord, or ADO, or SQLAlchemy". Which is fine, if they can explain the difference between inner, outer, left/right joins - and they can't. SQL will be the next COBOL at this rate, or at least I hope so for selfish and monetary reasons.

To make it a bit more clear, it's exactly the same separation of concerns that you want when you write a view for the UI. The controller takes one or more model objects and uses the view to generate an abstraction for the UI. When we save and fetch information from the DB (or send data out on the wire as JSON, for example) we want the exact same thing.

BTW, be very careful about doing all your computation on the ruby/rails side. It's a good idea from a certain perspective, but you are building a very nice bottleneck there if you have anything of real complexity. For example if you have a report that needs to sort through millions of records, you are going to be hanging your server for a loooong time. As you say, in those kinds of situations, you really want to query a service that has the ability to scale the requests more reasonably. Rails is incredibly poor at this kind of thing.

My own personal opinion is that there is very little that rails gives me that is worth the pain that Rails imposes. I'm much better off building something with Sinatra. What Rails does do very well (which the author also acknowledges) is reducing the number of things you need to know to get up and running quickly. But if you are going to pay the kind of salary I demand, then you will expect me to beyond that level ;-)

"Rails" is an appropriate term for the framework; step too far off of it, and you find you're on rocky terrain.

This solves the problem if you know ahead of time the format of the query, e.g. The example you gave would probably fit well. But if you're offering some kind of query building interface, well god help you.

No one has told me I'm wrong yet with this approach and it's been working great for years.

Model.find_by_sql(query, binds=[])

http://devdocs.io/rails~4.2/activerecord/querying#method-i-f...

Model.connection.select_all(query, name = nil, binds=[])

http://devdocs.io/rails~4.2/activerecord/connectionadapters/...

Oh, and if you're writing an INSERT statement you have to use connection.execute after all. Have fun!

You just answered your own question. You sanitize the string and then you call connection.execute. Not sure I understand your other issue but it doesn't seem too compelling.

> Not sure I understand your other issue but it doesn't seem too compelling.

If you don't understand the other issue, how do you feel qualified to comment on whether it seems compelling?

Use case: I want to pull up a table of aggregated data for my user. The table is built by joining multiple tables together. The user can dynamically select which columns in the table he wants to see.

A major problem with rails is it tries to "simplify" the inherent complexity of web development by using abstractions & mappings that ultimately increase incidental complexity in the entire stack.

Having been bitten by web applications written in scripting languages (Apache + TCL like AOLServer) with an architecture very similar to Rails, but done in 1999, Rails was never that interesting to me.

Isn't that part of the problem? Webdev is complex. But it feels to me like it's been overcomplicated by a factor of 100. It doesn't have to be.

Asking web dev to be less complex is like asking financial markets to be simpler. Websites are market tools, tools have to retain a competitive edge. You can't afford to ignore market trends. You can't afford to wait until everything is well-defined. You can't let craftsmanship get in the way of shipping.

You can buck the rules yourself and operate on whichever side of the tradeoff you want to operate in, but you can't expect everybody else to follow the same rules you do.

I mean, if you don't like the web, then by all means find a different domain. I personally love it, and find it absolutely fascinating. With the right tools, (Rails) the complexity is manageable.

Which isn't to say that the crap mountain wasn't the best choice. It may very well be the pragmatic choice. The highest net benefit choice. But I don't believe it's intrinsic. I don't believe it has to be this way. Which means it's at least worth considering alternate paths. Even if in the end we picked the same way.

I work in video games. Currently working in VR. Where you absolutely must hit 90fps and never drop a frame. A certain degree of craftsmanship is required to ship. Layers and layers of abstraction on abstraction need not apply.

If you want to produce compelling VR experiences then I'd recommend you download Unity. You should be able to start making real, valid prototypes for different types of VR interactions in under a week.

If you want to graphics then I might recommend you poke at http://humus.name/index.php?page=3D or https://github.com/bkaradzic/bgfx. But graphics isn't my specialty so my thoughts aren't the strongest.

If you want to learn C++ then... that's an interesting question I've not thought of before. Maybe I'd start with "Learn C the Hard Way"? http://c.learncodethehardway.org/book/ I'm not as much of a C fanboy/C++ hater as other game devs. I quite like C++11 lambdas and move semantics. But I hate boost and it's ilk. So starting with C and later adding a dash of C++ seems like a good way to start.

I built my first website in 1994. I know the right tools. Rails is not one of them.

It's been a while since I did GUI programming on the desktop, but I remember it being so complex to build cross-platform applications that rolling your own cross-platform abstraction would be downright ludicrous.

I think the parent commenters point is correct. People treat the web like it should be easy, like it should just be HTML, but its not. It's full of legacy stuff, it requires working on multiple "platforms" (browsers), it runs on all kinds of device sizes and shapes, and the applications being written for it are no longer trivial.

1) Broken platforms. How much "innovation" has occurred in javascript to compensate for a broken execution model? How much caching does your average rails app do because of the poor concurrency the the Ruby platform, requiring external services for persistence across requests?

2) Looking for challenging problems. Design patterns are often a solution to a meta problem. Building a CRUD app, there aren't too many hard domain. However, code maintenance is a hard problem. It involves many people using subjective judgement. So as a somewhat bored developer, I'm going to try to solve the meta problem.

It sort of pains me to see how much engineering effort has gone into essentially making broken systems more performant and maintainable.

I'm glad to hear people say this. I want to be a webdev (second career), but rather than code school I went back for an MSCS, because I really wanted to dive into the nuts and bolts down at the database implementation level.

I've done a fair amount of machine learning, ai, large-scale parallel programming, and algorithm design, and while I'm super-green, it's good to see the top comment is that the web is a serious domain.

I don't understand why web dev is so "scary" or "complex" that it needs 8 abstraction layers on top of it for my own protection. The only time I thought I needed hand-holding was when I didn't understand SQL injection and cross-site forgery/scripting (and once you do understand them, it's not difficult to protect yourself against those either).

If I found HTTP methods and headers, Javascript, CSS, Cookies and the rest of the web stack "scary" and needed hand-holding from Rails in order to get shit done, I'd be really, really worried about my skill set...

The web world is changing quickly and you have to ask yourself if you're a "web developer" or a "rails developer". I think you'd want to be the former.

And I have WINE to thank for that layer of compatibility.

If it's important to deploy as a Windows process, then the Windows Linux subsystem is not much better than a VM. Point is, its no substitute for a (better) MSYS2/Cygwin.

Now if you're saying that the webapp itself would be required to be a Windows process, there's really no way around that. But as I implied elsewhere, the biggest stumbler for Rails on Windows has always been the lack of a compiler. Whether you compensate for that by installing a subsystem with that capability or by using a VM with the capability is largely a local problem to the company.

http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUs...

To contrast, Elixir runs on Windows. However, it may be hard to get all your projects up and running due to various baked in concerns where they were written to support Unix-like systems only.