DEV Community

Please stop using Ruby

James Harton on September 12, 2018

I know what you're thinking but I want to start by saying that I love Ruby. Ruby is the language that made programming fun again for me after losi...
Collapse
 
thecodetrane profile image
Michael Cain

So...respectfully, I am going to go in on this.

I really feel like we need to slow our roll on shit-talking Ruby on Rails. Very few of us are ever going to have to worry about scale on a level where Ruby‘s raw performance metrics are going to be that impactful. Plus, let us not forget one of the main tenets of Ruby: programmer happiness.

I did not go to school for CS, so I don’t have the acquired taste for FP that a lot of folks have, I guess. I’m a digital carpenter; I want the code to be clear, easy to understand and flexible. Ruby is one of the best for that.

If you really think that you’re going to be managing 1M connections on one node a la Elixir (WhatsApp), go for it. That said, let’s keep the click-baity holier-than-thou hot takes to a minimum.

Collapse
 
sam_ferree profile image
Sam Ferree

You don't think there's anything holier-than-thou about idea that Ruby is one of the happiest languages to code in? Is the hardly subtle implication that engineers who care about performance can't possibly care about readability really going in on this respectfully?

What are the metrics for programmer happiness? How did you collect your data? What's your sample size? How can you even begin to honestly substantiate that claim beyond "I like it and everyone who insists on using it despite it's demonstrable problems likes it."

Everyone who insists on writing C# likes it, and people who insist on writing Elm are convinced that functional programming is obviously the most pleasant. Some people still swear by Ada.

Ruby is one language of many that allows you to write readable code.

And while there are languages that make it hard to write readable code; there are zero languages that make it hard to write unreadable code. Ruby doesn't even make writing unreadable code the least bit difficult.

I once was stuck on a rails error for 2 hours because I typed validate instead of validates. Any compiled language's editor would have caught that as soon as I typed it. Ruby was able to spin up the whole app and run indefinitely without ever feeling the need to say "BTW, I don't know what that method is."

Is "Please Stop using Ruby" a click-bait headline? For sure.
Are some of his criticisms of the language valid? Absolutely.
So yeah, this should have definitely been titled something like "Considerations to take into account before starting your next web project as Ruby on Rails"

Collapse
 
thecodetrane profile image
Michael Cain

I never said "Ruby is one of the happiest languages to code in". I said it's primary focus is "developer happiness', which is direct from Matz.

I think the fact that RoR is the de facto on-ramp for most devs coming out of boot camps says a lot for its accessibility. Is Ruby the happiest language? Highly unlikely! People are made happy for all sorts of reasons.

My whole point was addressing the obviously craven title and the nasty habit people have for shitting on other peoples' tools. Write your next app in mindf*ck for all I care. If that's what makes you happy and it does the job, great! The idea, however, well all need these super-concurrent, ultra-fast, functionally-programmed, EVERYTHING-less apps is silly. Very little of what most of us do is a) that serious and b) even going to be around in 5 years.

Thread Thread
 
sam_ferree profile image
Sam Ferree

You’re absolutely right that shitting on people’s tools is bad.

I don’t know that i’m aware of sufficient evidence to agree that “what most of us do is [not serious enough for the performance concerns to matter].” And the claim that what most of us are doing isn’t going to be around in 5 years disagrees with my experience. Anecdotal I know, but a company a worked for until recently still maintains and adds new features to and ASP classic application.

Thread Thread
 
thecodetrane profile image
Michael Cain

I certainly agree that languages/frameworks persist. I work on a team as the only RoR guy with a bunch of Java developers. We have services in C# all over the place. All the more reason to cease and desist with the "mine is bigger than yours" malarkey.

Collapse
 
mhenrixon profile image
Mikael Henriksson

validate is also a claim method in rails. Your example does not prove your point at all. It just shows you don't know rails well enough. Sorry, couldn't let someone be wrong on the internet. 😂

Thread Thread
 
sam_ferree profile image
Sam Ferree

"I don't know rails well enough" exactly proves my point when the opposing point is "rails is a productive framework and makes developers happy!"

Collapse
 
shalvah profile image
Shalvah

Just here to say that I love your "digital carpenter" phrase! Adopting it ASAP! 😆😆

Collapse
 
ondrazizka profile image
Ondrej Zizka • Edited

IDK man. I am in like 7th company in my life, ranging from 10k employees to the current startup of 100, and in all of them, the apps deal with thousands of parallel connections. And it is big difference if your hourly batch takes 15 minutes on JVM or 3 hours on Ruby, because then you need to write your app as parallel right away (something not easy to do in Ruby) and them run it on 3 nodes, just because someone liked Ruby.

Your metrics for happines, clear code, easy to understand and flexible are subjective; personally, with Ruby, I was unhappy, the code was mostly messy, hard to undestand, ad very rigid.

Collapse
 
89885512495 profile image
Sony

sry...but do you think that this code is easy to understand:

vowelsCount = Hash['aeiou'.chars.map{|n| [ n, 0 ]}]
gets.chomp.chars.each{|n| vowelsCount[n] += 1 if vowelsCount.key?(n)}

I am doubt.

Collapse
 
thecodetrane profile image
Michael Cain

You can write unintelligible nonsense in any language, my dude. Ruby's focus is "developer happiness", and I feel that it delivers. If you prefer to make yourself miserable, Java will welcome you with open arms.

Collapse
 
jerodsanto profile image
Jerod Santo

Please stop using absolutes in article titles. It's condescending and only serves to annoy, infuriate, or (worst of all) repel your prospective reader. 💚

Collapse
 
fareedjaved profile image
Fareed Javed • Edited

It's strange to see someone who benefited so much in their career from using Ruby and RoR turn around and discourage others from using it as well. The reasons you list to not use Ruby lack nuance. For example, you claim Ruby is slow, but what are you comparing it to and in what situation? Yeah, Ruby doesn't take advantage of multiple cores, but that doesn't mean it's useless.
And the reasons you list why someone should use Rails are incredibly backhanded. Saying someone should use Rails if their app never changes or if it doesn't have complicated logic is not apart of a #healthydebate.

And just because a language is faster and compiled that does not guarantee that you will write better software.

The point of rails is that it lets you develop and iterate over a prototype very quickly. This is the reason a lot of successful companies were able to get off the ground and make money relatively fast.
Also, those same companies have used Ruby for very complex systems. An example is Airbnb, who wrote their large scale payment application initially in Rails. While they did migrate to Apache Kafka & Spark, they did it because of the massive increase in users, not because Ruby isn't multi-threaded.

Ruby and RoR were never meant to be the perfect tools but only focusing on their drawbacks isn't enough for telling people to stop using the language. And it's frustrating to see this kind of thinking in 2018.

Collapse
 
skatkov profile image
Stanislav(Stas) Katkov

I can relate to your experience, James. I tried moving to other frameworks, even to better option you mentioned.

But rails has one big upside, which is hard to ignore -- maturity of libraries (gems). With a big probability I can find a library that satisfies my picky requirements.

With Phoenix and Elixir I still find myself spending too much time on very trivial things. Since I'm an indie dev -- this is a luxury I can't afford.

But I can afford rewriting some components in languages that performs better, if there is a bottleneck in Ruby itself. But in a lot of cases, I just know how to make Ruby performant :)

Collapse
 
jimsy profile image
James Harton

I agree that Rubygems is one of the main reasons that people stick with Ruby and it is an amazing resource. I've written my fair share of gems over the years and I hope that they helped people in some way. Working with Phoenix can be pretty annoying when you can just get a hex package that just handles user authentication the way that devise does - you have to wire up a lot of code to get it to work. I think this is mostly about maturity but I think it will get there. I once joked that Elixir is powered by thousands of angry Rubyists and like all jokes I think there's more than a grain of truth in it.

Collapse
 
shevegen profile image
markus heiler

Rubygems is great but I do not rely on it.

I can write whatever I need just fine, if I need it.

I wrote my own "package" manager in ruby and have been using that for ~13 years to manage my *nix systems.

I once joked that Elixir is powered by thousands of angry Rubyists

Elixir has great ideas; erlang is awesome, but the syntax of erlang is UTTER SHIT.

But even then, too few people use elixir; and even fewer use crystal.

Say what you want about ruby but ruby IS used by LOTS of people.

I think this is mostly about maturity but I think it will get there.

This depends on how many people use a language. Crystal struggles a lot because of this - too few people go into crystal. Which is a shame. But I myself also am not using crystal, primarily due to lack of time; but also because the type-madness leads to syntactic monsters that I don't want to deal with.

Note that ruby 3.0 will get additional type information, so some of your fake-complaints above may be answered.

I still think your article is horrible though. Please try to make your points more objective in general.

Collapse
 
richjdsmith profile image
Rich Smith

Yep, as a one-man-show, it's tough to argue there are a lot of better options that allow for more productivity/hour than RoR.

If I find myself in a situation working on something that has 1mm connections simultaneously, sure, I'll use Elixir. But to spin up a CRUD app, which honestly, are still to this day, most online web apps, Rails and Ruby are tough to beat.

Collapse
 
shevegen profile image
markus heiler

I use my own fake-webframework (created before rails came out).

Granted, it is way below feature parity with rails. But it also does not want to be feature equal.

I also use sinatra so I more belong into this world of simplicity.

And I am mega-productive related to the www there too, without needing RoR (but I value simplicity at all times; I hate the complexity of rails).

I just wonder why people think the www in ruby belongs to rails. I don't see it that way at all.

Thread Thread
 
princejoseph profile image
Prince Joseph

what is your framework?

Collapse
 
tux0r profile image
tux0r

While I agree with the assumption that we need to watch our website's performance and we should stop deliberately using slow languages (like Python and Ruby) and frameworks, this article missed the chance to point out that the most common problem with slowly loading websites is that they include a few megabytes of JavaScript which needs to be downloaded and parsed first.

Collapse
 
pim profile image
Pim

BOOM

Collapse
 
renich profile image
Renich Bon Ciric

And executes code on your machine...

Collapse
 
betogrun profile image
Alberto Rocha

The #healthydebate hashtag and this clickbait title doesn't match.

Collapse
 
rhymes profile image
rhymes • Edited

A few points:

  • Rails is adapting to this world that just doesn't ony "shuffle data back and forth" (integrating webpack, adding websocket support). Also stimulus.js by Basecamp goes into that direction

  • Ruby is getting better and better (well it would be funny if it got worse :D): there's talk of adding JIT compilation, guilds (sort of isolated processes in user space) and type decoration

Maybe it won't innovate fast enough and lose developers (it happens to every technology I guess) but there's a valid argument for it you didn't make: there are still tons of Rails jobs :-)

Rails (and Django) are turning into "boring technologies", which is not inherently bad :-)

I'm more optimistic about their future.

Collapse
 
ben profile image
Ben Halpern

My sense of parcel anxiety from yesterday is eased big time from leadership in the Rails community which does a great job of sniffing bullshit in web development and keeping things smooth.

This probably keeps me in Ruby more than anything else.

Although Rust and Elixir and others have a lot of former Rubyists leading the way in DX and pragmatism, as the post implies. Still, Rails makes me feel like I have some serious teammates in the game from small-to-medium-to-big organizations and lots in between. It's such a rock solid boring ecosystem.

Collapse
 
jimsy profile image
James Harton

This is really great to hear and I am forced to admit that I stopped following along with changes to Ruby a few years ago.

I also agree that "boring" is exactly what you want in production. But boring and slow?

Collapse
 
rhymes profile image
rhymes

"Fast enough". This is a really good article from an expert in Ruby and Rails: Is Ruby Too Slow For Web-Scale?

Collapse
 
spidergears profile image
Deepak Singh

No, I won't. I would only agree that Ruby is not the go to language for everything you do or for everyone / every project.

That being, please weigh your choices with care, use matrices that make sense and avoid noisy opinions you see on web.

Collapse
 
stereobooster profile image
stereobooster

Because Ruby's semantics defy almost any kind of static analysis where a user of another language could add a type constraint

I will leave it here:

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

Looks like Javascript+Flow to me, which is by far not as capable as Typescript. I love Ruby, but typing is a language feature and does not belong into a library. IMHO. Hope Ruby 3.x will come with optional typing.

Collapse
 
stereobooster profile image
stereobooster

This will not happen. I saw a quote from Matz that he believes that type signature will be obsolete in 10 years and he doesn't want to add them (I will need time to find it). Important: he didn't say that he against static types (he is for it), he didn't say he against static analysis (he is for it).

The second point, nobody wants to repeat the Python2 vs Python3 situation, so it will be a gradual type system (I guess).

Javascript+Flow to me, which is by far not as capable as Typescript

I'm doing a series of blog posts on Flow and TypeScript. There are, for sure, differences, but not so dramatic. The biggest issue with Flow is closed development, awful tooling and not very big community, but not the power of the type system itself. It is fairly comparable to TypeScript.

Collapse
 
yoelblum profile image
Yoel • Edited

So it's basically a long and click baity article about static types > dynamic types? Wow never heard that argument before. Oh yeah and the performance issue, of course. Happens to me everyday at work when I need to sprinkle more performance on my app but alas Ruby fails yet again. If only it was written in java.

Collapse
 
northbear profile image
northbear • Edited

I didn't see any reason to stop using ruby in my private automation tasks. Using ruby in the company productions is usually question of managers that keep in mind a lot of reasons that sometimes is not technical related.

  1. GIL does not cause any problem for python to grow up. So why should it be problem for ruby?
  2. Ruby concurrency (don't mess it with multi-threading) actually works pretty well via fibers. This approach is pretty popular in other scripting language. For instance Python has a lot of libs that implements of actor model: Pykka, Thespian. Asyncio is included in stdlib of Python 3.4 and so on.
  3. Ruby is not Rails. Yes, rails helps a lot to ruby to rise up. But now rails is big problem for ecosystem of ruby itself. In ruby community there is term "rails programmer" that much differs from ruby programmer. There is a lot of rails programmers but the knowledge of ruby outside of rails of most of them is lack pretty much.

So, It is totally your solution to stop programming in ruby. Ruby get losing its positions in competition with python, it's the fact. And I feel sick of it. I suppose it happens mostly because of marketing reason, not technical. Guido living in America has much more ability to promote python in Hi-Tech than Matz living in Japan. Plus Matz is pretty introvert guy. So...

Collapse
 
kyegupov profile image
kyegupov

Not really. Ruby has been always inferior to Python technically and practically. Python had cleaner C bindings (which enabled Numpy, Cython and numerous other libraries). Python code is easier to debug and maintain: more explicit, less metaprogramming, fails early, better documentation.

Python also had "threading" library for ages. And its Unicode support was much better than Ruby's even in the days of Python 2.

I find it's hard to take seriously OP's arguments about Rails being "the only tool" in 2008 (I remember writing easily maintainable MVC websites in Python around 2006-2007) and Rubygems being the only package library (PyPI appeared 2 years earlier).

It always seemed to me that the only reason to love Ruby is to know nothing about Python.

Collapse
 
northbear profile image
northbear • Edited

Actually I don't care what comes early or later. The point is what more or less comfortable to use in practice. It's absolutely subjective.
By example I am eager with Ruby for ability to write one-liners like:

ruby -e "Dir[\"./**/*.*\"].map{|i| File.dirname(i)+' '+File.extname(i)}.inject(Hash.new(0)) {|h,a| h[a]+=1;h}.sort_by{|k| k[0]}.each {|k,s| puts \"#{k} => #{s}\"}"

This one for example calculates how many files of what types exist in current directory and it subdirectories. I write similar one-liners in bash CLI without editor. How to write similar things things in python, I have no idea.
I know Python pretty well. I use it everyday for ALM automation for already 3 years. But anyway there still is wondering things in Ruby for me.
Rails is "the only tool ruby need for" mostly for people that usually far anough from ruby community. It's just popular internet mem that far from actual state.

Thread Thread
 
kyegupov profile image
kyegupov • Edited

I don't envy any person that would support such "one liners", but here's the Python version:

python3 -c 'from pathlib import Path; from collections import Counter; from os.path import splitext,dirname; c=Counter(); c.update(dirname(x)+" "+splitext(x)[1] for x in Path(".").glob("**/*")); import pprint; pprint.pprint(c)'

which one is easier to read, what do you think?

Your claim that you know Python "pretty well" seems dubious.

Good engineering is about writing a code which is reliable and easy to maintain. In my experience, Ruby's track record is abysmal on both counts.

P.S. Since I'm in the golfing mood, here's an one-liner in a statically typed language, which would be OBVIOUSLY not as elegant as the wonderful Ruby, right?

echo 'package main; import "os"; import "fmt"; import "path/filepath"; func main() { c := make(map[string]int); filepath.Walk(".", func(f string, _ os.FileInfo, _ error) error {c[filepath.Dir(f)+" "+filepath.Ext(f)]+=1; return nil}); for k,v := range c {fmt.Println(k, v)}}' > /tmp/a.go && go run /tmp/a.go
Thread Thread
 
northbear profile image
northbear • Edited

To talk about "easiness to read", you should learn more about functional programming and Ruby, of course. It's difficult for everyone to understand text or code if language it's written by is not known well.

I'm impressed that you reach an insight that not all prog.languages looks the same good in different applications.
So you still need only couple of steps to reach things that I talk about in beginning. And everyday exercises is very good habits. So You are definitely on the right way. Good job!

But your way to discuss here is boring me. I don't see any point to continue talk in this style. Good luck!

Collapse
 
azeemh profile image
azeemh • Edited

No. I will continue to use Ruby and whatever languages best addresses my use case. Fuck off with your stupid titles. Please stop writing shitty articles. Thanks. Fyi rails supports websockets and actioncable. And ops uses vms so just run a bunch of vms on multicore machines if you need concurrency and configure the appropriate port forwarding to apache nginx. Finally Airbnb and Shopify as well as Github are made with ruby and they make $$$. 1 man can do a lot with rails.

Collapse
 
jimsy profile image
James Harton

Thanks all for the feedback. I agree that the title is a bit clickbait, but if I hadn't given this article this name would you have commented?

I agree with most of the points raised here (and on the Ruby NZ slack where I cross-posted it). I'm sorry if it appears that I'm shit talking Ruby and Rails. This is my day job too. We have a joke around these parts that Rails is "New Zealand scale" - ie perfectly good for most workloads in this country and I would tend to agree (although I've worked on a few projects now where that assumption was wrong).

I guess the point I'm trying to make is from a purely technical standpoint Ruby is not up to the job we're doing any more. I want to know what factors continue to support it's (obviously widespread) adoption.

Collapse
 
victorhazbun profile image
Victor Hazbun

Stop posting articles here then, because this site is on Rails.

Collapse
 
caiocaiocaioca1 profile image
caiocaiocaiocaio

1) Rails, out of the box, doesn't have (trend) - The current trend in webdev is to make sites that are so slow, most phones and laptops can't run them comfortably. I like this, because exactly zero of my clients want to arbitrarily exclude 95% of their potential customers because of fashion concerns they have never heard of and don't care about. I enjoy taking business from people who feel my style is "dated".

2) Typing holy war - I understand why dynamic typing and duck typing are less preferable, but in practice, I have never seen any of the major disasters that people predict.

3) Ruby is slow - See point one. My apps run pretty fast, and it's easy to be fast when the competition has 100% deprioritized speed.

4) Concurrency - Ruby doesn't have the best concurrency model, so on a project where that's important, I don't use Ruby. Hardly enough reason to abandon ruby altogether.

Collapse
 
noblebe4st profile image
Jeff Hall

I love Ruby and Rails, but Mr. Harton has an opinion and that's fine. These issue aren't new, but I would point to Eileen Uchitelle's talk on the future of Rails, and as mentioned above progress continues to be made on Ruby itself. So I think it's fair to say that the respective core teams are not resting on their laurels. And as Mr. Cain pointed out, speed isn't everything. There's value in having such a large and vibrant community for instance.

Having said all that, it's perfectly reasonable for someone to eventually outgrow their tools. I can only speak for myself, but I'm not there yet. Ruby and Rails still have a lot to offer me.

Collapse
 
cshupp1 profile image
Cris Shupp • Edited

Have you ever tried JRuby? No GIL, true concurrency, all threads map to Jave threads. The speed delta is dramatic too.

Your app distributes as a war file to any j2ee server as well.

Collapse
 
kyegupov profile image
kyegupov

If you commit to JVM world, then JRuby is a very rare choice, compared to excellent Kotlin, reasonably established Groovy and Scala or good-enough Java 8.

Collapse
 
jimsy profile image
James Harton

Yes, I once attended a JRuby workshop run by Charles Nutter at RubyConfAU. I was very impressed but at the time it was quite difficult to migrate existing apps. Maybe that's not the case any more?

Collapse
 
cshupp1 profile image
Cris Shupp

I have always started with it. I fully expect it to be at least a bit of a pain to migrate any complex app.

Collapse
 
revskill10 profile image
Truong Hoang Dung

Try harder next time. JRuby is one of best options in the wild for you to go enterprise with Ruby.

Collapse
 
kenjin400b profile image
Kenjin400B

Interesting article but you've overlooked as well as many others in general that people like to use languages they like to use. In the heat of production or pressure the language you use can have a big affect on the user and there their work and product.

In context matters as well, sure for some cases rubys speed isn't ideal. But hardware has always made up for any languages deficiencys. The web has proven that cpu cycle counting doesn't really matter. You can see how a languages influences by its community. Plus its influenced by smalltalk which is the basis, of well all modern pc, mouse, user, keyboard computing.

Collapse
 
ondrazizka profile image
Ondrej Zizka

I'd suggest to the author to have a look at kotlin language. For me, Ruby was always far from nice, understandable, easy, usable, etc. Language. In fact, it is so bad that we had to move from Chef to anything else in one large company.
Also, the author seems to be untouched by the Java ecosystem, otherwise he would know that there was Maven artifact repo since around 2004, and that JVM at the time of writing had quite a bit of simplistic been frameworks.

Collapse
 
rafaelsales profile image
Rafael Sales

Yet another clickbait post attempting to become viral, but in the end just tries to make Ruby/Rails problems look bigger than it actually is.

Collapse
 
dustinbrownman profile image
Dustin Brown

Quick 2 cents. I used to think NoMethodError was a big drawback of Ruby/dynamically typed languages. Then I started working in Java and discovered Null Pointer Exceptions...

Collapse
 
watzon profile image
Chris Watson

Stop using Ruby and start using Crystal!

Collapse
 
dansantner profile image
Dan Santner

A lot of your article rang true with me as well. I feel like I had similar experiences. When I first discovered rails and needed to create basic RDB crud pages it was excellent. Once I started to need more than that, I felt like it was the wrong tool. I've moved on, but mainly because I can't stand using RDB.

Collapse
 
bbasile profile image
Basile B.

Crystal addresses at least the speed issue. I'm surprised not to see it mentioned in the article or as a link in the better alternatives.

Collapse
 
jimsy profile image
James Harton

I've never heard of it, so there's that. :)

Googling now.

Collapse
 
paayaw profile image
Derek Owusu-Frimpong

What version of Ruby did you write this on? What version of Rails?

Usually, when I read articles like this I usually think the author's opinion are based on a certain version of the language/framework?

Collapse
 
techpeace profile image
Matt Buck

Here are a few apps built with Rails:

  • GitHub
  • GitLab
  • Airbnb
  • Stripe
  • This very website.
  • Shopify

Here's Shopify's Director of Production Engineering:

It would seem that these businesses have surpassed New Zealand scale.

Collapse
 
maheshkale profile image
Mahesh K

I am on Windows and It's really painful to work with Ruby and Rails. So many bugs on Windows side for ruby. Often those SSL errors for installation and broken gems.

Collapse
 
symbiat_61 profile image
ajai

Without extensive tooling, a Windows machine out-of-the-box is especially painful to develop on,so Im not surprised. Compare this to other platforms where you login, fire up an editor and can start writing Ruby or Python or whatever out of the box without installing anything. I once mentioned this to a .Net developer and he suddenly became very angry. ..

Collapse
 
kyegupov profile image
kyegupov

Python support for Windows have been great for ages.
PHP community made an effort to ship Windows-friendly distributions.

Compared to those, Ruby have always been pure pain.

Collapse
 
hopsoft profile image
Hopsoft

From the DEV CoC:

Examples of unacceptable behavior by participants include: Trolling

🤷‍♂️

Collapse
 
maverick66 profile image
maverick66

I can't wait for Ruby 3. It's gonna solve most of the issues you have outlined.

Collapse
 
ogfris profile image
Fris

"the senior software engineer that I am today" you're very humble... jk

Collapse
 
lewiscowles1986 profile image
Lewis Cowles

Thanks for sharing.

Collapse
 
kendofriendo profile image
Kenney G

Allow me to retort with this essay that I spent all night drafting up trying to find the perfect words:

No.

Collapse
 
smallbasic profile image
small-basic • Edited

this site is built with ruby on rails, so get lost now

Collapse
 
tehmoth profile image
tehmoth

what a pointless article. also what is wrong with CPAN other than 'oh no its Perl'?

Collapse
 
shevegen profile image
markus heiler

Yup, the article is so pointless it is really amazing why the author wants to waste our time. He is evidently a rails guy, so he never used ruby because of ruby. These people only harm a community since they are language hoppers. Hopping to other better languages is great, but a click bait such as "stop using ruby" is utter PR trash. I used ruby before rails, I still use ruby and I fail to see why I should move to another language. What for, anyway? Ruby achieves precisely what I need from a programming language, so why should I stop it? That is just so stupid from the author.

The author writes crap such as:

What this tends to mean in practice is that dynamic typing leads
to subtle bugs because the wrong object is in the wrong place
at the wrong time.

I have been using ruby since almost 20 years and I can happily say that this does not happen. There are no "subtle bugs".

Of course it makes a difference if you design a COMPLEX and COMPLICATED system. Don't do that. Stay simple. Stay elegant. Don't use every random feature because you are just an incompetent person who should not program.

I do not have "subtle bugs". I know what the code does, and the code ensures that what it does works. Input is checked; output is checked. All of this works without (!) having to write a SINGLE test. I don't test my code - and my code still works without a problem. (I actually do test the END functionality, so that when I rewrite a project after, say, 10 years, I do not forget some functionality that once worked. So I do still write tests for the overall COMPONENTS, but not individual shit such as unit tests - that would be totally pointless).

The author is just too clueless to write such articles.

Then he writes crap like this:

Let's get this out there first of all. Ruby is slow.

If you compare ruby to python, perl, php, then ruby is NOT slow. In fact, it has become much faster than before too. Ruby 3 is right now 1.8 times faster than ruby 2.0; and that does not yet include MJIT optimized to its fullest. Either way this is comparable to the other "scripting" languages, so what is this author's problem? The same applies to the others too, so ...

What the actual fudge.

Collapse
 
xuwupeng2000 profile image
Jack Wu

It is just your opinion.

Collapse
 
alonewestand profile image
Kenney Goad

don't tell me what to do

Collapse
 
alex_takitani profile image
Alex Takitani

Performance - there can be only one

The V8 team read that and laughed their asses of.