Ruby: We have decided to go forward to 3.0 this year • Hacker News Board

Re: Ruby: We have decided to go forward to 3.0 this year

#21

Post by pizza234 » Mon, Aug 31, 2020, 4:21 PM UTC

anonova wrote: post #10

maxpert wrote: post #7

Did we get JIT?

Yes, it was introduced in Ruby 2.6 (2018): https://www.ruby-lang.org/en/news/2018/12/25/ruby-2-6-0-rele...

Well, yes and no (althought the question is a bit open).

It's more or less beta quality, and very primitive. It's discouraged to be used with Rails, so I'd be inclined to state that "we didn't get it yet".

I'm also personally skeptical that the unusual approach (invoking a whole C compiler in a separate thread) will stand in the long term - but that's my own take.

Re: Ruby: We have decided to go forward to 3.0 this year

#22

Post by ljm » Mon, Aug 31, 2020, 4:28 PM UTC

sosodev wrote: post #14

d3nj4l wrote: post #12

Earlier quoted context omitted.

It sure does blow up your logs if you're using rails with 2.7.1.

Have you updated? Pretty sure all the warnings have been fixed now.

Problem is if you're stuck on gems that aren't maintained any more. Seen a few with PRs containing fixes going stale. Can still switch to a fork, at least.

Re: Ruby: We have decided to go forward to 3.0 this year

#23

Post by jamie_ca » Mon, Aug 31, 2020, 4:29 PM UTC

sosodev wrote: post #14

d3nj4l wrote: post #12

Earlier quoted context omitted.

It sure does blow up your logs if you're using rails with 2.7.1.

Have you updated? Pretty sure all the warnings have been fixed now.

Yeah, core rails the only warning I've seen is a single one in sprockets-rails (brand new app from last week).

Re: Ruby: We have decided to go forward to 3.0 this year

#24

Post by oomkiller » Mon, Aug 31, 2020, 4:30 PM UTC

sosodev wrote: post #18

pmarreck wrote: post #16

Earlier quoted context omitted.

looks like they're adding an optional type system, which means you get the worst of both worlds- no guarantees AND no compile-time type checking (think: what happens if type-checked code calls non-typed code?) so I have no idea how they're going to make that fast since all types will still have to be checked at runtime

Are you sure it’ll be awful? Sorbet ( https://sorbet.org/ ) is pretty popular already. It can statically check your whole project and dynamically check it at runtime. It also doesn’t add that much overhead so I’m not sure what you’re on about...

Sorbet looks really cool, too bad they developed their own typing system that keeps types in a totally separate file instead of adopting it.

Re: Ruby: We have decided to go forward to 3.0 this year

#25

Post by digianarchist » Mon, Aug 31, 2020, 4:31 PM UTC

shinepl10 wrote: post #6

mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

You forgot about PHP going to v8

JavaScript really does take over everything.

Re: Ruby: We have decided to go forward to 3.0 this year

#26

Post by dbalatero » Mon, Aug 31, 2020, 4:31 PM UTC

pmarreck wrote: post #20

sosodev wrote: post #18

Earlier quoted context omitted.

Are you sure it’ll be awful? Sorbet ( https://sorbet.org/ ) is pretty popular already. It can statically check your whole project and dynamically check it at runtime. It also doesn’t add that much overhead so I’m not sure what you’re on about...

What does it do with your library code that isn't type-specified? If it infers types, isn't there a limit as to how far that can go?

Not sure what Ruby core will do, but Sorbet will type everything as T.untyped in the absence of type hints. Libraries can progressively provide rbi files to add first class type support though.

Re: Ruby: We have decided to go forward to 3.0 this year

#27

Post by jodrellblank » Mon, Aug 31, 2020, 4:32 PM UTC

mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

PowerShell 7 released in March, dropping the “Core” name, gaining backwards compatibility and becoming the main version.

https://devblogs.microsoft.com/powershell/announcing-PowerSh...

Re: Ruby: We have decided to go forward to 3.0 this year

#28

Post by tiffanyh » Mon, Aug 31, 2020, 4:33 PM UTC

It appears that Ruby 3 might come short of their 3x speedup goal [1][2] ... has anyone tried out Graal/TruffleRuby?

Graal/TruffleRuby has shown some massive perf increases [3]

[1] https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...

[2] https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b...

[3] https://www.reddit.com/r/ruby/comments/b4c2lx/truffleruby_be...

Re: Ruby: We have decided to go forward to 3.0 this year

#29

Post by canadev » Mon, Aug 31, 2020, 4:42 PM UTC

shinepl10 wrote: post #6

mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

You forgot about PHP going to v8

have you a link handy?

Re: Ruby: We have decided to go forward to 3.0 this year

#30

Post by _lbaq » Mon, Aug 31, 2020, 4:44 PM UTC

mfontani wrote: post #4

What a year! Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!

....and Scala 3 !