Live data from Hacker News

InfraRuby 3.7 – Compiler and runtime for statically-typed Ruby

infraruby.com

21–23 of 23 posts

Re: InfraRuby 3.7 – Compiler and runtime for statically-typed Ruby

#21
post #20
post #18

Earlier quoted context omitted.

If we remove the snark and keep the reality: Those problems do exist on all platforms and the tooling elsewhere is usually not as good.

Never had a GC pause in objc

Apples to oranges.

How about any of the major GC languages?

How about the great debugger tooling Java has. Had that in ObjC? How about performance and threading related tooling? How about refactoring tooling?

Re: InfraRuby 3.7 – Compiler and runtime for statically-typed Ruby

#22
post #10
post #6

Earlier quoted context omitted.

If you can find anyone willing to port Rails to a statically typed subset that requires adding type annotations and also porting every single gem it depends on....

Well that is a starting point. It would be even harder without it so better having it that not. Also do you have any alternatives? Maybe for a start, making a statically typed Sinatra rather than Rails would be a more affordable task. But anyway I'm not sure this is the right direction for Ruby as I think that more radical and different changes are needed to extract the full potential out of it. Anyway if Infrared pr…

> Also do you have any alternatives?

Yes: Not doing it.

> in those situations where Ruby was discarded because of performance

In most cases where Ruby gets discarded because of performance, it's a red herring. Most of Ruby's main uses are in areas where you can generally make things IO bound fairly easily.

For my part, I don't believe Ruby needs static typing to get far more performant. I'm working on a Ruby compiler, and while it's far from usable, from looking at MRI in particular it's worth noting that MRI implements pretty much nothing of the last 30 years or so of dynamic language optimizations.

Look towards JRuby today, and especially the Truffle backend, for indications of where Ruby optimizations can be going without sacrificing what makes the language attractive in the process.

That's not to say there aren't warts that makes it harder than necessary, but you can get very far with far less impact on the language than taking away dynamic typing.

Re: InfraRuby 3.7 – Compiler and runtime for statically-typed Ruby

#23
post #22
post #10

Earlier quoted context omitted.

Well that is a starting point. It would be even harder without it so better having it that not. Also do you have any alternatives? Maybe for a start, making a statically typed Sinatra rather than Rails would be a more affordable task. But anyway I'm not sure this is the right direction for Ruby as I think that more radical and different changes are needed to extract the full potential out of it. Anyway if Infrared pr…

> Also do you have any alternatives? Yes: Not doing it. > in those situations where Ruby was discarded because of performance In most cases where Ruby gets discarded because of performance, it's a red herring. Most of Ruby's main uses are in areas where you can generally make things IO bound fairly easily. For my part, I don't believe Ruby needs static typing to get far more performant. I'm working on a Ruby compiler…

Wow, then you do have an alternative! Hope to hear something more about it soon!
Post reply on HN