Quite to the contrary, I'd say this update is evidence of the inner loop being hyperoptimized!
MSVC's support for musttail is hot off the press:
> The [[msvc::musttail]] attribute, introduced in MSVC Build Tools version 14.50, is an experimental x64-only Microsoft-specific attribute that enforces tail-call optimization. [1]
MSVC Build Tools version 14.50 was released last month, and it only took a few weeks for the CPython crew to turn that around into a performance improvement.
Because Ruby is just a better thought out language than Python is. It had a sane package management story 15 years before Python. It doesn't rely on weird hacks like exception throwing for iterator control flow. It doesn't have nearly as many warts and footguns on basic operations (for example, in Python csv.writer(file).writerows(rows) is broken unless you remembered to set the newline mode on the file; in Ruby file.write(rows.to_csv) just works). Thanks to a sane VM design it's mainline JIT can actually run code faster than interpreted code (something that CPython's JIT can't do [1])
Many Pythonistas are woefully ignorant of what's going on outside their siloed community.
Having immutable objects by default isn’t incredibly commonplace outside of functional languages. It certainly isn’t unique to Ruby and seems out of place in a discussion comparing Ruby to Python. Fortunately, you can defensively freeze any objects you’re passing around to avoid the most common issues with mutable objects.
Immutable strings is a more popular programming language feature and Ruby has a mechanism for opting into that. It’s so commonplace that the complaint usually isn’t that a string can be modified, but rather that every source file includes a magic comment to prevent that. Besides data safety, the VM can optimize frozen strings, so popular linters will flip that setting on for you. String mutability isn’t a practical issue for modern codebases. And, as language design goes, it’s kinda nice not needing to use a parallel set of classes for mutable and immutable string data IMHO.
With that said, the magic comment is a wart and folks are looking at making immutable strings the default. But, there’s a strong desire to avoid breaking the world. The Ruby Core team is keen to keep the lessons learned from the Python 2 -> 3 migration in mind.
Not only a wart but a massive foot gun, not shared by any other language, as I said. It is incredibly common to create hash tables using strings as keys, and Ruby makes this dangerous by default.
> Having immutable objects by default isn’t incredibly commonplace outside of functional languages
They make it easy to create immutable objects. Python has tuples and immutable data classes. Strings are immutable.
> The Ruby Core team is keen to keep the lessons learned from the Python 2 -> 3 migration in mind.
In the meantime, this ridiculous foot gun that no other language shares exists. That is a fact, and the fix being hard does not make it any less of a fact.
Let me counter with this: Can you point out one country in the post world war era that had minimal government investment in science but had very productive scientific output? Or can you point out one country where scientific productivity increased after public sector investment in science was slashed?
I think you hit the nail on the head with the analogy to Doctor GPT, but I think you missed it with gatekeeping. I don't think it's about gatekeeping at all.
A freelance developer (or a doctor) is familiar with working within a particular framework and process flow. For any new feature, you start by generating user stories, work out a high level architecure, think about about how to integrate that into your existing codebase, and then write the code. It's mostly a unidirectional flow.
When the client starts giving you code, it turns into a bidirectional flow. You can't just copy/paste the code and call it done. You have to go in the reverse direction: read the code to parse out what the high level architecture is, which user stories it implements and which it does not. After that you have to go back in the forward direction to actually adapt and integrate the code. The client thinks they've made the developer's job easier, but they've actually doubled the cognitive load. This is stressful and frustrating for the developer.
Web browsers, yes. With GUIs and games, it's a less clear. Of course you can write GUIs and games in any Turing complete language but there's still a lot of work to be done in finding the right ergonomics in Rust [1, 2].
Because fiddling with Windows firewall settings is a power user feature that only a fraction of a percent of users will touch. If it ever becomes more widely used, then I agree, all bets are off.
