Ruby has the nicest object-oriented design (everything is an object) outside of smalltalk (IMHO).
In contrast to the mess that is Python. For instance, in Ruby it is natural that each or map are methods of Array or Hash rather than global functions which receive an Array or Hash argument.
This goes as far as having the not operator '!' as a method on booleans:
false.! == true
Once you have understood it, it is a very beautiful language.
Stuff like map() is generic iteration, over any structure that exposes iteration. When it's a member function, it means that every collection has to implement map itself basically. When it's separate, the collections only need to provide the interface needed to iterate over it, and the generic map() will just use that.
Taking OOP more seriously, this kind of thing should be implemented through inheritance, interfaces, mixins, etc.
Even though I've got used to it, Python has these inconsistencies that sometimes it wants to be more OOP, sometimes it wants to be more FP.
Ruby has chosen OOP as its size, and implements nicely those functional operations as methods (same for Kotlin, for example). That makes easy for composing them:
# Sum of the square of even elements of a list, in Ruby
my_list.filter{|x| x % 2 == 0}.map{|x| x * 2}.sum
Python could do something like that, but we quickly fall in a parentheses hell:
# The same code, in Python
sum(map(lambda x: x * 2, filter(lambda x: x % 2 == 0, my_list)))
Languages that have chosen the FP path more seriously implement function composition. They could do the same way as Python, but composition makes it more readable:
# The same code, in Haskell
sum . map (^ 2) . filter (\x -> x `mod` 2 == 0) $ my_list
PS: I know that I it would be better to use comprehensions in both Python and Haskell, but these are general examples
Kotlin is still rather different though in that it still implements stuff like map and filter outside of specific collection classes. If you look at the definition of, say, List, there's no map & filter there, only iterator. Instead, map & filter are defined as extension functions that work on any Iterable.
So semantically it's actually closer to Python, with the only difference that, since Python doesn't have extension methods, it has to use global functions for this, while Kotlin lets you pretend that those methods are actually members. But this is pure syntactic sugar, not a semantic difference.
And some will say the exact opposite: contrary to what would seem obvious, code is primarily meant to be read by humans, then written by humans. Because you'll spend way more time unfucking code than actually spitting it.
Yes, but it is not fully OO. Something like `if.class` generates an error, as opposed to returning some type such as "Syncategoreme".
That might looks really anecdotal, but on practice for example that's is probably the biggest obstacle to providing fully localized version of Ruby for example.
The second biggest challenge to do so would probably be the convention of using majuscule to mark a constant, which thus requires a bicameral writing system. That is rather ironic given that none of the three writing system of Japanese is bicameral (looks fair to exclude romaniji here). Though this can be somehow circumvented with tricks like
```
# Define a global method dynamically
Object.send(:define_method, :lowercase_constant) do
"This is a constant-like value"
end
It's very powerful though which is a bit terrifying. You can literally monkey patch Object at runtime and add methods to every single instantiated object! (I believe this is how rspec works..)
Awesome, but with great power come great responsibility ;)
RSpec moved from that quite some time ago. Monkey patching nowadays is usually frowned upon, even refinements, which could simulate monkey patching in a limited scope, are rarely used.
Oh I'm extremely out of date, I was into ruby back when Why's guide was a thing. Maybe I'll revisit it someday if I ever get bored of go paying the rent.
It's the language with the highest ratio of (useful work / LOC), so it's the least verbose language. This makes it very suitable to write and understand complex scripts, because the reduced boilerplate means less cognitive overhead for the programmer. As a result, experienced programmers can be extremely productive with it.
The well-known Rails framework uses this to great effect, however, some people argue that the choice of "convention over configuration" and extensive use of meta-programming, derisively called "magic", make it less suitable for inexperienced teams because they get too much rope to hang themselves and the lack of explicitness starts working against you if you're not careful.
> It's the language with the highest ratio of (useful work / LOC), so it's the least verbose language.
That's not even close to true. Even setting aside APL and its descendants, even setting aside Perl, any of the functional programming languages like Haskell and Scala are less verbose.
(The relative lack of success of those languages should indicate why minimizing verbosity is a poor aim to target.)
Don't just focus on the language syntax, the high ratio of useful work to verbosity is in large part owing to the excellent design of the standard library, which is available without including any headers or downloading third party libraries. This is where it handily beats out any of the alternatives you mention.
I see some people saying that Ruby is too much "magic", while what is magic is Rails. Ruby itself can have its high useful work / LoC ratio thanks to its syntax. For example, you can spawn a thread with:
thread = Thread.new do
# thread code
end
...
thread.join
In this example we can see that it's not magic, only concise.
Fair. I must admit that I'm not aware of the recent features of Java. Last time I really needed it was the time that we needed to instance an anonymous class for callbacks. I still find the block syntax in Ruby cleaner though.
Kotlin is another language that has this Ruby-style blocks for callbacks.
It depends which kind of magic. Everybody love some magic to be in its life, as long as it doesn't reveal to be a curse unintentionally coming out from a good willing wish.
Also you don't want all and everything being the results of spells you don't have a clue how they are cast.
Ruby is something like a "improved" Python, with a better OO system, a code block syntax that makes it easy to use callbacks, more consistent standard libraries, etc. It could be what Python is today.
I wouldn't say niche, but the killer app of Ruby is Rails, a web framework similar to Django. In fact, many people treat them as they are the same. But there are big projects that use Ruby and that are not related to Rails. As far as I remember: Metasploit, Homebrew, Vagrant and Jekyll.
Personally I think Ruby is amazing language for writing shell scripts. I write a blog post about it, you can see it and its discussion here: https://news.ycombinator.com/item?id=40763640
Can you name one way Ruby has parity with Python? Ruby is a dead language that uses sponsored posts here. Nobody actually uses this since like 2018 but some people are paid to hype it up. Just look at the empty praise. No real applications mentioned.
It's not just the well-known GitHub, Shopify, Chime, Figma, Zendesk, Convertkit (Kit), Coinbase etc.
See the "few" companies here, actively hiring Rubyists for no reason https://rubyonremote.com/remote-companies/
Square, Gitlab, Cisco, Figma, Instacart, Block, Calendly, 1password, and so on
huh. I'm not sure if I understood you right, do you script and configure those in ruby, or have you written them in ruby from scratch? Are the sources available to read/learn from?
Beware that one of the joys of writing these for my own use is that I've only added the features I use, and fixed bugs that matter to me, and "clean enough to be readable for me" is very different from best practice for a bigger project.
I'm slowly extracting the things I'm willing to more generally support into gems, though.
The wm was actually discussed on HN way back. I think once some of my other projects, like the terminal, is a bit more mature (it works for me and I use it for 99%+ of my terminal needs) I might post those too.
The biggest issue with these projects is that I feel uncomfortable pushing a few of them because I make a living of providing development and devops work, and my personal "only has to work on my machine and certain bugs are fine to overlook" projects are very different to work projects in how clean they are etc... But as I clean things up so they're closer to meeting my standards for publication I'll post more.
Rails has some very, very good features that make standing up a CRUD app with an administrative backend _very easy_.
It's also got a bunch of semi-functional-programming paradigms throughout that make life quite a bit easier when you get used to using them.
Honestly, if it had types by default and across all / most of its packages easily (no. Sorbet + Rails is pain, or at least was last I tried), I'd probably recommend it over a lot of other languages.
It's not a 100% compatible replacement, but I've ported a few things with only trivial chances. I didn't say it's a drop in, just that it's a fine choice.
Compile/test time is ok. It's a few extra seconds to run tests, but hasn't been an issue in practice for me.
I've tend to have found Kotlin to be the direction I'm more happy going with. It speaks to my particular itches for me personally, more effectively. I can absolutely see how it's a very effective choice.
I love Rails and spent a good chunk of my career using it - and I'd recommend it more if only the frontend story wasn't that bumpy over the years with all the variations of asset pipelines.
I wish the TypeScript/React integration was easier. Say what you will but there's no way you can achieve interactivity and convenience of React (et al) UIs with Turbo/Hotwire in a meaningful time.
I converted from webpacker (or rather shakapacker, the continuation after rails moved away from webpacker) to vite_rails recently, and it's been such a breath of fresh air. It's easy to set up, and easier to maintain. Strongly recommended.
Can you elaborate more in this? Years ago, I used to primarily do Rails development. Recently I built some web apps that use a JVM backend (one app uses Java & Spring and the other Kotlin & Micronaut) and a React frontend. One thing I ended up really missing issue the the frameworks, especially with disjointed fronted, don't solve the standard issue of a request sending an invalid form entry and showing the validation errors on the form. I ended up building my own implementation of that which of course also requires a convention on message format. Since most apps need to solve this it's so weird to be that frameworks nowadays don't solve this out of the box.
I definitely suggest using vite and the vite ruby gem. Create your Rails app, Create your TS + React app with vite, add the vite gem and done. It does not get better than that. Super fantastic.
The language is incredibly flexible and allows for "DSLs" that are just ruby libraries.
A simple example: `3.days.ago` is a very commonly used idiom in Rails projects. Under the hood, it extends the base Number class with `def days` to produce a duration and then extends duration with `def ago` to apply the duration to the current time.
`yyyy-mm-dd(datestr)` will parse a date str that matches yyyy-mm-dd format. It looks like a special DSL, but it's just Ruby. `dd(datestr)` produces a `DatePart`. Then it's just operator overloading on subtraction to capture the rest of the format and return the parsed date.
That library feels unnecessary, but the entire thing is 100 lines of code. The ease of bending the language to fit a use case led to a very rich ecosystem. The challenge is consistency and predictability, especially with a large team.
Not really a niche language. Fantastic web server development. A more flexible and powerful language than python—the metaprogramming can be ridiculously powerful (when done well)—without the nonsense of white space sensitivity. ActiveRecord is perhaps the best ORM out there. Rails has tons of functionality to get running.
Overall, a pleasant and expressive language with an incredible community. Python ends up "winning" because of pytorch + pandas, but is (imo) a worse language to work in + with.
...but ruby is whitespace sensitive too. It's hard to notice, because rules mostly follow intuition, but there're cases when not only a missing newline, but absense or addition of a space changes resulting syntax. Currently I remember only difference in parsing unary vs binary operators, like + and *, and ternary operator ? : vs : in symbols, but there're certainly more other cases.
Sure, like `a ?b :c` is nothing like `a ? b : c` (I guess the former is actually invalid), but that's obviously not what the previous message was referring to when speaking of Python which uses spaces as main facility to determine block scope.
There was a recent thread about parsing Ruby wherein I learned that the % quoting character accepts any character following it as the opening/closing delimiter <https://news.ycombinator.com/item?id=42032212> Crazypants.
Ruby is optimized for developer happiness, and it is not a small thing. Ruby on Rails is optimized to build successful web application businesses as a highly efficient team. It minimizes boilerplate code, and thus, time to market, while giving guidance (the Rails Way) on how to design for growth and scale.
it's by far the best language I've found for writing a quick bit of code to explore a problem, or to do a one-off task. perhaps something about it just fits the way my brain works, but I find it incredibly easy to convert ideas to working ruby without having to think too hard about "okay, how do I actually express this in code".
