> what makes ruby unique and awesome, BLOCKS!

Similar to blocks in Smalltalk and Self, surely?

Still, having worked with ruby a fair bit the past year, it does deliver much of what Smalltalk does (not surprising, as ruby borrows heavily from smalltalk).

https://www.gnu.org/software/smalltalk/manual/html_node/Invo...

Scala and Kotlin let you achieve something similar, without requiring a dedicated `yield` keyword, as well as not introducing yet another type of function into the language... Personally, I always found the number of different types of function in Ruby to be bewildering.

Scala even allows multiple blocks to be passed in, used to good effect in the Cats effect `bracket` function, amongst others.

I'm not so sure about the block thing. I mean I like having first class function-like objects, but you've got blocks and procs and both of these are different from bound and unbound methods. I would prefer that there was a single function type, personally. I wonder if I'm missing something, though. Is there an advantage to distinction between blocks and procs that ruby makes?

A block is a proc.

```ruby

def foo &bar

  return bar

end

foo {}

# => #<Proc:0x00007ff23783c4e0@(irb):16>

```

But I do agree that I don't quite understand the need for the distinction between procs and methods, or the need for unbound methods; I would think that methods could just be either bound to one object or another, as unbound methods are useless for the fact that they won't work at all unless they are bound.

I think they rather meant the difference between procs and lambdas (e.g. wrt return).

I love ruby, but I kind of consider blocks an antifeature compared to, say, JavaScript arrow functions (where you can actually call return and not inanvertsntly break out of the entire enclosing function).

Aren't they like arrow functions in JavaScript?

A lot of this kind of stuff is more about language and standard lib culture than strict language features. Ex - Rust actually has exceptions, technically, in the form of Panics, and you can infact catch them. But the culture of Rust is strongly against using panics in that way. Basically never catch panics and only allow them to happen when you're okay with the whole program blowing up. Use Option and Result and check them if you care about your program not blowing up.

Similarly, Ruby has nice blocks, and many other languages have similar closure support. But Ruby's support is so built-in from day 1 and heavily used in the standard library and the general culture of Ruby gems. Many of the methods in Enumerable take blocks, making it easy to chain a bunch of functional stuff together, even without any support gems and from the earliest days of Ruby.

Just parameters that are functions, except that you can only have one per function. I still fail to see the advantage of blocks over being able to pass functions as arguments like in other languages.

One nice feature of blocks is that `return` will return from the enclosing function, rather than the block, so you can write:

    def find(x, l)
      l.each do |y|
        return y if y == x
      end
    end

Where in Lisp you'd use (return-from find x) and in other languages you might pass in a continuation or use a special return value protocol. It's a nice solution for higher order functions that are supposed to feel more language-level.

Also, you can pass functions as arguments like in other languages; lambdas behave like you would expect them to.

Blocks are essentially just anonymous functions.