"Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves."
I have to agree with the dead comment here. Focusing just on people is how we got to the stage of having extremely fast CPUs that can compute billions if not trillions of operations and yet websites and apps lag. We can run full fledged games at 240 FPS and yet, websites and apps lag. It truly is heresy to not fully utilize the hardware we create, such a waste, simply because people don't optimize at every step of the process, useless abstraction on top of useless abstraction. In game engines they do, to some extent, because they have to, and so should they in general purpose applications as well.
Web apps are usually slow because of (1) poor data modeling/unoptimized SQL/unindexed tables, (2) ad tracker bloat, and (3) single page applications that reinvent the DOM for $reasons.
Swapping out ruby for golang won’t fix any of those.
I’ve worked on multiple Rails apps over the past decade, responsible for hundreds of thousands of customers and hundreds of millions in revenue, that easily rendered every page in 150-300ms. This isn’t time-to-first-byte—this is fully rendered, images and all.
However, fixing all of those, which costs less in server time (and potentially even dev time, debatable)? I've seen hundreds of Rust based sites on a single 5 dollar droplet while the same would take an order of magnitude more servers. At scale, this gets expensive. See Stripe, Shopify etc that have found this out.
I run a busy production ruby app on a $40/month droplet. My performance issues are almost never related to ruby. It's nearly 100% of the time some complex database query that needs to get indexed/cached.
If coders write their backend in rust for "the ultimate performance", and it's shipping 20MB of javascript to query a poorly designed, poorly indexed database with no caching, they're going to get far worse performance than a ruby app querying a properly designed, cached database with indexing that doesn't have to spend 5 seconds domming the user's DOM first. Performance is a holistic problem, and anecdotally, web sites felt a lot faster during the rails era than they do right now during the JS era.
One abosolutely should be prioritized over the other. There's never going to be a situation where you can address every potential source of slowdowns, and make everything 100% efficient all of the time. Given that, in any somewhat realistic environment, you're going to need to prioritize where to spend your focus on making things more efficient.
It's certainly possible that the answer is that the language you're using is fundamentally too slow - I personally have almost never experienced that - almost always I can get more out of a time investment by focusing on improving DB performance, or some problem with delivery, caching or optimizing bundles.
You should look at your personal situation and use real data to decide where to focus, but you always have to focus. "Make everything 100% efficient at all times" is completely unrealistic.
To try to clarify: none of my 3 points above are fixed by rust, golang, or any other language, because they are not caused by Rails. Uncharitably, in my experience, these 3 bottlenecks are usually accidental consequences of decisions made by software developers who do not fully understand the whole lifecycle of a web application request/response.
I usually run Rails on two servers for redundancy. Any features that are CPU expensive I will spin off into a separate service (I’m partial to golang.) This is all on the order of $10s of dollars a month on AWS. 90% of most products’ landscapes are CRUD, and bottlenecked on IO to the database, not expensive CPU calculations.
Stripe primarily interfaces with 3rd party payment systems. Anytime a request has dependencies outside of the database, you’re “off the Rails” and should investigate additional options.
Shopify is a great example. Last I checked, Shopify is doing great still using Rails for 90% of CRUD and are optimizing just the 10% that they see ROI from.
That's fine, I never said everything is solved by switching languages. But oftentimes focus in performance in one area, ie language choice, is correlated with performances concerns over other parts of the app.
Apps and sites are pushed out fast, crammed with the everything including the kitchen sink and monetised to the hilt. This is more the reason why they suck these days, rather than because programmers are modelling abstractions from the human end rather than the machine end.
Hm, it's also because we use dynamic languages with shitty implementations. JavaScript has been optimized to hell, it has a proper JIT compiler, and it's extremely fast, about half the speed of C in many cases. Python and Ruby are inexcusably slow in comparison. We have the technology to make them fast, but the language implementations were born in the 1990s, at a time where everybody thought single-core performance would always double every 18 months. It's this kind of "performance doesn't matter" mentality that lead to poor implementations and a huge waste of CPU cycles. IMO, those languages will inevitably be displaced for performance reasons. It will take time, but it's inevitable.
I do like LISP, don't get me wrong, but the lack of speed and modern multicore support (actors and transparent parallelization like in Erlang/Elixir) has always put me off.
Maybe I am getting old but I started to be skeptical about language features and power if at the end I can't make it max all CPU cores and use async I/O everywhere.
I think we all could use a bit more pragmatism. I for one don't like Rust but I am relentlessly investing in mastering it because I do need low-level statically typed and compiled language and I still have PTSD from C/C++.
F.ex. I loved Racket. It is an amazing language and extremely well-crafted and thought out. But, call me when they have Erlang/Elixir's processes (actors) and preemptive scheduling.
Common Lisp with SBCL compiles to very efficient code, it can be comparable to C, for example. For multicore support, I'm sure there are good libraries available - lparallel maybe? (https://lparallel.org/overview/)
What don't you like about Rust? I haven't done any of it in anger but I did Advent of Code in it this year and have been having a great time. I miss some stuff like Python's generators and some of the crates I've found (like ndarray and euclid for example) have felt a bit incomplete but overall the language and standard library feel very well thought out and enjoyable to use.
There is a lot of obscure error messages surrounding lifetimes and borrowing. Most of the time I would have immediately fixed my problem by being told "you are returning a reference to the insides of a temporary structure, either clone it or make the structure's lifetime `static`" but no, I have to get an error about not implementing a certain trait with anonymous type parameter... :(
I'm getting there though. Rust is an acquired taste, plus I am very much sold on its premise and love the results. The journey, not so much. But I want to have that extremely powerful tool in my toolbelt so I am muscling though the learning process.
Thanks for this reminder, will do as well! Overwhelmingly I've actually been really impressed with the quality of the compiler diagnostics— 9 times out of 10 the prompt is telling me exactly what I need to do. I will try to do a better job of keeping track of the occasional bad/baffling ones.
And yet Ruby has a global interpreter lock and is an interpreted language. Ruby, I assume as a language, has had all the time in the world to develop well. Why don't we fully utilize our hardware while still allowing for high usability such as with Rust with algebraic data types or (if you don't want to deal with a borrow checker) recent C++ with auto pointers, or Haskell which is garbage collected but is still quite fast and of course highly expressive?
IMHO the answer is that Rust, C++ and Haskell are out there and anybody can use them to build a web site. Maybe the real question is why there are developers the prefer coding in Ruby. In my case, I barely used C++ in the mid 90s and only read some examples of Rust and Haskell. I can't really tell anything about Haskell. Rust and C++ look too hard to use, I don't want to care anymore about all that micromanagement stuff. I'm really with Matz on this. I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features. There are plenty of languages with that kind of typing, there is no need to have another one.
Actually I'm doing most of my money with Elixir and Python now. Elixir is nice except for deployment, like all the compiled languages I know. Python is much like Ruby but with weird design choices. Oh well, I guess that people coming from Python could say that the weird one is Ruby.
> I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features
I agree with the general argument, except this - keep in mind that typing in Ruby is optional (and will always be).
So devs who choose not to use it, they won't suffer any downside. There are also middle grounds - typing can be added gradually or locally.
Keep in mind though, that as projects grow large, handling dynamic languages becomes more and more challenging, and adding types is a good strategy to handle that.
This will change over time. There are already several companies using Crystal in projects. As they say, typically, it doesn't take many changes to migrate Ruby code to Crystal.
"It doesn't take many changes" unless you're using Ruby for the things Ruby is good at: dynamic generation and metaprogramming. If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch.
TBH, having evaluated it, I don't see a great argument for using Crystal in 2020 unless the criterion is "I want to use Crystal." Which is defensible, if that's how you want to roll, but it doesn't make for a good porting argument.
> If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch.
> I don't see a great argument for using Crystal in 2020
There is still the Ruby-like syntax appreciated by many developers and Crystal has also some other interesting aspects not present in Ruby or imperative OO languages in general, e.g. union types, powerful macros (see e.g. https://github.com/sam0x17/mongo_orm/blob/master/src/mongo_o...).
Ironically I find the lack of static typing in Elixir (and thus Erlang) its greatest weakness.
Dynamic typing only gets you so far. Once you get beyond a certain scale of your project (number of lines, files, modules etc.) then static typing a sanity saver.
I still love Elixir to death but the lack of static typing isn't making it favours.
Have you seen Gleam Lang? It's like Haskell but on BEAM. I was looking into it but I decided that since there's next to no ecosystem for it, I might as well go with something like Rust.
Yep, I did. Wanted to make Phoenix projects with it but it turned out to be way too laborious, so gave up. Elixir has some problems but it's still much superior to Gleam.
Yeah true. For me I couldn't stand Elixir's dynamic typing and switched to Rust. I just feel personally like I can't use dynamically typed languages anymore.
I don't see them at odds. They are mutually complementary. You can go very far with a fantastic dynamic language like Elixir. The loosely shaped data that bombard your app from the net is a perfect fit for a dynamic language. And the OTP concurrency / parallelism approach as well: you can have an actor per connection (while languages like Python and Ruby and PHP have struggled with thread pools and dynamic limits for ages).
I am starting to love Rust but again, I don't see it as a competition to Elixir.
I like the BEAM and I like the spirit of Elixir, but I find it really hard to write correctly and quickly. For me it's the weak inference and autocomplete. Ecto is pretty cool, but Ecto doesn't help me do the right thing in the way that even something like TypeORM (not my favorite database layer) does without much effort on my part.
I agree with you in the past Elixir deployment was a bit complicated, you needed to install packages and such, but today IMO it's well supported by the language and simple to do, `mix release` and voilà.
So you haven't used the languages I listed but you want to judge them? No shame in that but if you want to ask why people use Ruby, I'd say you answered your own question, it's due to inertia, and if you actually want to compare these other languages, you have to actually use them to some non-trivial extent.
And I'd also say a big one is Rails, I'm not sure of many people who use Ruby outside of Rails. But that is because they're using Rails despite it being in Ruby, not necessarily because of it, because again, they're more interested in the features that Rails provides rather than being enamored with any language feature per se.
No way, I learned Ruby after 20 years of programming. Languages that earned me money before Ruby: C, Perl, Delphi (or something on DOS similar to it), Visual Basic, a little Visual C++, PHP, Java, JavaScript, even some Cobol plus a number of other languages for fun (hello to Postscript, Tcl, Forth, Pascal, BCPL, several assemblys and too many others to remember). Ruby was so much better. Garbage collection as in all interpreted languages, no types to write and a number of niceties that made me happy.
As you wrote, I started with Ruby because of Rails and I slowly migrated all my scripts from Perl to Ruby. Ruby is the language I use for my projects, plus some Node when I have to. Everything else is too hard, life is too short to waste it wrestling with those other languages. If I had to write something very parallel I'd go with Elixir. We'll see what Ruby's Ractors will bring to us.
The fact of the matter is, Ruby and Python are badly implemented, speed wise. The other commentor states more about this. JS is super fast with a JIT but Ruby and Python are still stuck with slow implementations.
Seems about right. Luckily, if performance becomes an issue, you can probably scale out horizontally, or perhaps if you don't care much about sticking to the reference implementations, you can consider using alternative ones.
Of course, performance in real world scenarios and when using larger frameworks (such as Ruby on Rails or Django) may differ from synthetic benchmarks, but it's nice that at least there's work done in creating these alternative implementations. A bit like how we have Hotspot and OpenJ9 for Java as well or even how there's glibc and musl - that way you can choose which implementation is the most suited for your needs, be it for performance reasons or others...
You're caring too much. Why is it so important to you that two particular implementations of two programming languages are badly implemented and thus (which doesn't actually automatically follow, but nevermind that) slow? Are you being forced to use them against your will? Have you developed a trauma?
My advice would be to change a job and stop caring. It would be healthier in the long run...
As for the subject matter: yes, Python and Ruby are somewhat slow, which is absolutely fine for a lot of projects and in a lot of contexts. Where the slowness is problematic, they simply shouldn't be used, and if they are, it's an engineering or organizational failure. Don't blame poor decision making on the language implementation!
> Python and Ruby are somewhat slow, which is absolutely fine for a lot of projects and in a lot of contexts
You can say that, but it presumes they are better than alternatives in other regards when there are options with really no disadvantages but better performance. The primary reason for using these languages appears to be that they are easy to learn when getting started (either as a new developer or a new project). But when you think that you're optimising to save a couple of months coming up to speed on tech over a lifetime of maintenance and performance benefits ... it seems lazy to me.
I mean, I am forced to use them if I use apps, sites and services running on Ruby and Python right? And why shouldn't I care that things are slow? I don't really appreciate you sarcastically armchair diagnosing me with trauma which can be a serious thing for many people.
Except there is jitted Ruby. Rubinius and jruby to start. Even (C)Ruby 3.0 literally touts JIT as one of the pillars that make it 3x faster than 2.0, granted it is only optimized for a certain kind of code (not Rails) in 3.0.
Almost any web-public-facing project is very parallel so Elixir should be a no-brainer, provided no artificial limitations on which technology to use (which is a very generous assumptions, granted).
I think you're pretty much wrong on that last point. The people I know who love Rails tend to rave about Ruby the language. It's not personally my favorite (spent about 2 years with it as my daily language, no rails involved) but it has many many fans.
How can you tell that that is due to them liking the language because they work with a nice framework on top of it? If I worked all day in a a language, I'd like at least some parts of it.
These people had experience with many other languages prior to Ruby. And they choose it for non-rails projects.
A lot of the love for Ruby seems to center around the widespread use of generators and the clean syntax for invoking them. And some people truly love duck typing.
People are raving about all sorts of stuff and that doesn't mean they know what they are talking about. I've been a party pooper on a Rails meetup before, people were extremely clueless where Ruby ends and Rails starts. Nothing wrong about it, but it can be a bit worrying sometimes how much misinformation is being spread.
For the record, I like Ruby -- but no longer work with it. I feel there are languages that picked up its slack for years now. Might come back to it now with the 3.0 release (provided Rails works with it). Actually excited to see if it's better now.
So I am not mindlessly hating. But "raving" about something is not a data point.
Fully agree, using Tcl as Apache/IIS plugin in our own AOLServer inspired application server, while a pleasant experience, has taught me to never again use scripting languages for anything other than OS scripting tasks.
Sure, but the pendulum has swung so far in the "I optimize for dev time not server time" that people are forgetting how to write fast, efficient programs, and we the end users have to put up with that garbage like Electron.
There is this meme that Electron is so bad but as an end user I have much better experiences with Electron apps like Slack and Discord then I do with Microsoft Teams or other competitor apps that don’t use Electron.
Is Microsoft Teams supposed to be the fast, efficient alternative because I don’t think so...
The problem with Teams is that Teams doesn't have to sell based on user experience. Its sales pitch is "you already paid for an Exchange server or Office 365, so this is ready to go".
Haha guess it wasn’t such a good example then, I had no idea. But I do think Slack or Discord works as well as native Mac apps from the user perspective. I can’t really tell the difference between Atom and say the old Sublime Text or Textmate. If you told me they were all Electron I’d believe you other than Textmate being so old that it couldn’t have been when I used it
Electron afaik wasn't created because "people forgot" but because it's by far the easiest way to create a platform independent UI that's heavily customisable.
Web site bloat is largely due to web applications being optimised for product managers. Tracking, ad partners, etc...aren’t there for the developers benefit any more than they’re there for the end user.
Sure, there is bloat in a great many web frame works and I too question why some blogs need JS enabled just to render static text. But if we are being honest, by far the worst offenders for web bloat is the trackers and ad partners.
Why? Why do we have to make apps run fast? I run a self-hosted install of ArchiveBox and it takes > 10s to archive a webpage. If I am saving the page to retrieve it in a few years, I can surely wait 10-20s. One can say that an optimised setup may load and render a page in under 2s but why?
Apps need to fulfill our needs. Nothing more and nothing less. Just like you buy a Nissan Leaf to fulfill your need all while knowing that Bugatti Veyron is one of the fastest cars in the world pushing above 400 km/h. Just like I use ArchiveBox written in Python and SQLite while knowing that there is Rust and RocksDB out there that can outperform Python/SQLite.
Side note: I do agree that in some cases product owners take over both user needs and developers' good judgement and turn a good product into a horrid mess but I would argue you can do that in any programming language.
Go make yourself some drip coffee on this Christmas day and take it slow! Happy holidays everyone!
Speed matters. As a matter of UX, it feels good. People can tell when things instantly open up and load versus being sluggish. And it's also a matter of beauty. I like and appreciate things that fully utilize their forms. In software, it's apps that fully utilize the hardware. I was playing Doom Eternal the other day and it was just amazing the fluidity I got.
I fully agree! But not everywhere and not at all times.
> feels good
> matter of beauty
Well, that's not "matters" as in "must have", rather "nice to have" or "should have". See https://www.librarything.com/ for another example where a slow(er) app with high information density is preferred to a "nice" app (eg Apple Books "shelves" that are next to useless compared to this but sure enough, they are nice and fast).
> playing Doom Eternal the other day and it was just amazing the fluidity I got.
Well, this is where speed truly matters. The whole purpose of a game is to give you experience. Nice UX and fast graphics are a must because it's key to what the game shop is selling you.
I can see the difference between VSCode and Sublime Text. I also don't...care. I use VSCode because everything it offers is way more useful to me than a handful of milliseconds. Wider language support, better language server support, better autocomplete and intelligent suggestions, out-of-the-box formatters and linters for the languages I care about, a really genuinely great remoting solution.
And as you obliquely sniff at: it's TypeScript, and this is powerful. "Oh hey, I don't like how this works, I'm just gonna crack its brain open and write an extension for it" is powerful, and while I used Sublime Text for quite a long time its accessibility in this regard is much weaker.
True, but again this is the case where the primary function of an editor is to edit, so people naturally get upset when editing is slow. But if only Slack worked as nearly as good as VSCode does, I think we wouldn't be trashing Electron so much.
But then again, Electron is the best example where neither users want it nor developers particularly need it: users are fine if the UI differs across platforms and developers are OK to develop multiple native apps but PMs are not fine paying 3x or more for the product development.
Right, but then you are not just a developer but also a product designer/manager (in some capacity). 3 (30) developers would happily develop 3 native apps if a company was to pay them.
But speed doesn't come for free. You need to spend time either using a lower level language or improving algorythms, time that could be used to add functionality to the product. Speed can be a feature, but one of many.
I think you and I differ here because I really don't agree with this. Speed always matters. In fact, it is superlative, the fundamental feature on which other features must rest. I certainly won't use an app that's slow, even if it does more, because I get annoyed at the slowness.
You would have a hard time naming a AAA game which doesn't have a huge chunk of its actual gameplay logic in a scripting language (or something like Unreal blueprints). There's a huge amount of value in using different tools for the performance-critical parts vs the rest.
The programming language is often only a (relatively small) part of this problem. The choice of the framework (or, I'd say, the pollution of frameworks, as well as 40 MB libraries only imported to do dependency injection), wrong abstractions, wrong data models (if I'd had a penny for every time I've seen some code do a full list scan when it could have indexed the objects into a map I'd be millionaire by now), over-engineering, frameworks that reinvent the wheel (often in a much less optimal way, all in order to provide the developer with a bit of syntactical sugar), they all play a much bigger role in performance degradation than the language itself.
On top of it, projects are often lead by managers that are mostly interested in grabbing the low hanging fruits, pack the product with poorly tested features, set unrealistic deadlines and monetize as fast as possible, and they often don't provide developers time to breathe, take a step back and do any refactoring or optimization - those are too often labelled as purely technical tasks with no business impact and pushed down the priority line.
Some of the code written two or three decades ago was much more efficient (especially given the hardware available at the time) than today's projects both because developers were aware of building software for machines with a limited amount of resources, and because the software delivery timelines were much more realistic - aggressive marketing, sales and product departments hadn't yet completely taken over the engineering departments, and while agile methodologies were supposed to mitigate these issues they've actually only shrunk even more the delivery windows and made software development more hectic and shortsighted.
30 years ago a program that would choke on a 386 would be refactored until each single but was optimized for the available resources. Today's approach is simply "just throw more RAM/CPU power" - and that's what I frankly find unacceptable.
Oh, one more reason I forgot in the case of webapps: 3rd-party scripts and trackers. I've been using NoScript for years now, and that forces me to explicitly whitelist any domain used for scripts on a website. Once you start looking at what major websites do, you start to understand the problem. Most of the newspapers on the web, for example, often employ 20 additional script domains on top of their own - for anything from analytics, to tracking, cookie banners, ads, adblock detectors, Hotjar, Taboola, and so on.
We often (justifiably) argue that deep learning, as it's done today, is something unsustainable for the environment. I wonder if anyone has ever measured the impact of running tons of non-functional scripts on the web pages rendered every second by billions of devices around the world.
We can run full fledged games at 240 FPS and yet,
websites and apps lag
This problem is real, but addressing it in the context of Ruby is misguided.
Slow websites?
It's the overall system design of the web. Running a bunch of untrusted sandboxed code, retrieved asynchronously from potentially dozens of sources?
Yeah, that's gonna be slow.
Replace all the Rails sites with assembly code running on bare metal if you like, it's not going to change anything.
Ruby on Rails is plenty fast. You can serve up static pages in a few milliseconds. If they take longer than that, it's because you're doing a bunch of work at the database layer or some other work outside of Ruby.
i think this has less to do with "concentrating on humans" vs machines and more to do with "business requirements" that are ever-changing which causes insufficient time to work on optimization and siplification... all we get are piles of code upon piles of code...
the other side of that is in the web, the tech stack was not at all designed for what we are trying to make it do...
add those two things together, add a dash of network latency for all the loaded resources, and you easily get what we have today...
I agree with the general sentiment but it has been brought to an extreme to the point that things in many dynamic languages are way too slow. Maybe some of the CS courses are to blame; people think "hey, let me make my own language and an interpreter!" -- and the rest is history.
IMO a chunk of the programming world is entering a mature stage where much more work is put in the runtime of a language on not on the language itself. End of the day, you are going to have a call from an executive asking why the hosting bills are ballooning. I've saved some of my customers literal [tens of] thousands of $$$ a month by migrating a critical chunk of their services from Ruby on Rails to Elixir's Phoenix and, on one occasion, Rust's Rocket.
Programmer ergonomy and happiness are important, don't get me wrong. But IMO we are fixating way too much on them in some languages / frameworks. Some pragmatism should be put back into the picture.
> things in many dynamic languages are way too slow
"No matter how fast or slow your language might be, there will always be some applications for which your language is fast enough and some for which it's not."
I agree. When I think Ruby it brings to mind the Chef code base. Massive amounts of indirection via one line, but only one time used?, methods. Mixin abuse requiring manually searching an ungodly number of files to figure out where behavior is coming from. Errors pointing to non-existent lines of code because somebody thought it was a good idea to generate classes in loop to avoid boiler plate. Sandi Metz' "come to Jesus" book.
As a computer engineer you need to focus on computers, not people. I know this is popular right now, but it sucks and it is wrong and leads to bad results. Yes, the current state of affairs is a "bad result", young ones.
We expect civil engineers to account for people, but they think about materials, planning, math, etc. Stay close to your craft or you might see it and/or your position in it evaporate.
At the design level where stresses strains and loads are the considerations, it’s nothing about the people. I think that’s the level the parent was thinking of.
The fact that all static languages are adding an Any type means the discussion is settled.
Lol. How has this settled anything? You think Ruby devs from now on are all gonna use Sorbet or RBS? I highly doubt it. Some very unique companies like Shopify or Github, which don't really represent the average Ruby shop, may make a limited use of these tools. The vast majority won't.
>The fact that all static languages are adding an Any type means the discussion is settled.
They really aren't, though. No statically typed languages which started off as such, to my knowledge, have added an Any type (casting magic notwithstanding). You must be thinking of TypeScript and other "gradually typed" languages, where it's a necessity for interop with existing code.
The rest of your comment, unfortunately, does not really put forth any coherent argument, so I would tend to weakly agree with the parent comment.
Which was added to support COM variant types as main goal, and as side effect of trying to make the CLR a good target for Python and Ruby, an effort that has mostly died and is kept around just for backwards compatibility.
They add an "Any" type because they have no choice, what are you on about? You can't change a dynamic language to a statically typed language overnight. Or over a year. Or five.
You are not furthering your argument, you are just reasserting the status quo.
Okay you convinced me to stick with my assessment of ruby. I regret every single time I have chosen to write something in ruby. I guess this release won't change that if nobody uses these features.
No, it won't. If you don't like it you don't like it, it's alright. I'm not trying to convince anyone to do anything most of the time, stick to what makes you happy and productive.
> The fact that all dynamic languages have adopted some kind of static verification tool has settled the discussion.
No, it hasn't.
The fact that there is utility to static type checking that is sometimes a net win so it is better, ceteris paribus, for a language to have it available does not “settle the discussion” about the claim that dynamic typing was pure lazy design that was never in the interest of human developers.
It was, back when all mainstream statically typed languages had atrocious UX and there really was no good example of a language with ergonomic typing. Even now, there are very few languages around which has that. The most ergonomic I know of is Crystal, which is not surprising considering its heritage.
Matz 2003
https://www.artima.com/intv/ruby.html