Ruby already solved my problem (newsletter.masilotti.com)

Ruby, and Ruby on Rails is a treasure trove of little handy bits you can use if you just know where to look. I really miss some aspects of ruby (I just don't have a chance to use it these days).

Metaprogramming is Lisp's canonical super power. Ruby is going to win out on tasks where it has built in syntax, like matching regular expressions.

But once you get to metaprogramming Lisp macros are going to give Ruby a run for its money.

I will say one of the under appreciated aspects of Ruby is the consistency of its semantics, where everything is message passing very much like Smalltalk.

rubygems.org also has decided to, rather than fix on existing problems, eliminate all former maintainers and instead put in Hiroshi Shibata as the solo lead - the same guy who keeps on writing on different github issue trackers how he does not have time to handle any issue requests for low-used projects. Wowsers.

Other than that, how was the play, Mrs. Lincoln?

Also, add readability and maintainability to that list, and scaling to a large codebase. And good debugger support.

Pieter Levels writes his startups in PHP and hasn't had a performance bottleneck so far. For most applications, the performance of the language won't be an issue. I personally wouldn't pick PHP for any of my own projects, but Ruby I'd pick any day.

man, people are still parroting decade old, incorrect talking points I see.

Is ruby as performant as C, probably not, although, actually, in some cases, it outperforms C -> https://railsatscale.com/2023-08-29-ruby-outperforms-c/

One of the largest ecommerce apps in the world runs ruby, shopify. Ruby now has a JIT, there has been insane effort put into making ruby faster.

* default libraries (these are maintained by the Ruby core team, delivered with Ruby, and upgraded only as part of Ruby version upgrades.)

* default gems (these are maintained by the Ruby core team, delivered with Ruby, not removable, can be required directly just like default libraries, but can be updated separately from Ruby version upgrades.)

* bundled gems (these are gems that are delivered and installed with Ruby, but which can be upgraded separately or removed.)

Rubygems is a default gem. [0] It used to not be part of the standard library, but it has been since Ruby 1.9, released in 2007.

[0] see, https://stdgems.org/

it's so typical of ruby culture "haha, what if I do this silly thing" and then that gets shipped to production

    from dataclasses import dataclass
    
    @dataclass(frozen=True, order=True)
    class AppVersion:
        major: int = 0
        minor: int = 0
        patch: int = 0
    
        @classmethod
        def from_string(cls, version_string: str):
            return cls(*[int(x) for x in version_string.split(".")])
    
        def __str__(self):
            return f"{self.major}.{self.minor}.{self.patch}"

    from collections import namedtuple
    
    class AppVersion(namedtuple("AppVersion", "major minor patch")):

        @classmethod
        def from_string(cls, version_string: str):
            parts = [int(x) for x in version_string.split(".")] + [0, 0]
            return cls(*parts[:3])
    
        def __str__(self):
            return f"{self.major}.{self.minor}.{self.patch}"

Some of those languages would have you deal with the problem of allocating multiple arrays in the heap just to compare three numbers. Or give you tools to outlaw passing invalid strings to AppVersion.new (quick: what is the comparison between AppVersions "foo" and "bar"?).

Plus you have very few tools to ensure code remains beautiful. I've worked with Ruby for close to two decades, almost nothing in the real world looks that clean. Take a look at the Gem::Version#<=> implementation that the article talks about: https://github.com/ruby/ruby/blob/master/lib/rubygems/versio...

       parts = version_string.to_s.split(”.”).map(&:to_i)

A problem is that ruby lost many developres; rails too but it is by far the biggest driver in ruby. And this creates problems, because it overshadows the remaining ruby developers.

Why thank you! :D

    record AppVersion(int major, int minor, int patch) implements Comparable<AppVersion> {
      public static AppVersion of(String version) {
        var array = Arrays.copyOf(Arrays.stream(version.split("\\.")).mapToInt(Integer::parseInt).toArray(), 3);
        return new AppVersion(array[0], array[1], array[2]);
      }

      public int compareTo(AppVersion other) {
        return Comparator.comparingInt(AppVersion::major)
            .thenComparingInt(AppVersion::minor)
            .thenComparingInt(AppVersion::patch)
            .compare(this, other);
      }

      public String toString() {
        return "%d.%d.%d".formatted(major, minor, patch);
      }
    }

It's syntactic sugar for what Ruby does with a lambda, but fundamentally the purpose is to extract a method from the input. Python has that in the standard library, as `operator.attrgetter`. But also in Python, you generally convert by passing to the type constructor rather than calling a method; so you can just use that directly.

> parentheses-less function calls

Only methods are called here, not plain functions. You can get this effect in many other languages by defining properties instead of zero-argument methods.

> the fact that arrays implement <=> by comparing each item in order

This is also done in Python, and probably many other languages.

> that there's an overloadable compare operator at all, having multiple value assignments in one go

Idem.

> In any other language I can think of real quick (TS, Elixir, C#, Python, PHP, Go) a fair number of these parts would be substantially more wordy or syntaxy at little immediately obvious benefit.

A relatively direct translation looks like:

  import functools 

  @functools.total_ordering
  class AppVersion:
    def __init__(self, version_string):
      self.major, self.minor, self.patch, *_ = map(int, str(version_string).split('.'))
    def __lt__(self, other):
      return (self.major, self.minor, self.patch) < (other.major, other.minor, other.patch)
    def __eq__(self, other):
      return (self.major, self.minor, self.patch) == (other.major, other.minor, other.patch)
    def __str__(self):
      return f'{self.major}.{self.minor}.{self.patch}'

Although the rough ecosystem equivalent of Gem::Version (https://github.com/pypa/packaging/blob/main/src/packaging/ve...) does much more sophisticated parsing. And you could also get the comparison logic by leveraging `collections.namedtuple`, `typing.NamedTuple` (but changing the initialization logic isn't so neat for these immutable types), `dataclasses.dataclass` etc. as in js2's reply.

Scala would like to have a terse say about this... :-)

I like when parens/brackets are reliable wrappers for chunks of code. Like being able to ‘vi{‘ in vim to select a function body. Or ‘%’ to jump to the matching paren.

Do you find the language more readable without it? Less visual noise?

Admittedly, I have never done a lot with Ruby, but I have done some Rails and I tried for a few months to use it for simple “shell” scripts, and the language never felt beautiful or elegant to me.

Admittedly, I come from a strong functional programming background, so it is entirely possible that my brain sees “it’s not really a ‘functional’ and therefore I don’t like it”, but I do like Rust (even when I write it very imperatively) and I even kind of like modern Java.

Dunno, I will admit that I am weird, my favorite language is Clojure and I know that that one is an acquired taste :).

    from dataclasses import dataclass

    @dataclass(order=True)
    class AppVersion:
        major: int = 0
        minor: int = 0
        patch: int = 0
        
        @classmethod
        def from_string(cls, version_string):
            parts = map(int, str(version_string).split('.'))
            return cls(*parts)
        
        def __str__(self):
            return f"{self.major}.{self.minor}.{self.patch}"