[sacado2]

Are they going to make non-backward-compatible changes, or is this just a marketing move?

[anshul]

Ruby 3 is expected to introduce new concurrency primitives that evade the global interpreter lock (guilds / isolates) and type definitions for the stdlib for optional typing support. This should be a big release for ruby!

[aantix]

The GVL?

https://github.com/ruby/ruby/blob/c5eb24349a4535948514fe765c...

[jrochkind1]

There are some non-backwards-compat changes regarding keyword arguments.

They aren't that exciting, but they are necessary to eliminate some ambiguous and inconsistent cases, and will be a pain for some codebases. (2.7 already marks as deprecated behavior that will break in 3).

https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...

I'm not sure if ruby actually commits to semver-style no-backwards-incompat-unless-major; they didn't used to. Either way though, recent ruby minor version releases have seen few if any (?) backwards incompat changes of any note -- nothing of note I can think of since 1.9 in 2007 (which did have major changes. Ironically 2.0 didn't have so much). The keyword arg changes will definitely effect more codebases more significantly than any we've seen in a while.

[ilikepi]

It might be a little of both. I did come across this change to keyword arguments[1] recently, but I'm not sure how impactful it is since I don't personally leverage keyword arguments right now.

[1]: https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...

[d3nj4l]

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

[sosodev]

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

[ljm]

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.

[jamie_ca]

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

[d3nj4l]

Can't update at work, there's a few breaking changes :/

[pmarreck]

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

[sosodev]

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...

[pmarreck]

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?

[dbalatero]

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.

[oomkiller]

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

[jamesgeck0]

Sorbet was developed before the details of the new Ruby type system were locked in. They’re working on providing some convergence in upcoming releases.

[tomc1985]

The 'separate' file is to avoid breaking backwards compatibility and avoiding a Python2/3 fiasco

[virtue3]

Also see coffeescript, etc.

[Lio]

Sorbet will be compatible with the new file format. We’ll still be able to use the inline Sorbet type signatures.

My personal hope is that typing can be included in test/spec files.

[cjohnson318]

I use type hints in Python to make my code more readable and more clearly convey my intent, although I rarely use analysis tools.

[jnwatson]

It works great for Python.