1. 21
    1. 12

      Ruby changed my mind about so many things - importance of type safety, importance of aesthetics, OO & controlled mutation.

      Its something I recommend anyone give a serious go. Don’t read a bunch of books, just make a small fun project. Don’t try to make it FP, you will feel when you pulling against the language instead of embracing it. Its the first language I used that doesn’t feel like it has an agenda (in a good way) other than to just be a pleasure to use.

      EDIT: Important aside that I find people making common issue with, ruby is much more than rails. Try a project that is just plain ruby. I personally really fell in love with ruby when I started writing my language in it.

      1. 5

        +1 to that! I love using Ruby outside web development. Creating small scripts and CLIs with Ruby is :chef-kiss:

      2. 3

        Don’t try to make it FP, you will feel when you pulling against the language instead of embracing it

        Hard disagree, what I love about Ruby is that it blends OOP and FP approaches together.

        1. 1

          upvoted… my ruby is very FP and that’s how i likes it

          the ruby style guide that a big portion of linters is based on and more or less considered a standard across most of the industry encourages you to write in a functional style

          when i’m writing ruby i make it my mission to do it, it rarely is a problem unless i come across a method or gem someone wrote that was meant to be non functional

      3. 1

        I came at it from a different angle…

        I had extensively used Perl and a SmallTalk derivative..

        Meeting Ruby felt like coming home to something better than both.

        Although I’ll admit my Ruby code has changed over the years becoming far far more FP like and less perl like.

      4. 1

        Yes, indeed, “just plain Ruby” is both a joy and a pleasure! But with great power comes great responsibility yada yada…

    2. 9

      But in general my feeling is that Ruby always does the most intuitive thing a programmer would expect

      As someone with a strong dislike of Ruby, exactly because of the type of shenanigans described in the article, I would like to correct this to:

      But in general my feeling is that Ruby always does the most intuitive thing that I would expect

      1. 1

        As a Rubyist and also Lisper, I have to agree … I’ve found Common Lisp to be far more intuitive in many cases.

        Picking on numbers again …

        ➜  ~ pry
        [1] pry(main)> 3 / 2
        => 1
        ➜  ~ sbcl
        * (/ 3 2)
    3. 3

      I stumbled upon this ongoing series while looking into the Crystal language (Ary Borenszweig is one of its co-creators). It’s very instructive for me as I have no experience with Ruby. The comparisons with other languages are quite fair.

      1. 1

        I tried using Crystal to write a webserver related project. Kemal’s documentation is piss-poor, and most of my time was spent uselessly subverting the type system because they don’t have generic types, and because it kept expecting nil everywhere, because it kept forcing me to put things into unsafe containers (Example: A thing I created that was in a type safe container, had to get cast to a non-type safe hash simply to get the damn thing to work properly, then later it complains when trying to retrieve those attributes, because the container isn’t type safe! This isn’t a direct fault of the type system, it’s a fault of the workflow and the functions they provide for working with that type system).

        Not to mention, trying to extract attributes in a “type safe” way. You can verify that the thing is not nil, but you still need to explicitly cast after providing that guarantee, because it doesn’t seem to do any control flow modelling. Even then, an exception can still be thrown, which destroys any guarantee created by type safety in the first place.

        Your code can be entirely type safe enough to compile but can still display horrible, wretched behaviour, or outright do the equivalent of segfault, simply because an exception was thrown (Kemal will continue if an exception is thrown, but will malfunction afterwards and not properly process anything, which took a few whole days in production before it was actually noticed by a user).

        It’s the most horrifying, horrific, and disgusting experience I’ve had using a type safe language. I hope it gets better in the future because the promise it makes is wonderful (A C-level language! Completely type safe! That feels like ruby! how wonderful), but it is almost certainly not there yet.

        1. 2

          Thanks for your feedback!

          they don’t have generic types

          Keep in mind that I’ve just started with Crystal, but I think that they do now.

          About the documentation, I haven’t used packages/shards yet but I did notice that the language docs are spotty, especially in the tutorials section (they clearly often assume the reader to be a Ruby programmer, which I can understand actually!). However for the moment I found the specification quite good for learning!

          I’m bookmarking your comment to come back to it later, thanks again.

    4. 2

      Ruby is an incredible language. The fact that it’s so closely tied to Rails is such a double-edged sword. No one would know what Ruby is without Rails, yet Ruby itself is so much more.

      I don’t know why, but Ruby truly is the most joyful language to use for me. I don’t use it at work anymore, because I really prefer static typing at work. But, if I need to use a language as a bicycle of the mind, I always reach for Ruby. It’s as close to pseudocode as is humanly possible I believe, it has a great standard library, and support for trailing closures is so incredibly underrated even though some languages do also have it. Chaining functions also just feels like the best way to write code in my opinion as well:

        .map { |i| i + 1 }
        .select { |i| i > 2 }
        .reduce(0) { |sum, i| sum + i }

      It will always be my favorite language to use for personal stuff and scripts.

      1. 2

        Even better, support for enumerable methods has improved over the versions. You can replace that whole .reduce with a .sum and assuming you swap the .select and .map (which I’m not assuming is the intended case here) you can use .filter_map instead. The brevity of the language while not being totally arcane is really wonderful.

    5. 2

      I love Ruby, but not for the reasons the author provides in this series. For me, it’s mostly because I experience the least friction and frustration with Ruby, compared with other languages. Things operate mostly how I expect. I only have to type a small amount to express and actuate what I have in my mind; very little boilerplate. This also helps readability.

    6. 2

      I’ve used Ruby a lot, it’s been my primary language at work for the last few years, but I’m still not a big fan of it, and this post covers a few of the things I dislike about it actually. For example, floats:

      1 == 1.0 # => true (in math too!)

      Comparing floats and ints as equal is something I’d really rather the language didn’t do, because they do not have the same behaviour! Like so:

      irb(main):001:0> 2 == 2.0
      => true
      irb(main):002:0> (3 / 2) == (3 / 2.0)
      => false

      Ruby does have a lot of nice things about it, but I also think it makes it easy to shoot yourself in the foot.

      1. 2

        I also hate its approach to arrays.

        irb(main):001:0> xs = [1,2,3]
        => [1, 2, 3]
        irb(main):002:0> xs[10]
        => nil
        irb(main):003:0> xs[10] = 4
        => 4
        irb(main):004:0> xs
        => [1, 2, 3, nil, nil, nil, nil, nil, nil, nil, 4]

        Yes, I know they want me to always use iterators. And whether I use them or not, I want these operations to behave sensibly.

        1. 3

          I honestly can’t tell what your complaint is here. You’re trying to say it should error out when you set something beyond the end of the array, or something else?

          1. 1

            Yes, I believe every language must treat indexing errors as, well, errors. Most of them do.

            1. 1

              Hm; I’ve used 10 or 12 different languages and the only one I can think of that uses errors for not-found values is Racket.

              1. 2

                Python is a very mainstream counter-example:

                Python 3.10.2 (main, Jan 17 2022, 00:00:00) [GCC 11.2.1 20211203 (Red Hat 11.2.1-7)] on linux
                Type "help", "copyright", "credits" or "license" for more information.
                >>> xs = []
                >>> xs[10]
                Traceback (most recent call last):
                  File "<stdin>", line 1, in <module>
                IndexError: list index out of range
                >>> xs[10] = 1
                Traceback (most recent call last):
                  File "<stdin>", line 1, in <module>
                IndexError: list assignment index out of range
                1. 1

                  Yeah, I understand they exist; I just think they’re in the minority.

    7. 2

      I stopped using it for scripting simply because I do way more node for work these days, but I always liked Ruby. Whenever I found something about it I hated, the culprit was usually rails ;-)

      Of course, a lot of the worst code I come across in the JS-verse is people trying to write ruby in JS, so it’s definitely a horses for courses sort of thing.