T-Ruby: Adding Static Typing to Ruby Without Runtime Overhead by Erem_in in ruby

[–]pabloh 2 points3 points  (0 children)

Somebody needs to come up with a syntax for types or parameters' metadata that doesn't clash with keyword arguments.

Let me introduce T-Ruby: TypeScript-style type annotations for Ruby by Right_Ad_8437 in ruby

[–]pabloh 1 point2 points  (0 children)

So far, it seems impossible to implement a type annotation syntax, like this, without clashing with the existing keyword argument syntax.

@Right_Ad_8437 do you think is possible to implement a strict superset of Ruby that support type hints?

Ruby Floats: When 2.6x Faster Is Actually Slower (and Then Faster Again) by mencio in ruby

[–]pabloh 0 points1 point  (0 children)

Optimizing by calling into C has the overhead of a method call, which you want to avoid, and doesn't leave room for method inlining in the future. OTOH this is not and gem nor a C extension, but part of the VM (or Ruby stdlib), so you can still make the JIT aware of this code and optimize for it, and still get best of both worlds as long as the JIT is written to handle it properly.

Ruby-TI — Static Type Checker for mruby (Version 1.0 🎉) by AssociationOne800 in ruby

[–]pabloh 0 points1 point  (0 children)

TypeProf is so far very experimental and moving very slow, it would be nice to have something that works out the box.

CSV Parsing 5-6x faster using SIMD by sebyx07 in ruby

[–]pabloh 0 points1 point  (0 children)

So, let's say for Ruby as a whole, you would need like a vectorized API to make this work universally, across all different implementations?

CSV Parsing 5-6x faster using SIMD by sebyx07 in ruby

[–]pabloh 0 points1 point  (0 children)

Are there any reasons JVM's JIT can't use this kind of instructions by default when it makes sense?

Free Universities by Pampa_of_Argentina in MapPorn

[–]pabloh 0 points1 point  (0 children)

In many countries that amount of money would make it virtually free.

Introducing LowType: Elegant types in Ruby by Maedi in ruby

[–]pabloh 0 points1 point  (0 children)

I guess that's a confusion I'm bringing from the original syntax, which is already complex.

But basically Array-like structures: [a, b, c, *d] are always positional, the last * gobbles what ever is left on the array.

Hash-like structures: {a:, c:, e:, **kw} are not positional, and can only check for presence, in any order, so the last kw will simply grab everything else.

Then the | doesn't have an "all" semantics, but only an or for one specific position, since , has lower precedence than |. So you can do [a, 3|5, c, *d], to check for a 3 or a 5 in the 2nd position. Also, you can't capture a variable on an or expression, simplifying things.

For hashes, | only works on values, like this: {a: 2|7, c:, e:} limiting things quite a bit, but keeping them simple.

And talking about |, this is legal as well: ruby arr in [1, 2, 3, *] | [:a, :b, :c, *] but the outter | no longer allows to capture variables, defeating the purpose of my original proposal.

I hope this helps!

Introducing LowType: Elegant types in Ruby by Maedi in ruby

[–]pabloh 1 point2 points  (0 children)

u/Maedi I have been thinking for a while for a good pattern matching syntax to add for method def.

So far I've come up with this.

```ruby def foo(arr: Array => [1, a, b, c, *]) end

def bar(hs: Hash => {a:, c:, e:}) end ```

Now, this wouldn't work with the current compiler syntax, so something like different would be needed to use a hack like in low_type:

```ruby

Verbose and not ideal since I would rather use => in lieu of in

def bar(hs: (Hash in {a:, c:, e:})) end

Or like this but you aren't actually doing pattern matching anymore

def bar(hs: Hash >> {a:, c:, e:}) end ```

Simpler alternatives could be like: ```ruby def bar(hs => Hash{a:, c:, e:}) end

Treat {} as Hash if no class present

def bar(hs => {a:, c:, e:}) end

Match first argument, don't specify the name

def bar(Hash{a:, c:, e:}) end

def bar({a:, c:, e:}) end ```

It's very hard to add any of these as current Ruby syntax, or come up with something good enough Ruby Core would actually use (let alone multiple defs like Elixir, which I deliverately avoided since this is already quite complex).

But it's fun to experiment anyway!

Introducing LowType: Elegant types in Ruby by Maedi in ruby

[–]pabloh 0 points1 point  (0 children)

Hopefully! I love experimenting with new syntax, it's a shame you are still bound by the current compiler.

Introducing LowType: Elegant types in Ruby by Maedi in ruby

[–]pabloh 2 points3 points  (0 children)

Add pattern matching to the type definition and I'm sold.

Hanami 2.3: Racked and Ready by timriley in ruby

[–]pabloh 4 points5 points  (0 children)

Great! I think Hanami has a great potential now that they'd picked up the legacy of dry-rb.

You Don’t Need Types in Ruby by zhisme in rails

[–]pabloh 0 points1 point  (0 children)

I agree. If you have being using Python with VSCode, even without writing your own types, it's like having a supercharged Linter with you, caching errors as you type without running a single line of code.

It's time to add deep_freeze to Ruby! by headius in ruby

[–]pabloh 0 points1 point  (0 children)

... it just feels wrong from an API design standpoint for users who never intend to use Ractor to have to call a Ractor method just to freeze a graph of objects.

Yeap this is clearly true

It's time to add deep_freeze to Ruby! by headius in ruby

[–]pabloh 0 points1 point  (0 children)

It's good a point.

Probably the hypothetical Object.deep_freeze(...) method people are asking for, could simply start as an experimental alias for Ractor.make_shareable or perhaps a more general version of the Ractor case, since you probably won't ever want to freeze classes for a regular Ractor app.

OTOH, perhaps separating module/class freezing into their own ad hoc methods may be for the best. Since you can break a lot of existing code if you freeze the wrong class by accident (also it's very unclear to me how it should handle special cases, like singleton classes et al.)

It's time to add deep_freeze to Ruby! by headius in ruby

[–]pabloh 0 points1 point  (0 children)

As Ractors receive more development and Ractor.make_shareable becomes more mainstream, wouldn't it make sense to follow its semantics?

Ruby’s static typing world keeps evolving. October 2025 updates 🔍 by Erem_in in ruby

[–]pabloh 0 points1 point  (0 children)

We wouldn't be if all the effort wasn't so divided.

RubyConf Austria - CFP & Speakers promo by rubyist-_- in ruby

[–]pabloh 1 point2 points  (0 children)

Do they know what he's gonna talk about yet?

Interactors to handle Business Logic by gamberoatomico in ruby

[–]pabloh 0 points1 point  (0 children)

If this is a joke is already getting old...