[HN Gopher] Ruby: We have decided to go forward to 3.0 this year
___________________________________________________________________
Ruby: We have decided to go forward to 3.0 this year
Author : anshul
Score : 237 points
Date : 2020-08-31 13:10 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tiffanyh wrote:
| 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...
| owens99 wrote:
| Look for tenderlove's comments on TruffleRuby. The performance
| is at the expense of memory.
| eregon wrote:
| Which comments?
| loic-sharma wrote:
| https://blog.heroku.com/ruby-3-by-3/
| norswap wrote:
| Fair warning: this is from 4 years ago.
| hinkley wrote:
| In Ruby, as in NodeJS, the GIL pushes you to scale
| horizontally. The memory footprint of Hello World becomes a
| big problem, because the number of copies you run will be
| proportional to the number of cores you have, not the number
| of machines. You get no benefit from moving from an 8 core
| box to 16 or 20 cores.
|
| I suspect if they do manage to pull off more concurrency in
| Ruby 3, that vertically scaling machines will make more
| sense. If 8 cores benefit from a shared footprint, instead of
| one core per process, then the budget looks more attractive.
|
| So now might not be the right time to cherry-pick some of
| these features, but it may not be far off.
| [deleted]
| sickcodebruh wrote:
| I'm excited about performance improvements but thrilled at the
| idea of adding types. Has anyone here worked with Sorbet or a
| prerelease 3.0 in Rails and able to share some notes?
| pqdbr wrote:
| I'm also very excited for Sorbet. Not because of types
| specifically (I don't use them and don't plan to), but because
| I hoped it would give me the same linting experience that
| ESLint gives me on JS files (unused variables, undefined
| methods, calling methods on nil, and so on).
|
| The sorbet demo (https://sorbet.run/) is all I could wish for
| (you can remove the type signatures and see that it would still
| warn you about the `.barr` typo).
|
| However, it is still a great deal of work to set it up on Rails
| (Sorbet is made by Stripe, they use Ruby but not Rails), and I
| couldn't finish the setup because of some gem warnings that I
| couldn't updated at the time.
|
| Hope to give it another try soon!
| bradleybuda wrote:
| Our team has been using Sorbet at getcensus.com for almost a
| year now, and I'm generally very happy with it though it's not
| perfect.
|
| Like most non-trivial Rails apps, our test suite takes a while
| to run, so I like having Sorbet to catch "dumb" issues without
| having to run the full suite. Running `srb tc` to check types
| is incredibly fast and seems to be scaling well as our codebase
| grows. It catches the obvious stuff, but has also found some
| subtle bugs in flow checking and is great for refactoring
| support. The false positive rate is extremely low - if Sorbet
| flags a regression in your type checking, it's very likely to
| be a real bug.
|
| The Slack community is helpful and responsive - if you're
| thinking of using sorbet, I'd strongly suggest joining.
|
| The downsides are:
|
| - Unclear workflows - it's hard to know when you need to
| "rescan" for new type definitions in gems, the stdlib, and in
| generated code in your own app
|
| - Poor Rails integration - the sorbet-rails package is helpful
| and being actively developed, but it's clear that the
| maintainers don't use Rails and aren't going out of their way
| to support it.
|
| - Upgrades are rough - the sorbet tools that scan your gems and
| code to find "hidden definitions" are seemingly unstable from
| release to release. There's a good chance that upgrading to a
| new version of sorbet will break your type checking for
| mysterious and hard-to-debug reasons. Lots of this is probably
| related to Rails as well.
|
| - IDE integration isn't quite ready for prime-time yet. I've
| gotten it working in Emacs with lots of experimentation and
| poking around, and I think some folks have it working in VSCode
| too, but it's not officially "released" or supported and it
| crashes somewhat often. It's still stable enough to be useful
| and I'm glad I have it.
|
| It's great and seems to be getting better, and it has
| absolutely made me more productive, but know that you're still
| adopting an alpha- or beta-quality tool and it's unlikely to
| "just work".
| mfontani wrote:
| 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!
| jodrellblank wrote:
| PowerShell 7 released in March, dropping the "Core" name,
| gaining backwards compatibility and becoming the main version.
|
| https://devblogs.microsoft.com/powershell/announcing-PowerSh...
| MrPowers wrote:
| Spark 3 was released this year:
| https://databricks.com/blog/2020/06/18/introducing-apache-sp...
|
| Almost entirely backwards compatible with huge performance
| gains.
| KeyBoardG wrote:
| and .Net Core becoming the standard .Net 5.0
| open-source-ux wrote:
| The Crystal programming language might also reach 1.0 this year
| too.
|
| _Towards Crystal 1.0_ :
|
| https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html
| jbverschoor wrote:
| great news
| Alex3917 wrote:
| Python3 has really been the norm since 3.4, which was released
| in 2014. After that it took another year until most major
| packages were updated to Python3, but that happened at some
| point in 2015. By 2016 there weren't many packages left that
| weren't Python3 compatible, or that didn't at least have
| Python3 replacements.
| jonnytran wrote:
| This is simply not true. From 2014 to 2017, I worked at a
| place where I kept starting new projects in Python 3. But
| people with less foresight wouldn't let their Python 2 habits
| die. It was a constant struggle to get anyone to realize that
| Python 3 was the future, and the majority of the code ended
| up using Python 2. In 2019 when the end-of-life for Python 2
| was finally announced, I knew of companies scrambling to
| upgrade.
|
| I can't help but contrast this with the upgrade from Ruby 1.8
| to 1.9. It was also painful, but no one in the community was
| holding on to 1.8 years later.
| tonyedgecombe wrote:
| I've often wondered if part of the problem was supporting
| Python 2 for so long and hence prolonging the pain.
| rightbyte wrote:
| Without that I think many would lose trust in Python and
| just switch language.
|
| I mean it has only been 11 years since Python 3.1/2.7 and
| that's probably a common lifespan for maintenance mode
| code projects? 3.5 is still supported and that one is 5
| years old. Why the hurry.
| awill wrote:
| Anyone who works in an enterprise with old code has been
| working on migrating Py2 for ages.
| cortesoft wrote:
| Someone forgot to tell my company...
| chaostheory wrote:
| I beg to differ as someone who's been forced to use python 2
| at work until next year. As for the python ecosystem as
| whole, it feels at the earliest the transition to 3 had to be
| around 2017 - 2018 before most popular libraries got with the
| program. Then again the numbers could prove me completely
| wrong. I just remember personal pain points well. By
| comparison, the Ruby ecosystem was much faster in
| transitioning.
| philwelch wrote:
| > Python3 has really been the norm since 3.4, which was
| released in 2014. After that it took another year until most
| major packages were updated to Python3, but that happened at
| some point in 2015.
|
| So from the perspective of an application developer who uses
| package dependencies, using Python 2 was the norm until 2015
| at the earliest? That sounds about right to me.
| framecowbird wrote:
| most Linux distros still have Python 2 as the default though,
| right?
| ATsch wrote:
| That's just a measure for backwards compatibility, so
| python2-only scripts don't cause cryptic errors when they
| have a `python` shebang. Many distros ship without python2,
| but will probably still link `python -> python2` for the
| near future.
| loeg wrote:
| Not most, no.
| lbhdc wrote:
| Fedora only includes py3 by default in workstation 32.
| marcuskaz wrote:
| No, Ubuntu 18.04 shipped with Python3 as the default.
| dharmab wrote:
| Only server/LTS versions which need Python 2 for backwards
| compatibility.
| walkingolof wrote:
| ....and Scala 3 !
| mixedCase wrote:
| ...and Idris 2!
| zem wrote:
| and (maybe...) ats3!
| shinepl10 wrote:
| You forgot about PHP going to v8
| unfunco wrote:
| The current major version of PHP is 7 so that makes sense, it
| was really the jump from 5 to 7 which was a little anomalous.
| canadev wrote:
| have you a link handy?
| some_furry wrote:
| https://stitcher.io/blog/new-in-php-8
| digianarchist wrote:
| JavaScript really does take over everything.
| e12e wrote:
| Heh. More seriously, I think maybe deno[1] should be on
| that list, as a nodejs 2.0 / event loop for js 2.0?
|
| [1] https://deno.land
| randomdata wrote:
| At that rate, next you're going to tell us that Go is going to
| get generics.
| mrtweetyhack wrote:
| Looking forward to it! Thanks for all the good work.
| sacado2 wrote:
| Are they going to make non-backward-compatible changes, or is
| this just a marketing move?
| jrochkind1 wrote:
| 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.
| pmarreck wrote:
| 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
| jnwatson wrote:
| It works great for Python.
| sosodev wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Sorbet looks really cool, too bad they developed their own
| typing system that keeps types in a totally separate file
| instead of adopting it.
| Lio wrote:
| 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.
| tomc1985 wrote:
| The 'separate' file is to avoid breaking backwards
| compatibility and avoiding a Python2/3 fiasco
| virtue3 wrote:
| Also see coffeescript, etc.
| jamesgeck0 wrote:
| 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.
| cjohnson318 wrote:
| I use type hints in Python to make my code more readable and
| more clearly convey my intent, although I rarely use analysis
| tools.
| anshul wrote:
| 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 wrote:
| The GVL?
|
| https://github.com/ruby/ruby/blob/c5eb24349a4535948514fe765c.
| ..
| ilikepi wrote:
| 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 wrote:
| It sure does blow up your logs if you're using rails with
| 2.7.1.
| sosodev wrote:
| Have you updated? Pretty sure all the warnings have been
| fixed now.
| ljm wrote:
| 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 wrote:
| Yeah, core rails the only warning I've seen is a single
| one in sprockets-rails (brand new app from last week).
| ricardobeat wrote:
| Context? What changes are in v3?
| splitrocket wrote:
| The goal of Ruby v3 is to be 3 times faster than v2.
|
| https://blog.heroku.com/ruby-3-by-3/
|
| Unclear if that goal has been achieved.
| anonova wrote:
| From benchmarks [1], 2.8.0 (with jit) is ~2x faster than
| 2.0.0p648 [2].
|
| [1]: https://pragtob.wordpress.com/2020/08/24/the-great-
| rubykon-b...
|
| [2]: https://pragtob.wordpress.com/2017/01/24/benchmarking-a-
| go-a...
| riffraff wrote:
| notice the "3x3" goal is on a specific benchmark
| (optcarrot), not on all workloads.
| sosodev wrote:
| A lot of focus has been on this benchmark
| https://github.com/mame/optcarrot/ It has seen huge
| performance improvements thanks to the mjit but not quite 3x
| yet.
| geraldbauer wrote:
| Not up-to-date but many more ruby 3x3 articles, see
| https://planetruby.github.io/calendar/ruby3x3
| Pet_Ant wrote:
| Performance is more of an implementation level change rather
| than a language change unless they are restricting the
| language to facilitate new optimisations.
| maxpert wrote:
| Did we get JIT?
| anonova wrote:
| Yes, it was introduced in Ruby 2.6 (2018): https://www.ruby-
| lang.org/en/news/2018/12/25/ruby-2-6-0-rele...
| pizza234 wrote:
| 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.
| jashmatthews wrote:
| The CRuby JIT is stable but whether it improves performance
| or not is workload dependent.
|
| It's simple not primitive. MJIT is designed to take
| advantage of a C compilers optimization.
|
| "Compile to C" worked for Chicken Scheme for the past 20
| years and continues to be a popular way for functional
| langauges to compile. It's also how Nim works. It's all
| about different trade-offs.
| oblio wrote:
| Chicken Scheme compiles ahead of time, doesn't it?
| jashmatthews wrote:
| JRuby has a semi-optimizing JIT since JRuby 9000 was released
| in 2015. It's mostly non-speculative but still the fastest way
| to run Ruby in production. I've used it at several companies.
| ljm wrote:
| I wonder what happened to that old planned feature where the
| ruby code would be byte-compiled into .rbc files?
| byroot wrote:
| The capability is there since 2.3 at least, but Matz doesn't
| want it by default, and prefer to leave it to libraries.
|
| If you use bootsnap, you use ".rbc" files already.
|
| Source: https://bugs.ruby-lang.org/issues/16847#note-14
___________________________________________________________________
(page generated 2020-08-31 23:01 UTC)