The latest developments in Rails are making the solid foundation even more solid. There is stuff happening to make infrastructure easier: Kamal sure, but also Solid Cache and Solid Queue and there is a lot happening in the front-end with Turbo (Morphing) and mobile apps with Turbo Native and Strada.

We have upgrade to 7.1 already and have a mobile app in production that is built with Turbo Native. I am also excited to start replacing our Redis cache with Solid Cache to make everything simpler and cached longer.

Great to see the Rails community so alive and see the deep connection the (ex) core team members have to the framework!

I've never worked with Rails, but this sounds amazing. One of the things I really hate about the Node.js ecosystem is that there are no clear conventions, the structure is always different even when the same framework is used. It's a mess. The exception is probably Next.js but it's more frontend-y.

The downside is if you want to do something that cuts "across the grain" so to speak, things can get messy. Combine that with Ruby's high dynamism and someone trying to be too clever can make a mess fast (alias_method_chain anyone?).

Yeah, node has been incredibly successful but I think it's a fair criticism to say it's also a victim of that success in that it just feels like so much arbitrary complexity. And the flavor of the month changes so fast that projects end up this weird mishmash.

This makes sense from an objective perspective on what constitutes clean code, and I used to believe that this is what a really large enterprise Rails codebase should be refactored to eventually (although I never personally did so).

Rails offers an alternative approach to this however, that is less neat from an objective perspective, but actually follows the Rails principles a lot better and it's called Rails engines. Basically you split your Rails app up into multiple mini-rails apps for each domain called Rails engines, each has the same directory structure as a Rails app and you get the full benefits of a regular Rails app inside each. I used to think this was an ugly approach and I never even considered it, but now after over a decade of Rails development I've made a 180 and I believe this is the way to go.

The "clean" way forces you to construct interfaces between your business logic and the Rails app, basically introducing a lot of extra boiler plate. All for the perceived benefit of making your business logic be abstract of the Rails framework. This violates YAGNI of course, and by a huge margin too. I've never seen the business logic of a Rails app be ported to some other framework in 15 years, the most I've seen is reusing code in a Grape API that was mounted inside the Rails app. And what you give up is Rails' convention over configuration and its predictable structure, and the general documentation and knowledge of that structure that people can carry from job to job.

I've learnt a bit of Django's app-centric model (which is similar to rail's "engines")

I work for a company that enforced the data/domain/interface with a plug-in approach to custom code.. and I liked it.

But for my own projects, I get stuck choosing between the two, I see more benefits in the layered approach, but I feel like I'm fighting the tide with every project I start

Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks.

P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s

Not sure if that's a plus or a minus, after all there might be devs whose preferred stacks differ by 1 or 2 items (e.g. prisma over drizzle, nextauth over something else) and they'd both benefit from having a standardized template to start with.

EDIT: just remembered I fell in love with Meteor for a while. Then they started shoving React and other external stuff into it to gain more market share and it inevitably lost that opinionanted nature that, IMO, made it so good. Choice isn't always a good thing for the end user (even, and sometimes especially, when that end user is a professional who just wants to get things done).

Django and Sails.js both seemed like they were a step down in terms of general productivity, though each had a unique advantage of their own (admin out of the box, websockets & realtime features).

I haven’t had a chance to really give RedwoodJS a trial run, but it's the JS-based fullstack framework I'm most curious about.

Maybe my first update experience with Laravel was a bit of a mess (v4.2 to v5.0 "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."), and I couldn't easily "see" the models' properties and the Facades, that's why I have shy-ed away from it a bit. I have worked with several Laravel applications since then and have gone through the v6 through v10 upgrade cycle and can say it's gotten easier (though I wish they could settle on a release schedule), but my preference is still Symfony.

Plus when I checked out Django, I felt a bit more "at home" (e.g. see Twig templating language and how they used Django templating language as inspiration).

I've worked with Vue.js and AngularJS 1 and Angular 2+, but I'm glad htmx is coming in strong, so I can focus on logic, speed and stability instead of glueing the frontend and backend API together and debugging in the different browsers.

Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs.

There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.

Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components into the server which IMO is a mistake. And I say this as someone who has been doing mostly front end since the 90s.

I would like to introduce you to Adonis. https://adonisjs.com

https://platformatic.dev/

But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.

https://packages.adonisjs.com/?category=Rendering

And the fact that these aren't official is kind of the point I've been making. In the JS world there isn't a holistic fullstack framework. You have to stitch it all up yourself. In Adonis, Express, Fastify, Next, SvelteKit, etc.

Because most people are content with using Adonis' Edge templating with something like Alpine for sprinkling in interactivity, or using Vue.

> In the JS world there isn't a holistic fullstack framework.

This is true for all monolithic frameworks in every other language. Even Rails you have to use 3rd party addons for stuff. It's not feasible to build everything in for every possible use case, so they make it easy to add on stuff.

I think now you're just starting to move the goalposts.

I think you make a good point here, JS is uniquely able to be executed both frontend and backend, hence things such as underscore templates.

Other languages don't have that ability. Therefore I would agree that there is no point in making a 1to1 copy of existing MVC ideas.

Being an ex-rubyist and now doing a lot of NodeJS, I really enjoy moving server code to the client at zero mental cost since it's mostly the same APIs

Trying to use client patterns to solve the server has been mostly a mistake. OTOH separating server and client and using an API to glue has produced a lot of issues too (SPAs, etc).

I think the future is a hybrid model where 80-90% of the front end is orchestrated from the server (LiveWire, Hotwire, LiveViews, etc) and 10-20% is a pure client side solution.

Moreover, JS really encouraged the use of API driven development + React, at a time when that trend was in general growing. I bet this impacted the ORM development space, as I suspect FE style devs were perhaps more demanding of an ORM while more backend oriented devs were perhaps fine writing SQL. With other frameworks I find the coupling of ORM and template views to be slightly more natural. Maybe this is just me inventing story lines but its how it feels. I think the lack of a quality ORM _really_ hurt the most.

Lastly there was a growing trend towards micro dependencies and assembling from parts, and I think it promised more than it could deliver. I think if Node had shipped a higher quality standard lib, perhaps akin to Go or (maybe) how Deno is trying to do, the story might have looked much different.

This is my take as a consumer, rather than creator / maintainer of these frameworks, so not sure how accurate this is. Just my viewpoint with my dev career growing alongside the early emergence of Node.

Flask is almost completely freeform in what it allows you to do, it just has a few style recommendations and a ton of community convention, but you could technically ignore 90% of it since Flask doesn't really expect any sort of structure.

https://sailsjs.com/

https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...

https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...

Next.js is using React, it's a piece of the fullstack framework, like Rails and erb. React is the primary fullstack JS templating system, that's even more featureful as it's a better client side JS interop story than html templates.

By the stackoverflow graph, it's clear that most complex projects have moved onto frontend frameworks like React, instead of templated html, which standard Django is using. Django used in conjunction with a frontend framework, is most often through Django Rest Framework, which fares much less popular on stackoverflow trends:

https://insights.stackoverflow.com/trends?tags=next.js%2Crub...

Ruby 3.3 YJIT is 2x faster than Ruby 2.5 in RailsBench.

Work on brining more Ruby Gem from C to Ruby ( easier JIT )

Lots of dev tooling around Ruby and Rails coming.

Hopefully there are more good things to come in Rails 8.0 and Ruby 3.4

     it looks basically the same in structure whether it is the 
     biggest Rails app there is or a new one

In addition to easier onboarding, it greatly reduces bikeshedding.

MVC maybe isn't the best paradigm for everything, but it's good enough for most things.

Which is funny because uncle bob cites this as a major downside to architecting code.

Do I have to deal with JavaScript in any way?

Sure can. However I won't pretend it's the only framework you can do this with and be productive. I love Rails and Ruby but it has great competitors these days.

> Do I have to deal with JavaScript in any way?

Really depends on what you're doing but probably.

You can use Hotwire (look at turbo frames and turbo streams) and you will write less Javascript code while achieving some very nice interactive UI.

Which specific documentary is it? Google seems to return a few different options.

I've repeatedly seen the same things over a 15+ year timespan.

Also, I do wonder if RoRs perceived productivity is by inertia? I have a hard time believing you can top the productivity of quick scaffolding for back-end you get circa .NET7-8?

The ASP.NET team tends to churn stuff wayyy more often than I'd like for questionable reasons, which can make keeping more painful than I'd like - but tbh I often just keep using the older ways of doing things in ASP.NET since it's almost always still supported...

non-LTS is 2 years, LTS is 3 years

https://dotnet.microsoft.com/en-us/platform/support/policy/d...

imo, short term RoR will beat the pants off asp.net core in terms of developer productivity. mid to long term asp.net core wins hands down in terms of developer productivity.

I don't think the RoR productivity story is fake, but I do think it's not worth the long term maintenance costs.

Three days ago I started using rails and I just flew through the weekend to get a MVP setup to show a coworker. Rails just made it easy to focus on what my app needs to do, not how my app needs to be implemented. I can finally see why people love it so much.

For the longest time, my primary complaint has been a lack of documentation/conflicting information when you break from convention. It can be extremely challenging to find/understand the "blessed" way of doing things. Thankfully, ChatGPT is extremely good at providing a starting point for this stuff.

Same thing with some of the more advanced Model relationships. I just don't write _that_ many relationships, so I tend to forget how Rails wants certain things defined. Since a lot of things rely on config, rather than "normal" runtime code, it can be frustrating to debug. ChatGPT just gets me to the right answer.

---

It's also pretty useful at gut checking DB design. There's been a few times where it's suggested a different approach than what I expected and I've preferred it's suggestions.

I’d recommend to those interested in seeing how a real Rails app is structured to look at the Jumpstart codebase as it’s a great resource on how to structure things

https://jumpstartrails.com/

As an alternative Bullet Train is pretty good, even though it adds a lot of bespoke libraries that aren’t the “Rails way”

https://bullettrain.co/

I kind of feel bad mentioning Struts and Rails in the same sentence, though, as Rails did much more than Struts.

I even remember at around that time there was a fundraiser specifically to hire someone to write better docs. I think it was some third party response to all the forums where people had been lamenting the desire for better docs. This was before go fund me and kickstarter so itself was a little unusual at the time.

It was so heartwarming to remember my Rails story, its been 20 years ago since I started using it! https://twitter.com/buger/status/1723040883325460818

That was until I learned that in Ruby:

`someObj.some_var = 'hello'`

Is syntactic sugar for:

`someObj.some_var=('hello')`

That made me smile. I have never smiled like that about a programming language. It literally gave me joy.

I’ll be honest I have some trepidation devoting my time now to something “old”, but on the flip side my career is in PHP so what the hell am I talking about “old” for.

As someone who’s taken multiple projects to production in Rails and generally loves Ruby, these days I prefer to start new projects in full-stack TypeScript. RedwoodJS has been quite good.

The Rails Console has to be one of the greatest productivity enhancers I've ever come across.

I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years.

Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. And how they tie together.

Talking about the domain: Rails puts "the plumbing" up front. Its how it achieves this consistency. My app is never about "models" or "http" or "databases". My app is about medicine-journals. Or loan-request-management. Or CRM. Rails makes itself important, at the cost of my domain.

Rails' opinionatedness makes it so that this is hewn in stone. Its MVC is a given - and that's fine - major architectures should probably be dictated by the framework. But it's ORM - ActiveRecord also is a given. And that's not fine because AR (as an architecture and as how Rails implements it) is very unfit for a large category of applications. It's virtually impossible to swap AR out for anything else. Same with templates/views, JS, Caching, and many more: you can -in theory- replace them with a drop-in alternative. But you cannot -not even in theory- replace them with something that has an entirely different architecture or concept. This makes Rails not Omakase, but actually McDonalds: wherever in the world you come, you know exeactly what to expect, but it also makes boring and bland: no-one eats 7days/week McD.

This makes all Rails apps look alike. Despite the fact that not one of the apps that "we" are building is alike another. Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck. Regardless if you build the next fintech platform with a team of 120 senior devs over 6 years, or you hack your "marketplace for coffeelovers" over the weekends alone: you get The Rails Way. One of those might be a perfect fit. But it's impossible they all are. Each team gets the same "menu". And in many cases it simply won't fit.

This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate where to put every file in a project or having to invent a new folder structure for every app we build fills me with a bizarre mixture of boredom and rage.

As with everything in life the people that whine about the medicine the most are the ones that make it necessary.

Sounds good to me. Most companies never reach that scale and if they do, I think investing into some extras will be well worth it.

Tobi looks pretty chill about it in the documentary.

the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs.

I'm also curious about YOUR choice of stack at this point.

In my day job I use mostly Rails. My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. Rails was great to get started fast.

Nothing wrong with using a press instead of a hammer at some point, they are just tools.

What sort of web app do you have that is CPU bound?

It wasn't a problem other than that a better initial design (nothing to do with rails) could have made passing all that data not needed, which was better for mobile. We had about 600,000 customers.

But yes, Spring and the various Java equivalents probably also fit the bill.

Rails is the "goto:" label of web frameworks. It's unbelievable how much it encourages spaghetti code and misdirection directly via its conventions.

Rails provides a way to approach CRUD via MVC. Controllers are your API. Models are the connection to the Database. Views are what the controllers render.

If your app doesn't do these 3 things - API, Database, and representation of your API - you don't need rails (I bet you do those three things). Other than that, you're free to layer on whatever architecture via ruby that you want on top of these basic rails constructs. If you don't like it, again don't use rails. It's opinionated for a reason

Business = program

Company = class (business can be a conglomerate)

Department = method

frameworks = implementation details

No. "we" are not.

hmm, sounds like this rails app that one might have not heard bout. You should check it out. Think it's called Basecamp

BaseCamp is DHH's company's product. DHH is the creator of Ruby on Rails. He literally create RoR to build BaseCamp, which is exactly the type of software the other poster is claiming is problematic for RoR.

DHH is on record as having said RoR was evolved organically from the early code of BaseCamp.

Rails/DHH took already established design patterns and made strong opinions into a convention on the folder hierarchy of where you store your code. You can change that hierarchy, its not set in stone. It will require a lot of change. I've been on teams and it isn't just on-boarding time, its countless hours trying to find code written by someone no longer there that had their own layout of where files should go. Without conventions, people will run amok with a file structure. Multiply that by the number of developers on the team with attrition and different view points on organizing files and it can be a giant mess after a number of years. Its all a waste of time and has nothing to do with the quality of the code, what domain the application is in or anything really.

If you love Ruby there are other libraries out there like Sinatra [1] that don't have the conventions of Rails.

[0] https://en.wikipedia.org/wiki/Law_of_triviality

[1] https://sinatrarb.com/

I maintained both kinds of framework-heavy and "organic home grown just libraries" apps, and you know what? I totally prefer framework heavy stuff; at least it has battle tested facilities for everything, and I can expect consistency instead of fomo-driven/resume-driven development.

my last homegrown framework was a nasty 60k LoC api that did like 10 operations. total business logic was 3000 lines, including fn declarations and docs. just transaction scripts. the remaining 57k were a gargantuan amount of boilerplate that gave absolutely nothing to the project, and all in "typed python" which is like 0.9x java verbosity. a massive piece of shit.

Does this happen more often for Rails than for other frameworks?

There are many ways in which a Rails project can get derailed. But they seem not different from regular tech debt and I could imagine equivalent problems in other environments.

> AR (as an architecture and as how Rails implements it) is very unfit for a large category of applications

If you plan to build an application belonging to a category where AR is not a good fit, why use Rails?

I wouldn't claim that Rails is a good fit for all problems. Still, I'd say the structure and defaults of Rails are one of its strong benefits.

Or do you mean "application" as in "usage" - i.e. that over time you might notice a problem that's hard to solve with AR? Could you give an example? I'd guess you could use a different approach for a single task, or even move from Rails to a different tool if that becomes a big issue.

I mean you could have at least picked some better example. Considering Rails was precisely extracted out from Basecamp which is "Domain. Team and Project Planning".

> It's virtually impossible to swap AR out for anything else.

I've used Mongo and a number of other ORM's, why can you not use other ORM's exactly?

This just sounds like you don't like frameworks and want to build things from the ground up, because most of the complaints you make are just not true. Maybe you are just inexperienced with Rails because you can swap out almost anything.

I can't reasonably swap out an array with a linked list even if the official contracts are the same.

this is why things like DAL's are created, they give you an opportunity to deal with the differences in behavior.

The issue with frameworks like RoR that use AR throughout is that the queries are sprinkled throughout the codebase, giving no opportunity to fix such behavioral differences.

What happens is every ORM then attempts some sort of "query reuse" and they do so badly because it's not possible to do it well with the contracts they expose. It creates code where you can't ever reason about the query that's actually being generated.

Sure, if you are going to swap out AR for another ORM in the middle of an established project you are going to have a bad time, but if one is doing that I have larger questions.

What is it that's not making sense to you?

How is that different from any other framework ever? You have to query the DB somewhere. Rails makes it incredibly easy to swap out databases. Much more so than any other platform I can think of.

Nothing is making you use AR at all. This is a non issue.

If it needs to be explained you've never seen anything but a gocart.

    I am convinced this is a major contributor 
    to why so many Rails apps turn into an 
    unmaintainable mess over years.

1. Any non-trivial app in any non-trivial language/framework usually becomes a mess eventually, given enough commits and developers

2. Rails (specifically, ActiveRecord) won't stop you from creating circular dependencies between models. This is easy to avoid, but it doesn't warn you about this or try to prevent it. So 99% of Rails apps have like, a User model that depends on (and is depended on by) most of the other models. This is far from a Rails- or ActiveRecord-specific issue though.

    Who measures onboarding in hours? 

However I think the standardization on MVC pays off here as well. For apps with multiple developer teams you may constantly be "onboarding" as you move between different areas of the app. And you can move forward with less bikeshedding.

    And that's not fine because AR (as an architecture 
    and as how Rails implements it) is very unfit for a 
    large category of applications

So IMO/IME it works well for scenarios where some of your data is AR/ORM friendly and some isn't.

     Same with templates/views, JS, Caching, and many 
     more: you can -in theory- replace them with a 
     drop-in alternative

Rails' caching backend has been seamless to swap between DB, Redis, in-process, and Memcached backends. As far as the caching "frontend", it's entirely optional, so I can't really imagine there is an obstacle to swapping it for something else? Like, you never have to use `Rails.cache`.

As for the JS side of things, I don't think I totally agree. There aren't drop-in alternatives, but you don't have to use Stimulus, and you can certainly use your own.

    This makes all Rails apps look alike.

I disagree. This presumes that there's some initial "onboarding" process, and that once that's done you just now will know the structure of the app for all future, never spending more effort on it.

That's only true for trivial apps. What actually happens in bigger codebases is after you stop working in some section of the code for a few weeks, it falls back out of your head and you have to figure it out again. Additionally, without conventions other members of your team are constantly inventing new structures and connections between things.

So really this lack of consistent organization is a continuous drag, not a one time cost.

I need to be more concise.

She is big on separating the business logic from the framework.

One had this what you describe: everything in /lib, and the MVC merely delegating to that. MVC downgraded to what it should be: plumbing that binds together your domain stuff.

The other did something similar but had it in gems (bound as Railties/engines). IT was a bit more cumbersome, as one had to release a new gem before being able to integrate it in the rails app. It forced a very solid separation of concerns.

i interpret fat model as: what can be move to the model, sits better in the model (directory). things that cannot be moved to the model: the request, the response, the session. not set in stone, but usually this works.

what i regret about older Rails code i wrote was the gluing of all biz logic to ActiveRecord ORM models (akin to, yuck, Hibernate entities), that also contain DOAs, form validation and all business logic. now i tend to split these out: form dtos that do validation, repos with queries, simple record classes, etc.

fat signals homogenous big thing, but is actually where most of the application lives. i coudl call it lib as well.

My biggest issue with trying to do this is ActiveRecord. I'd much prefer the repository pattern.

This reads like someone who doesn't understand how to use a tool so they think it is broken. I've worked on Rails apps that outperformed Spring/Java apps routinely and node apps routinely at very large scale. You're very rarely bottlenecked on CPU in a modern CRUD app, much more often, it is the database.

It sounds naive to call the framework that runs github, that almost everyone in the world pushes their code to "veeeeery slow" and I don't know what you mean by "bad at io" in any context where that is a problem for Rails.

That said, there are areas where Phoenix can't match rails, such as having access to a large developer community and a large existing base of libraries.

https://www.techempower.com/benchmarks/#section=data-r21&hw=...

https://medium.com/@elviovicosa/phoenix-vs-rails-benchmark-2...

The big difference is the blog post you linked performs a very basic GET request to an endpoint. It mentions it doesn't hit the database or deal with caching. It's basically a non-realistic hello world that is good at isolating performance of a specific library but doesn't show how it fits into the grand scheme of things.

The other link performs multiple database queries as part of the request which goes back to the old saying that for a huge portion of web apps you're I/O bound (AKA waiting for something else such as the database).

If you want to give an honest apples to apples comparison then, okay fine, what framework that does everything that rails does is considerably faster?

Is a Ferarri faster than a dump truck? Sure, but they have different uses. Try hauling gravel with a Ferrari. For the class that Rails is in, there isn't anything as feature compatible that is also an order of magnitude faster.

That being said, you missed my original point, which is that there are problems where you don't really want Rails implemented in a different language because Rails is not a good tool to solve that problem. Think hammer vs saw. You are asking for a different brand of hammer that can cut wood better. Wrong question.

Stateless API gateway making HTTP calls to other services, which have response times in seconds for various reasons. Rails throughput ~20 requests per second. Golang rewrite throughput: 200k requests per second. Same hardware.

Did anyone else feel the same way? I kind of want to give it another chance bc I have some side projects that I want to try out, but I find django/python and next/react easier to grok. Maybe I should try harder?

FWIW, I also want to pick up good practices when it comes to engineering a back end, and the good ex-rails engineers I know tend to be really good in general.

I like ruby quite a lot, too.

rails made me very fast.

I think one thing is true -- Ruby gives you lots of different ways to do things. And it can be really terse sometimes, if you want it to be. Some Ruby devs IMO should learn to favor readability over terseness.

Overall though, Ruby is my favorite language and IMO can be very beautiful. I don't think anybody would call Python beautiful. (Lots of great things about it though, nice language and ecosystem... no hate)

Love Rails, but found it very difficult to learn Ruby. It's very hard for me to read, but that may be because I come from a C# background.

If you're looking for something like Rails, I'd recommend trying out Laravel.

It's on par with Rails as far as features, ease of use, etc. And PHP was a lot easier to learn for me versus Ruby.

Today it’s something I repeatedly try to tell everybody about. It’s just so productive.

For example, ending an if statement with semicolon and then having the if block indented below is just not the normal way to do things. I’m not knocking Python, I use it all the time and it’s great, but it’s not a language you can carry over to learning other languages. It’s like if you know English, it’s pretty easy to learn Spanish. But if you only know Chinese, it’s going to be tougher to learn an “English-ish” language. Hope that makes sense.

Its not the minor syntax differences that I have trouble with, its that ruby does not "fit my brain like a glove."

I know this is a possibly unpopular opinion but I don't think one should glorify a sophomoric book as a key Ruby book-- there are others that deserve that title, PickAxe is close, but I'd have liked a book like Whittaker's "C#, Player Guide" for Ruby.

Matz's intent was and has been to bring joy and delight to developers, with the odd combination of PERL, LISP, and Smalltalk as his inspirations. Joy and delight don't necessarily equate with "most practical". But joy and delight are wonderful and healthful qualities to cultivate for a good life!

_why embodied much of the spirit of the (at least earlier) Ruby community. We were software developer immigrants, many coming from prescriptive verbose technologies (I'm looking at you, Java!). We were eager for novel ways of expressing our ideas. Ruby's metaprogramming capabilities are, as far as I know, still all but unmatched beyond perhaps Smalltalk itself (and IO, which AFAIK no one uses seriously). _why's playfulness captured all of this in elegant and sometimes bizarre but often artistic expressions in his projects and code.

I will never regret or apologize for the Ruby community's appreciation for the Poignant Guide.

And, _why, wherever you are and whoever you are, thanks.

I just didn’t know how much faster building web apps could be.

This isn’t even a criticism of Django; the things that Django does, it does very well. But there are a lot of things that it doesn’t do that a mature web app will eventually need to handle.

Also worth mentioning Michael Hart’s intro course, which is a really shockingly well done way to ramp up from absolute zero, even for someone with very little code experience.

* Which, in fairness, it mostly is. But also meh.

In under two weeks of opening Michael Hartl’s Rails Tutorial, I was already more productive with RoR than with the stack I'd been using professionally for 3+ years.

Otherwise great docu with DHH "f*uk you" slide which does give an insight into successful open source projects.

Unfortunately iirc Ryan suffered a burnout and had a lengthy break. I hope all that is better now.

Unfortunately having folks around me that had burnout helped me to avoid one myself.

https://news.ycombinator.com/item?id=38253485

You played a big part in it. Thank you!