I don't think complexity comes just from the number of tools, but the disparate things you "need" them to do. Redis, Vite, large CSS toolkits -- you're learning a bunch of large components.
I mean complexity comes from many places, but compared to the 'Unix philosophy' most of these tools are quite large. Obviously, there's quite a bit to learn about the way a *nix OS works, but if you treat tools as small and composable for simpler interfaces it helps a lot.
The web dev example of pub/sub is funny, because chances are if you're using Rails your primary DB (probably Postgres) already has a pub/sub system in or. Or you can just use any RDBMS for your job management system.
I mean, I think the problem with SPA-like client-side approaches are that there aren't any that have felt _good_ with Rails, let alone great.
Absolutely true that not every app needs to be a SPA from day one, but I do with there were a few more common solutions for "hybrid" apps, which use some pages as a SPA. That said, it's not that bad once you've got it setup. I like that Rails offers a solution like import maps, but I do also wish there were better core functionality for using some kind of package manager.
Like the redis analogy: Whether or not you need Redis, there are good defaults and very good 'third party' solutions for background jobs (or caching). You don't even need Redis is many cases, but it's easy to grow into.
Lapis is very cool, but I really struggle with a lack of examples and pre-built solutions for some things.
Leafo's itch.io is built with it and I maintain snap.berkeley.edu. A great tool, but I'm also many times more productive in Rails. (It's an unfair comparison, to be sure!) and Openresty + Lapis is quite performant and low overhead which is great.
I love JS and Ruby, and I spent a bit of time maintaining a web app in Lua.
There are parts about the language I really enjoy. I like dynamic languages; I don't run into type issues so often it bothers me, but the tooling around Lua still leaves me wishing for me.
Part of this is really my own ability, or lack thereof, but I feel slow and constrained in lua. I have a hard time debugging, but I don't feel these things in other languages.
I have a close friend, who's an Azure dev -- uses his MS laptop for work, his phone for everything else. And I do mean everything - taxes, trip planning, etc.
It's not just crazy kids who "know nothing but phones". Even engineers.
That said, phones operate too much like appliances. I will not give up my Mac.
I've been wondering about this... It definitely doesn't feel great to be on the receiving end of something auto-generated. But a "unique" message is at least more interesting to read, and doesn't feel quite as frustrating.
A yet if P(someone unknown is a robot) gets too large, it's going to be a weird adjustment period.
Oh I think they are! Gruber is by no means alone in his praise. And the technical details are impressive. (Plus the 14" and 16" are fantastic improvements.)
Yeah, it's not usually an issue in practice. But I do see students get confused trying things out...and it's likely because learning in an interpreter doesn't often look like "real" code does.
There's a bunch of things to pay attention to in Ruby. I wouldn't say these get too hairy, but they trip students up for very understandable reasons.
* `a ||= b` is not just `a = a || b`, but `a || a = b`
* The distinction between defaults arguments and hash arguments in functional signatures has many edge cases -- but it's much much better in Ruby 3.
* There are still 2 pieces of syntax for hashes (`{a: 1}` and `{:a => 1}`) They are the same.
* Curly bases show up a fair bit for a language that's not a braces language. :) They're in hashes, blocks, and % strings. e.g. `%w{a b c}` is the same as `%w|a b c|`. They're also used in string interpolation, e.g. `"Hello, #{name}"`.
* There are sometimes many ways to do the same thing. There's Procs, blocks, and lambdas. % strings work with many characters.
* `unless` for `if not...` and get wonky.
* Overusing "surprise if" e.g. `do_thing if other_thing` can be hard to read.
* It's so easy to monkey-patch and extend primitive classes, you might not realize when libraries do it.
All of these are features that I actually find nice to use in the right contexts. But they can pop up when you don't expect, and they can definitely make Ruby a challenge to learn. That said with a little discipline (or just a linter ;)), I find a lot of Ruby code a joy to read and write.
In that case -- I definitely agree Ruby usually gets out of way. It's often my go to for hacking on something, unless it's data science-y.
I'll mention: implicit returns, return if, and safe navigation, the &. operator. Ruby's newer pattern matching features are really cool[1], especially for things like JSON structures, but I've only use started using them. Classes are also super easy to extend.
Many of these things are also incredibly easy to abuse - but they have their places.
Comparing Apple Silicon and x86 as the difference between having modern plumbing or not...not exactly where I expected the review to go! Gruber's hyperboles can be entertaining for sure.
But damn, I can't wait for the time for me to upgrade my Intel Macs.
More productive is really hard to say... But I personally prefer Ruby to Python. For smallish scripts, I really like Ruby's backticks for easily executing shell commands. And I find the metaprogramming support in Ruby great for some tasks. I'm not sure if that's what you're getting at.
But especially with "modern" Python features like f-strings and the walrus operator there's not tons of differences that really stand out as "productivity".
One thing to just remember: Ruby is not just the Ruby on Rails community. Rails is a dominate space, but it's not the only thing out there. At the same time, when it comes to scientific computing, ML, etc. the Python ecosystem is incredibly robust. There's plenty of awesome Ruby tools for these things too, but it is not the same.
Ruby and Python are the two languages I primarily teach courses in, and used professionally. Ruby is my cup of tea personally, but they're both modern dynamic interpreted languages.
The fact of the matter is that it wouldn't even necessarily need to increase tuition. The UC system is a $50bn/yr enterprise. Lecturer salaries are a tiny amount, and really only about 20% or so of tuition money right now is directly attributed to instruction costs. If the University worked on a budgeting model that valued instruction, then I think the pay gap could be significantly reduced.
This is true, but it also sucks if we assume "part of a career path". That means there's virtually no teaching-focus career paths in the UC system which is terrible for basically everyone. (Students as well as other faculty.)
In reality, there's spots where it very well could be a career path but it's incredibly difficult to make it work in CS. (And in many many other fields too!)
Costs a crap ton for what it is, but it is nice.