don't take this the wrong way, but -- people still use ruby?
Ruby is not without its drawbacks & drama, but it’s elegant in a way that few languages are to this day (how many JS programmers _actually_ grok prototype-based object-orientation?) & compared to NPM, RubyGems is (lately) unexciting in the best way.
(Yes, I'm taking it a bit far; my prototype Ruby compiler is self-hosting finally, so I guess sometime in the next 20 years I'll end up booting into a Ruby kernel for no good reason...)
But like... something like a font renderer in Ruby? The thing that is incredibly cache sensitive and gets run millions of times per day on a single machine? The by far slowest step of rendering any non-monospaced UI?
The Earth is weeping my brother.
https://github.com/vidarh/skrift
(Note that this is a port of the C-based renderer libschrift; the Ruby version is smaller, but much less so than "usual" when converting C code - libscrift itself is very compact)
Generally speaking Ruby has the best APIs.
ActiveAdmin is best in class, Rails is fantastic; but there’s a lot of insanity in the API for a language that “gets out of the way” and “just works”
Slice is my favorite example. (It’s been a bit since I’ve used it)
[0].slice(0, 100) == [0]
[].slice(0, 100) == … For a “give me an array back that starts from a given, arbitrary index, and auto-handle truncation” not having that behavior continues to confuse me from an intuitive perspective. Yes, I understand the source of it, but why?
So saying “give me the array containing the first 100 elements of this array with one element” would obviously give you the array with one element back.
Saying “give me the array containing the first 100 elements of this array with zero elements” would follow that it just gives the empty array back.
On top of that, because ruby is historically duck-typed, having something always return an array or an error makes sense, why return nil when there’s a logical explanation for defined behavior? Ditto for throwing an error.
Seems thoughtfully intuitive to me.
[].slice(5, 100)
Edit: Longer example:
puts "[1, 2, 3].slice(1, 100) -> #{[1, 2, 3].slice(1, 100).to_s}"
puts "[1, 2, 3].slice(3, 100) -> #{[1, 2, 3].slice(3, 100).to_s}"
puts "[1, 2, 3].slice(4, 100) -> #{[1, 2, 3].slice(4, 100).to_s}"
[1, 2, 3].slice(1, 100) -> [2, 3]
[1, 2, 3].slice(3, 100) -> []
[1, 2, 3].slice(4, 100) ->
That's not a big surprise in a tiny example like this; but if you expand this out into a larger code base, where you're just being an array and you want the 100 through 110th values for whatever reason - say it's a csv. Suddenly you're having to consider both the nil case and the empty array case; but then why are they different?
Some additional things I discovered when trying to figure out why it might work like that:
* the behavior also seems consistent whether using `array.slice(a, b)` or `array[a..b]`
* `array[array.length]` and `array[array.length + 1]` both return nilThe easiest way to get around that if you are not carefully using the ranges would be to do `Array(array.slice(a, b))` as that will guarantee an array even if it's invalid. you could override slice if you really wanted to but that would be a performance penalty if you are doing it often.
``` If offset == self.size and size >= 0, returns a new empty array.
If size is negative, returns nil. ```
either way if you are doing stuff with arrays and not checking bounds you can throw an `Array(some_array.slice(x, x+100))` and it will always behave.
[0, nil, nil, nil, …x100, nil] is the same as [0] in terms of access.
In both cases, trying to access the 100th element (e.g. [0][100]) will give nil.
[].slice(0, 100).each do |x| puts x end
that shouldn't be an error and it seems to be the principle of least surprise imo.
[].slice(5, 100)
( I made the other comment like this longer, please use that one for context )
For web stuff, with server-side rendering and partials it means minimal requirement to touch the hot mess that is JavaScript, and you can build PWAs that feel native pretty easily with Hotwire.
Ruby is slow as fuck though, so there's a tradeoff there.
For anything "slow" I can put it in Sidekiq and just run the worker code with TruffleRuby.
I have high hopes for ZJIT but I think TruffleRuby is the project that proves that Ruby the language doesn't have to be slow and the project is still getting better.
If ZJIT, JRuby or TruffleRuby can get within 5-10% of speed of Go without having to rewrite code I would be very happy. I don't think TruffleRuby is far off that now.
when I touch js, and python... I prefer ONLY AI agentic style of working.