Hacker News Reader

Comment by skrebbel | Hacker News Reader

Unrelated side note, but I haven't written any Ruby in maybe 15 years or so and dammn I forgot how elegant the language is at its core. The author's AppVersion class is so nicely done, it's nuts how succinct eg the compare implementation is.

Having done mostly TypeScript and Elixir lately, I had forgotten things could be so succinct yet so clear. The combo of modern (to me) Ruby's lambda syntax (in the .map call), parentheses-less function calls, the fact that arrays implement <=> by comparing each item in order, that there's an overloadable compare operator at all, having multiple value assignments in one go... It all really adds up!

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. Like, this class is super concise but it doesn't trade away any readability at all.

Having learned Ruby before Rails became commonplace, with its love for things that automagically work (until they don't), I had kinda grown to dislike it. But had forgotten how core Ruby is just an excellent programming language, regardless of what I think of the Rails ecosystem.

View on HN

Ruby trades away quite a few things for readability. It's beautiful but a lot is being hidden.

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...

Wow I wonder why it's so verbose. Performance optimizations? Seems like this wouldn't be called often enough to show up in any performance profiling exercise.

Ruby is very slow so you gotta squeeze everything you can everywhere. Even a seemingly simple method will have to be scrutinized so that overall performance isn't impacted. It's death by a thousand cuts.

See the commit that made it complex: https://github.com/ruby/ruby/commit/9b49ba5a68486e42afd83db4...

It claims 20-50% speedups in some cases.

There's churn that comes with that. Ruby will have code that is ever changing to gain 5%, 10% performance every now and then. You gotta put that on balance: in a language like Go this method would've been ugly from the start but no one would've needed to touch it in 100 years.

There are plenty of businesses that have under 10k users and can live perfectly well with http requests around 500-1000 ms. When there are performance issues, 95% of the times they come from the database, not the language.

I somewhat agree. In general most apps are small where the language choice doesn’t really matter.

Caching is also vastly underutilized, most apps are read-heavy and could serve a significant portion of their requests from some form of caching.

> When there are performance issues, 95% of the times they come from the database, not the language.

Eh, statements like these are always too hand wavy. Resource usage has to do with performance, the DB has no fault in it but the runtime does.

Having worked with Rails a ton there’s a very large overhead. Most apps would see a significant speed up if rewritten in a faster language and framework, with no changes to the DB whatsoever. The amount of memory and CPU expended to the app servers is always significant, often outweighing the DB.

But what do you mean, give me a real example. You loaded too many active_records in memory and it's using a ton of ram? Did you try pluck, batches or even skipping active_record and using a raw query?

Unless you really need to scale for a ton of users, you don't have to go crazy to get decent performances out of rails/ruby. How many requests/sec are we even talking about here?

> When there are performance issues, 95% of the times they come from the database, not the language.

DHH used to say that it didn't matter if Rails was slow because the database was I/O bound anyway. But that was a long time ago. Times have changed considerably. Most especially because DHH now promotes using SQLite, which completely takes the worst I/O offender right out of the picture. Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.

Doesn't matter if SQLite is now viable with rails, no legacy rails app is using it and it's not like you're going to wake up one morning and migrate your production db from postgres, mysql, sql server or oracle just because you felt like it.

In theory the language is slow, in practice it doesn't really matter because the db is much slower unless you're github or twitter and you really need to scale.

When you choose ruby, you trade faster dev time for slower runtime. I am OK with this trade-off 99% of the time. My dev time costs way more than a couple ms lost on my production server.

> When you choose ruby, you trade faster dev time for slower runtime.

Ruby is a beautiful language, but that does not translate to efficient use of dev time. Ruby is not a language that you can quickly write usable code in. Some other languages are clearly more productive. You can create works of art, though, which is still pretty appealing. Ruby does have a place in this world.

It was, again, DHH/Rails that used to make the claim about developer time — premised on Rails eliminating all the so-called "situps" that other frameworks imposed on developers. It is very true that when you eliminate a bunch of steps you can move a lot faster. But:

1. Everyone and their bother have created Rails clones in other languages that also eliminate the same "situps", negating any uniqueness Rails once offered on that front.

2. It turns out those "situps", while a dog in early development, actually speed development up down the road. If you are churning out a prototype to demonstrate an idea that will be thrown away after, its a pretty good tradeoff to ignore what you can, but things become far less clear cut when a program finds longevity.

>> When there are performance issues, 95% of the times they come from the database, not the language.

> DHH used to say that it didn't matter if Rails was slow because the database was I/O bound anyway. But that was a long time ago. ... Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.

Nowadays CPU speeds, available RAM, and network speeds dwarf what was top-of-the-line "a long time ago," making the trope of "Ruby is too slow" much less believable "nowadays."

"Too slow" is a mischaracterization. Ruby was never too slow, only comparatively slow. What DHH was talking about is that when the system was I/O bound, even if you could eliminate all the time spent in Ruby, you'd only see small percentage increases in performance at best. But the calculus has changed. I/O isn't the bottleneck like it was when those statements were made. Now, if you could eliminate the time spent in Ruby, you'd see significant percentage increases in performance.

You previously stated:

  Nowadays the language (when it is as slow as Ruby)
  is most likely to be the problem.

And now state:

  "Too slow" is a mischaracterization. Ruby was never
  too slow, only comparatively slow.

In response to my identifying the "Ruby is too slow" trope. Furthermore, when you assert:

  Now, if you could eliminate the time spent in Ruby,
  you'd see significant percentage increases in performance.

This implies a performance issue within Ruby when, in fact, the narrative has now been shifted into execution percentage allocations. For example, if an overall execution flow takes 1 millisecond and time within the Ruby runtime accounts for 600 microseconds, then the above would be true.

One way to describe your position is disingenuous.

> This implies a performance issue within Ruby when, in fact, the narrative has now been shifted into execution percentage allocations.

Yes, that's right. If you have performance problems then Ruby taking up the large majority percentage of the execution allocation means that Ruby is the problem.

But your incorrect assumption is that you will have performance problems in the first place. Neither Ruby nor databases are that slow.

You must have done that stupid HN thing where you pick random strings of words and try to derive meaning from them without taking in the entire context that surround those words into account?

Ruby itself has also gotten far faster, even if you stick with MRI, and even faster if you don't.

> Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.

These days the main issue why web apps are slow or fragile is because they are huge React apps that do way too much in the browser than they need too. The response time from the server is rarely the issue unless you're doing heavy analytics. High end React shops do some crazy optimization to try to compensate for this fact. Linear is the only one I've seen do it well with JS.

You never gotta squeeze everything you can everywhere!

Regardless of how slow the language is, the 90/10 rule applies: 90% of the time is spent in 10% of the code. Optimize that 10%! Making the rest of the code faster isn't worth the code quality cost.

That's a rule that might hold for applications and services. It does not hold for languages and libraries, where any and every aspect is going to be the bottleneck in someone else's code. It's a different 10% for each user.

You can’t build a Ford Pinto and then swap the piston heads and rear differential to get a Formula 1 car.

lol.. yet we have no problems running webviews on chromes on electron on VMs on later.

You can use Crystal which is faster that Go

Challenge accepted:

    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}"

Before dataclasses you could've used namedtuples, at a loss of attribute typing and default initializer:

    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}"

Not knowing python, I find the data classes example extremely readable. More so than Ruby example.

I write mostly Python these days, but agree with op. The comparables implementation in Ruby seems much nicer to me (maybe because I'm less familiar with it).

It's virtually the same in Python if you wrote it explicitly:

    def <=>(other)
        [major, minor, patch] <=> [other.major, other.minor, other.patch]
    end

vs:

    def __lt__(self, other):
        return (self.major, self.minor, self.patch) < (other.major, other.minor, other.patch)

Then use the `total_ordering` decorator to provide the remaining rich comparison methods.

That said, it's a little annoying Python didn't keep __cmp__ around since there's no direct replacement that's just as succinct and what I did above is a slight fib: you still may need to add __eq__() as well.

> Then use the `total_ordering` decorator to provide the remaining rich comparison methods.

While we're here, worth highlighting `cmp_to_key` as well for `sorted` etc. calls.

> it's a little annoying Python didn't keep __cmp__ around since there's no direct replacement that's just as succinct

The rationale offered at the time (https://docs.python.org/3/whatsnew/3.0.html) was admittedly weak, but at least this way there isn't confusion over what happens if you try to use both ways (because one of them just isn't a way any more).

I know, but the ability to use symbols to define the comparator is super, super cool, as opposed to the horrendously ugly lt dunder method.

It's a little magicky. I guess the "Order=True" is what ensures the order of the parameters in the auto-generated constructor matches the order in which the instance variables are defined?

order: If true (the default is False), __lt__(), __le__(), __gt__(), and __ge__() methods will be generated. These compare the class as if it were a tuple of its fields, in order.

eq: If true (the default), an __eq__() method will be generated. This method compares the class as if it were a tuple of its fields, in order. Both instances in the comparison must be of the identical type.

However, I think comparing the Ruby example implementation with the "data classes example" is a category error.

The Ruby example should be compared to the implementation of data classes. The Ruby code shows how cleanly the code for parsing, comparing and printing a version string can be. We would need to see the code underlying the data classes implementation to make a meaningful comparison.

You could also use a normal class, a direct translation of the Ruby example:

    @functools.total_ordering
    class AppVersion:
      def __init__(self, version_string):
        parts = [int(x) for x in str(version_string).split('.')]
        self.major, self.minor, self.patch = parts[0] or 0, parts[1] or 0, parts[2] or 0

      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}'

FWIW, these lines are not equivalent:

    @major, @minor, @patch = parts[0] || 0, parts[1] || 0, parts[2] || 0

    self.major, self.minor, self.patch = parts[0] or 0, parts[1] or 0, parts[2] or 0

The Ruby case is intended to handle strings like "1", "1.2", and "1.2.3".

The Python code will throw an IndexError as written. Which is why I did this in the namedtuple example:

    parts = [int(x) for x in version_string.split(".")] + [0, 0]

That ensures you'll have at least three parts so you can then:

    self.major, self.minor, self.patch = parts[:3]

Nice solution with dataclass! And for a complete comparison with the blog you can also use a library to do it for you. It's not quite in the official python distribution but it's maintained by pypa as a dependency of pip so you probably have it installed already.

    >>> from packaging.version import Version
    >>> Version("1.2.3") > Version("1.2.2")
    True
    >>> Version("2.0") > Version("1.2.2")
    True

packaging.version has a somewhat weird (or at least Python-specific) set of rules that don't match the semantics of Ruby's Gem:Version, which will accept basically anything as input.

I'd use `semver` from PyPI and whatever the equivalent Gem is on the Ruby side in most cases.

Like you, I remember 15 years ago when I decided to solve Project Euler in Ruby, a completely new language to me. I still remember the joy I was feeling when I started coding with this new language. So elegant! So natural! Like it was made to fit my brain. It's a pity I ended up working professionally with entirely different stuff.

Yes, the version in Java is clearly less elegant. Java has map+lambda and compareTo (<=>) but no tuple assignemnt and no splat.

    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);
      }
    }

Also the copyOf isn't really the same as being able to || things since it just happens both copyOf default is 0 and in this case it is also 0 (i.e. what if it was -1 to indicate there was no version).

There’s no accounting for taste but I have never really seen why people consider Ruby so elegant.

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 :).

> 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. Like, this class is super concise but it doesn't trade away any readability at all.

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

Scala also draws on many other sources, but syntactically it clearly takes inspiration from Ruby in a lot of nice ways!

Fair! I was underwhelmed by a Python port in a sibling comment but I can imagine Scala could come close indeed! I mean it’d take a day to compile but it’d look pretty!

I don’t know any ruby but I dabbled in elixir and I gotta ask: why do you prefer parenthesis-less function calls?

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?

Yeah, I don’t really understand the hatred for parentheses. Lisp famously has parentheses everywhere, and it looks a bit noisy at first but the precedence and scope is never ambiguous and with Vim you can always do % to find the match.

I would even say that the parens are a huge benefit of lisp. I guess that’s obvious though cause parens are like half the syntax.

But once you get used to it: - you don’t really notice the parens anymore (definitely not the trailing ones anyway) - you get the advantages of structural editing. So many nice shortcuts for moving stuff around. After working in clojure, typing typescript feels so clunky. How do you focus the next argument? Jump to the enclosing function scope? Yank the body of the closure? You just have to actual navigate to those things and select them, so uncouth!!

> why do you prefer parenthesis-less function calls?

I don’t feel strongly about it, but you gotta admit that this is remarkably easy on the eyes yet also easy to follow:

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

The Elixir equivalent, likely a series of pipes, would be just as easy to follow but substantially more to read, more symbols to parse etc. I don’t feel like this here line of Ruby makes any sacrifices in understandability compared to this Elixir port we’re both imagining.

Good point about grepping though.

> The Elixir equivalent, likely a series of pipes, would be just as easy to follow but substantially more to read, more symbols to parse etc.

Huh?

  [major, minor, patch] =
    version_string
    |> String.split(".")
    |> Enum.map(&String.to_integer/1)

I don't know that I'd call this "substantially more" of anything.

Enum.map(&String.to_integer/1)

.map(&:to_i)

To me the latter is no less clear so yeah, substantially more.

For context I write Elixir once a week and Ruby once a decade. In particular in this case elixir’s (and erlang’s) arity disambiguation (the slash) seems like unhelpful noise. Enum.map only accepts single-arity functions so it seems weird to me that the language couldn't figure that out for me.

> The author's AppVersion class is so nicely done, it's nuts how succinct eg the compare implementation is.

Why thank you! :D

Modern Python is quite close to the ruby version:

    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}"

All languages steal from each other, so on a long enough time scale, it makes sense they kinda converge.

I don't really know Ruby, what is the to_s doing in

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

Is it to_string? Isn't version_string already a string?

Yes, to_s returns the string representation of an object.

I think it's a safety measure in case the argument passed in is not a string, but can be turned into a string. Safe to assume that calling "to_s" on a string just returns the string.

Ruby is a dynamic language, `version_string` can be anything. The author uses `to_s` to coerce it into a string. There are problems with that: if I pass in an array it'll coerce into `"[1,2,3]".split(".").map(&:to_i)`, which makes no sense.

One could do a conversion e. g.

    if x.is_a? Array
      x = x.first

Or something like that. Could be one line too:

    x = x.first if x.is_a? Array

Most times it's better to just accept the dynamic nature of the language rather than do this kind of runtime type checking. You'd have to do this `.is_a?` dance for every type to have it be reliable.

Even if you implement an "interface" (duck typing) with `respond_to?(:to_app_version)` you still can't be sure that the return type of this `:to_app_version` is actually a string you can call `split()` on.

it allows you to initialize an AppVersion with an other AppVersion object

This is the most relevant use of `to_s` in this class indeed. One could imagine additional methods like:

    def bump_minor
      self.class.new(major, minor + 1, patch)
    end

(although I'm not sure why it would be useful in that particular case, it's just an example of how you can build new objects out of existing ones without having to mutate them)

it is a string usually but could be called with a single number or some other object that has that method overwritten and it would still do the right thing.

It's trying to make it more 'type tolerant' so it accepts both string and int and perhaps other types that implement `to_s`.

It's also a quite bad practice to my eye.

it could be anything, but virtually everything implements `#to_s`.

... But maybe not in a way that happens to be a good idea in the current context.

It allocates 2 collections for every compare call and obfuscates the comparison logic. Personally I find that extremely inelegant. Different strokes I suppose.

Obfuscates how?

> But had forgotten how core Ruby is just an excellent programming language, regardless of what I think of the Rails ecosystem.

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.

Is that true. Feels like new Ruby versions and great updates are being churned out relatively fast these days.

I have always found python very succint, is ruby even more?

> modern (to me) Ruby's lambda syntax (in the .map call)

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}'

You don't need any `end`s, but you don't (in 3.x) have the convenience of a direct `<=>` analog (it used to be `__cmp__`). The actual integer conversion function could be done differently, of course, to handle invalid values (I don't know why the Ruby code is doing the `|| 0` business; `to_i` already takes care of that AFAICT).

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.

Reply on news.ycombinator.com