Berk

I'm in the process of creating an MVC framework and was curious about the other architectures you mentioned. This comment seems to be down on MVC and Rails so I was curious about the alternatives you mentioned and came across your post that ended with praise of Rails ( https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ): > Rails still is a great way to get a prototype demo, or minimum viable product online in days with least surprises. Your comment seems to indicate that you started discovering new architectures like the Command Pattern but it sounds like you are also still a proponent of Rails and MVC based on your blog post. Do you have any links to resources that helped you discover other patterns or could you share what took you on your journey? In the Rails blog post, you said: > I have a separate post planned on "RAD web frameworks", MVC and ActiveRecord, but it is safe to say that such frameworks, amongst which Rails, have found their niche, yet are by no means a silver bullet. Is that post you are planning to write going to delve into some of the architectures you mentioned here? That would definitely be something I would be interested in reading.

>Maybe Ruby is not at the level where is was in 2007-2009 but it is also NOT in a downward trend. It's not only that ruby and ruby on rails are trending down, this has been the case for at least 10 years. https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ This is only an article, but you will find the same point of view in many other places. The decline of ruby and RoR is obvious for anyone doing web development. Python is only getting stronger, Typescript the same, not to mention the statically typed competitors like Java with Spring Boot. I wouldn't doubt that even languages like Go and Rust might surpass ruby soon in web development because as general purpose languages they are already more relevant. I'm a former RoR developer and I took off the keywords ruby and ruby on rails from my curriculum because for me professionally it makes no sense to invest time in them.

About that content: back in the days there were numerous podcasts about Ruby or Rails or both. That was when podcasts were hardly as omnipresent as they are today. There were newsletters, blogs, and every e-learning platform had many prime tutorials on rails. Those aren't all gone. But in the grand scheme of things, Ruby, and Rails' have been relatively decimated. There now are about twice as much (web) devs as back when it started but Rails nor Ruby is hardly twice as big. It's been going strong, solid, flatline. I wrote a longer post, a while ago, with sources and numbers on this. It was featured on HN https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ (and frankly, it's going faster and is worse than I predicted back then)

> There are real efficiency issues. For example, when policing offensive material (eg CSAM) is each entity responsible? How is that efficient? Related: https://berk.es/2022/11/08/fediverse-inefficiencies/

Being "peer-to-peer distributed" (aka "decentralized") is a fundamental part of the definition of what a blockchain is. This article explains it well: https://berk.es/2018/09/19/the-private-blockchain-fallacy

I was left confused after reading this article. 1. It claims Rust is ~10x faster than Ruby, based on a benchmark that reads a 23mb file, and then iterates over the data a single time. In my experience, Rust is between 20-100x faster than Ruby in purely CPU-bound workloads. But the author's main contention is that most work is IO-bound instead of CPU-bound, so probably not a big deal. 2. The author claims "it hardly matters that Ruby halts all code for 15ms to do garbage collection, if the fastest database-query takes 150ms". I've written applications that query Postgres databases with tens of millions of rows, where the 99th percentile response times are <10ms. I'm not sure why it just needs to be taken as a given that databases will take 150ms to return any data. 3. This flame graph from the article[0] seem to show that the vast majority of the request time is spent in Ruby parsing timestamps, rather than in the database. This seems to make the opposite point that the author is trying to make. I'm not familiar with this stack, so maybe I'm missing something- can anyone explain? [0]: https://berk.es/images/inline/flamegraph_sequel_read.svg