It’s not very often a Ruby article pops up in my newsfeeds, and this was… interesting?
3 Likes
I wish this was at the beginning of the post rather than the end:
A RuboCop Perspective
You might be wondering I am so grumpy about a bit of chaos during the development cycle of Ruby? After all it seems that most problematic features tend to get improved/removed.
I’m the author of RuboCop, a popular static code analyzer and formatter for Ruby, that’s why my perspective on all of this is probably different from that of many other people. Together with RuboCop and Parser’s team we actually have to support all of those language changes. Imagine how fun it is to add support for something, change this a couple of times, while tracking upstream changes, and then just delete it at the end. Or to have to do complex changes to support some new syntax that probably is going to be used by a handful of people… Trust me, that’s get frustrating after a while, and we’d definitely appreciate less turbulence in the design of the language.
Personally I think it’s great that languages and tools evolve over time, that’s how they adapt and stay modern/relevant - more important in some areas than others. I agree with the poster that more community involvement would be good. Unfortunately due to much of Ruby’s core team being Japanese and non-English speakers this has always been challenging for them.
Ruby certainly hasn’t been standing still these last few years either, in fact I think the pressure from other languages (and people moving to them) has been a major factor in ramping up improvements. For instance they (as well as other languages such as Crystal) are forging ahead with concurrency and other improvements (such as those we see in Rails). As a result I see less people moving away from Ruby and Rails and in fact many going back to them.
Tldr: I’m all for progress 
3 Likes
I saw a stat recently that showed Ruby’s 2019 market share fell by another significant amount and Python’s rose again, and Python is about to take the top language spot from Java as funky as that is (AI stuff I’m guessing).
3 Likes
Which one? Most of those stats are usually pretty unreliable.
But yeah Python is definitely doing really well thanks to all the AI stuff 
I’ve always respected Python (it was in my shortlist when I decided to go with Ruby) personally I can appreciate a language even if it’s syntax isn’t to my tastes 
3 Likes
Either stackoverflow’s or github’s, think those were the only ones I’ve seen in the past few months.
I really need to get around to learning the Modern AI stuff, my old knowledge of it is pretty worthless now. ^.^;
2 Likes
Python has:
- Web frameworks
- Django
- Pyramid
- Flask
It also has the possibility to chain: AI with web frameworks, games and Gui in one language. So python most definitely becomes a very powerful tool.
Also i forgot to add Linux scripts and ethical hackers tools.
So those stats can reflect that. Not just the AI usage.
2 Likes
My main reaction to that is that there are people writing Ruby today that really wish they were writing Elixir. Most of the features mentioned there (numbered params, pipelines, the method reference operator) are obviously Elixir-inspired.
This urge can run deep in a project, sometimes to the detriment of their Ruby code quality. For instance, a local startup has most of the code in its Rails app written as module_functions… that all take the same kind of value as a first argument…
3 Likes
Disclaimer: what follows is my personal opinion, I don’t claim it as “objective truth” 
First, on Ruby’s merits, or lack of, as a technology:
I think Ruby (and Rails) is still an outstandingly good platform for web development. Very successful companies are based on it, the community is still awesome, and the ecosystem is large. But wait, isn’t it {slow/not concurrent/too dynamic/etc.}? Yes. Maybe. It depends. And, more importantly, does it really matter that much?
What I mean is, any team is free to evaluate if in their specific case there is a better choice, but Ruby/Rails is still a great general purpose web development platform: you can definitely do better in any specific area, but as a whole Ruby does a very good job. A good general purpose technology is what many, many companies need. Most companies are not Google scale, and most applications do not have to squeeze every last millisecond. Good developers are harder to find and more expensive than servers (and more and more so), so this is a great trade off in many cases.
What happened is that Ruby, after its early years as a “rebel”, finally became “establishment”, and as such we give its qualities for granted and criticize its limits. That’s perfectly fine, it’s in the life cycle of technologies. But let’s not mistake “buzz” or “engagement” for success and adoption. Ruby is doing fine, it’s just not the cool kid on the block anymore, and that has pros and cons.
Now, about the blog post:
I think it is also perfectly ok for technologies to evolve, and to learn from each other. If good ideas spread, we all win. I have mixed feelings about some of the new syntax additions to Ruby, but then again, nobody is forcing me to use them. While I understand some of the points made by the article, I smell a little bit of ego from the author (which is also the author of the very opinionated Rubocop formatter) as a “keeper of good syntax”, as well as a bit of “I told you so” rhetoric. Yes, some syntax changes were tried, and those that generated more confusion than value were removed before the release, is that so wrong? It sounds to me like a honest way to get feedback from early adopters.
In my view, what is happening is that as Ruby is not surfing the hype curve anymore, its not a good community for “celebrities” anymore. Some of them stayed and enjoyed the quieter productivity, some moved on to other communities, some instead are surfing a bit the “not like the good old times anymore” wave.
5 Likes
High-level talent has left Ruby, and now it’s infested with midwits who want bureaucratic control. Even Matz can’t keep them at bay. The freezing of Elixir core language was maybe one of the best ideas ever.
3 Likes
That’s quite humorous. ^.^
Absolutely this!
3 Likes
There were people writing Ruby 7 years ago that really wished they were writing Elixir.
This is Gary Bernhardt (of WAT fame):
“contribute to rubinius for a year till you know how it works, then fork the ruby language… you want persistent core types… you probably want actors and lightweight processes, you’re going to have to build a userland scheduler, but it’s not that hard, that’s what erlang has”
But also really watch the whole video; it’s basically the core of how one thinks about programming and testing elixir.
2 Likes
I write all my new Ruby code in (1) pure functional style (module functions) with (2) explicit namespaces. Ruby coders barf when they see it. But I now have a fighting chance at writing maintainable Ruby. The code is also easy to parallelize with the parallel gem.
5 Likes
It really does matter that much. In 10 years of writing production ruby+rails, I’ve constantly run into problems caused by all three of these that have been roadblocks, or generated enormous cost:
- Too slow and I can quantify the damage. Ruby can be fast. I did get my production apps responding under 200ms for every request. But I spent months of time optimizing and re-optimizing to achieve that. I pay for expensive memcache servers. And I was forced to develop skills (Rails optimization) that don’t add business value. And the codebase is less expressive for it. Meanwhile, Elixir/Phoenix delivers phenomal speed out of the box. It’s “free”. I can spend time delivering features, not baseline performance.
- Not concurrent and stopped development of my RSpec in the cloud project in its tracks. Impossible to run RSpec multithreaded. Will likely never be possible. Am considering Elixir/Phoenix rewrite. And of course, the no concurrency means that web server config requires another deep dive (e.g. becoming a Puma or Passenger expert) that Phoenix provides for free.
- Too dynamic to be easy and fun to use. The language absolutely defies static analysis. No tools work well. There’s no such thing as autocompletion. There are no true Ruby IDEs. The closest might be Ruby Mine. But it can’t even open up a new vanilla Rails app without a sea of false positive errors. IMO, it’s vaporware.
5 Likes
Small side remarks: I read several articles about unrealistic expectations about AI. One of those: https://softwareapplications.com/how-to-recognize-ai-snake-oil/
Pyton has an interesting feature called “gradual typing” https://realpython.com/python-type-checking/, fb did some research
https://research.fb.com/wp-content/uploads/2019/09/Optimizing-and-Evaluating-Transient-Gradual-Typing.pdf
2 Likes
Hey! I work at a company that makes bank from unrealistic expectations about AI. Don’t spread that article around 
2 Likes
I seriously wish I could upvote @dogweather’s comment 1000 times. Yes it matters, much more than people are willing to admit while they are still in their “we just raised $300,000 in Series A investment” euphoria state.
As he said, you jump almost straight up to delivering business value and not working on a baseline expected performance. A fresh Rails MVP project with 2-3 weeks of basic functionality added has an average response time of 250ms on an otherwise pretty strong machine like the MacBook Pro 2015. This is absurd. It’s almost 2020. If your programming language or framework cannot tick a basic set of boxes without extensive hand optimisation in the first stages of the project then it should straight up be not recommended for commercial use. This is not about fandom or belonging to tribes. This is having a sustainable business common sense.
Rails is still valuable, though. Valuable in the meaning that you can unquestionably sketch an MVP faster than many other languages and frameworks, Phoenix included. I’ll give it that; its scaffolding abilities are nice. You can also use it for internal company web apps that are never expected to get more than 10-20 active users a minute. And that’s it. You go beyond those limits and you will curse your life because you will have to pay for memcached and Redis servers instead of, you know, just use :ets or :persistent_term and have them respond to you in the single-digit microseconds space. I worked with Rails 6 years and many times I was tempted to just hand-optimise a C/C++ program. It was that bad and it was the status quo 95% of the time. Only exceptions were two very carefully hand-optimised Sinatra + Sequel projects (meaning no Rails and no ActiveRecord). And that took quite some effort to get right and fast. Still not worth the effort IMO.
(Another example I periodically mention was how a rewrite of generating reports from Ruby to Elixir yielded huge speed improvement; it went from ~3h on average to ~7m).
@lucaong I do agree with your thoughts on the blog post’s author. He seems simply burned out. He had the expectation of the language and the ecosystem stabilising and not requiring so much grooming through its 3rd party tooling, and sadly that wasn’t the case. Which is 100% fine; he can simply step down. His work has been very influential in the Ruby / Rails community and I am sure others would be happy to pick up where he left off.
3 Likes
I have even implemented the proper polymorphism in ruby (spoiler: by fully replicating Protocol from Elixir.)
4 Likes
