Hacker News Reader

Blocks and `yield` are a killer feature; I regularly pick Python over Ruby for similar reasons as you, but I consistently find myself missing those two (and all the things that get built out of them, like the `Iterator` APIs).

Python is a lovely language, but context managers often feel like a shabby substitute for what I can do with `yield` in Ruby :-)

This is basically how I feel about true first-class functions when I have to wrangle ruby and care about blocks, procs, and lambdas.

I love the syntax of Ruby blocks (IMO it's the best syntax for higher-order functions in any language) but I don't understand why they were implemented the way they are, where some things are blocks, some things are procs, and neither one is really a function. I would prefer if Ruby blocks were just functions.

You can convert between blocks and Procs very easily. Ruby has several methods to let you do that, both as syntax and as methods. They are really two sides of the same coin; a block can be thought of as a Proc that is intended for immediate usage (though this is convention, and of course nothing prevents you from converting a block into a Proc and stashing it away for later).

As for functions, Ruby doesn’t really have them—or, rather, blocks and Procs really are the closest you get to a function. Instead, since everything is an object, Ruby has methods instead of functions. Critically, because methods are defined on objects they have inherent object context, which is why you can’t treat a defined method as an anonymous function. Of course, there are ways to extract the method as a Proc and pass it to another object (with or without its object context). But having methods be objects the way they are in, for example, JavaScript would require extra magic under the hood, and lead to all sorts of context gotchas, which is probably why it doesn’t work that way.

In 15+ years of writing Ruby for production I can't think of a single time where the distinction between blocks and procs caused a problem. Blocks are a syntactic element, procs are a data type (that you can construct with a block). I honestly don't even know where the problem is supposed to come from.

It comes up when you get in “ok this block is great, but now I want two of them”. Only one can be a block, the other needs to be a Proc, and now there’s this odd syntactic distinction

Not saying it’s the optimal choice in the languages design spectrum, but it is a little defensible:

If you’re prototyping a new interpreted language and don’t want to have to build a JIT that can optimize code, but still want some semblance of good performance, the block approach Ruby picks can be pretty useful.

Ruby doesn’t haven to allocate a full-on, garbage-collected, closure object every time a function accepts a block: it only has to do this if the block gets stored to a variable. If the block is only ever yield’d to, the allocation can be skipped.

And when your language’s primary looping mechanism is done with blocks, the difference adds up:

    xs.each do |ys|
      # with normal closures and no fancy JIT,
      # the VM has to allocate a closure once per loop:
      ys.each do |y|
      end
    end

Ruby was able to get away with its closure-heavy standard library APIs without a JIT for almost 3 decades because of the affordances that blocks provide over procs/lambdas.

Blocks are Proc objects whenever you take their value, and it's only an implementation dependent optimization that they are not that all the time in MRI. It's perfectly viable to implement a Ruby where blocks are always Proc's. You don't need to care about that distinction.

Ruby doesn't have functions at all - it has objects with methods, and you can treat a block as an object whenever you want.

Is Ruby's "yield" different than Python's "yield"? I use Python generators all the time, and I think they're the bee's knees.

It’s kinda different although you can do some similar things.

IMO the ruby one is more powerful because it effectively allows you to customize language syntax by supplying a block. And it fits nicely with the stdlib and libraries (ex map yields to a block to do the mapping). Ruby also has an enumerator that does some similar things to pythons yield: https://docs.ruby-lang.org/en/master/Enumerator.html

Pythons yield is more commonly used for iteration and stuff although it does allow some neat tricks for scoping things.

Completely different. Ruby‘s yield calls a block, which is basically an anonymous method with some special syntax tacked on.

I also worked at Stripe, and loved Sorbet-ified (typed) Ruby, but any time I'd recommend it to a friend it would fail to work in their project out of the box. I think it works really well on Stripe's codebase, and might work on another one if you have what it takes to wrestle with it. And aren't ahead of Stripe on Ruby versions…

Sorbet works well on Shopify's codebase. We are basically always on the new version of Ruby and Rails both. Sorbet wasn't a huge effort to get working on the code I work on, but its been mostly easy keeping going.

question, first glance sorbet looks like an awkward version of typing syntax wise that makes ruby look like other languages. At that point what still stands out about ruby that makes it still great with a lot of type overhead? I did ruby / rails for years and enjoyed int. Just wondering.

I am not a fan of sorbet. I just know its been relatively painless. I haven't really had any extra confidence refactoring from Sorbet, nor have I noticed much beyond it being another step in making code. Mostly I think its kind of an ugly solution, and I would like something else for optional typing.

My friend's experiences ranged from "too many papercuts to deal with, gave up" to "broken entirely on Ruby 3", but good to hear it works for you. For the Shopify case, do you not have a Ruby infra team that manages the install?

Yeah there are teams for ruby and rails infra, so my pretty smooth experience might just be that team doing the work to hide the issues from the rest of the developers.

You can do this in C#, F#, Rust and many other languages too with 10x better performance (in Rust in particular those usually get completely optimized away).

I agree that pipeline functional stream processing are in many case simpler and clear than weird nested loops with early exit conditions. However, besides maybe the needs for lambda expressions, this is mainly a function of good API design as opposed to something code to the language. In particular here i don't think the niceness of this approach is related to anything core to ruby. C# with link, F# with computational expression (and haskel monadic structures) and as you mentioned java stream do the same thing and even a bit better in my opinion

Ruby's blocks as a way to express a HOF is pretty accessible, and I like that I can switch from "arr.map{|o| ... }" to "arr do |o| ... multiple lines ... end" seamlessly, to be terse when I want to be but then be verbose when I need to be. But that's not exclusive to Ruby, Java's lambda syntax behaves similarly.

More generally, and more to your point, I think extensive use of blocks/HOFs lends to the "spirit" of Ruby being a lot more functional-style than python, which iirc got lambda support late and they're kind of ugly (I mean, you literally type lambda! almost as bad as go!).

Honestly, I think both Python and Ruby have a subpar gradual typing story.

The problem is that Python type hints are not enforced at runtime. They can can not be trusted. You have to rely on external type checkers that are relatively slow and different checker might give you different results.

Probably the only mainstream backend-language getting gradual typing right is PHP. Yes, good old PHP. Dead simple type system, no productivity-sucking compile step like in Typescript, actual runtime enforcement of types contrary to Python and great static linting.

Though PHP is also a fair bit less expressive and dynamic compared to both Python and Ruby so it can get away with an much simpler type system. Then again, as someone who has to work with many legacy systems, sometimes I am very grateful for the lower expressiveness.

Y'know it's weird but it's never bothered me too much that python type hints don't do anything at runtime. It's enough to just know what someone, at some point, intended. (And PyCharm is pretty good about pointing out when they're wrong, anyway). I guess when it comes down to it, given we're not statically typing, I still get an awful lot of mileage out of just knowing when my assumptions about the code conflict with someone else's assumptions about the code (even if that other person is subtly wrong, like anystr vs str or something).

Sorbet has a runtime time-checking mode I think, too, so that's actually a point in favor to ruby for you (though again with the drawbacks I mentioned of being a gem and imo being a little clunky syntax-wise).

> Ruby have a subpar gradual typing story

Whether you agree with it or not Ruby's (the language not the developers) resistance to static typing is just how Ruby wants to be written. There are no types, only messages. The whole culture surrounding Ruby is burying all the underlying data in favor of pure message-passing nirvana. I have no ducks but I must quack.

This is partially true, but a pretty large chunk of idiomatic Ruby is focused on Enumerable method chaining, transforming arrays and hashes, slicing and dicing strings, etc. A language that was totally dedicated to message-passing nirvana wouldn't have regexes as a built-in data type with a literal syntax (or dictionaries, ranges, and so on)

Those things are all just Objects in Ruby, just with some syntactic sugar, not built in data types. `/a?/` is just syntactic sugar for `Regexp.new('a?')`, ['a','b','c'] is just `Array.[]( 'a', 'b', 'c')` everything is an object being sent messages.

> There are no types, only messages.

Yes but...what is the shape of those messages? I ways prefer to know the type of the material I'm working with...

Enforcing the type hints at runtime gets really expensive if you allow for complex/higher order types. Typed Racket has had trouble with this since it tries to actually be a sound gradual typing system. Interesting work here: https://dl.acm.org/doi/pdf/10.1145/3434334 on speeding it up via static analysis (figuring out what dynamic enforcement points you can statically eliminate).

I also love Ruby. I've been using it for over 20 years now, although always in a 'supporting' role--like at most maybe 5-10% of the code I write, and I definitely don't read or write it every day.

I've also never written anything particularly large in it. Like around a few thousand LOC, tops, for any one tool. And at that point, I often find myself writing a lot of things like assert { foo.is_a?(Foo) } to check parameter types, because beyond a certain size I just can't keep all the details in my head, and I don't want to rely only on comments.

Guess I'm saying that even though I really love it for small things, I'm also skeptical of its ability to scale.

The special-casing of Blocks irks me, including the fact that you can only have 1 of them in a single method call. I understand the justification, but it’s syntactically inconsistent and doesn’t sit right with me.

I really like the way Swift introduced closures as regular parameters, but lets you have the Ruby-like “trailing closure syntax” for the last one in the list. It’s very best-of-both worldsy: if you need just one closure, it can be trailing, and if you need multiple, they can both look the same.