6 ms·
News for Ruby 3.2.0
- meisel 4y agoHow do MJIT and YJIT differ?
- jez 4y agoMJIT pastes together snippets of C code that implement Ruby VM bytecode instructions. It then hands off that C code to GCC which compiles it to native code while the Ruby VM is running. YJIT compiles from Ruby VM bytecode straight to native code using a JIT technique called basic block versioning (which is slightly different from how JITs like V8 work because the unit of reuse is a basic block instead of a function). There’s more information in these links: https://youtube.com/watch?v=zO9_uTaELCw&feature=shares https://youtube.com/watch?v=zO9_uTaELCw&feature=shares https://shopify.engineering/yjit-just-in-time-compiler-cruby https://shopify.engineering/yjit-just-in-time-compiler-cruby
- petersafwat 4y ago[flagged]
- mdhb 4y agoQuick question for the current Ruby community: I kind of moved away from Ruby right around the time Ractors were about to land and they looked really promising. I was just curious if they ended up delivering much in the way of change and if not what the main problems were?
- Alifatisk 4y agoRactors is still in experimental stage but I’ve played around with it and it sure offers a huge performance benefit & true concurrency
- mdhb 4y agoI assume by the fact they are still experimental that there isn’t much in the way of adoption yet?
- drchiu 4y agoI was looking into this question a few weeks ago and couldn't find any libraries I would use in typical applications (eg. background jobs, etc) implementing Ractors. There are occasional comments in GH issues discussing the possibility of implementing Ractors, but nothing material.
- Lammy 4y agoHere's one that sounds like exactly the sort of example you had in mind: https://github.com/okeeblow/DistorteD/tree/NEW%E2%80%85SENSATION/CHECKING%20YOU%20OUT https://github.com/okeeblow/DistorteD/tree/NEW%E2%80%85SENSA... Disclaimer: mine :)
- Alifatisk 4y agoNot from what I have seen, It’s kinda risky because the fact that Ractors still is in experimental stage means that there couls be major breaking changes at any time, both how you use it and internally.
- chucke 4y agoractors, due to its "no shared or immutable only memory" constraints, is fundamentally incompatible with 99% of ruby code in the wild. I don't see it getting much adoption until some of those constraints are relaxed.
- LAC-Tech 4y agoIf that constraint is relaxed, then they aren't really actors anymore, are they?
- chucke 4y agoThey would. Some of the constraints were senseless. You used to not be able to use class variables, even if they were already initialized and frozen. However, using static variables, and worse, changing them, was fine. Ruby uses a lot of pure lazy memorization. That's an aspect I'd like to see more accepted. A system that enforces rather than recommends, is a less usable system.
- t-writescode 4y agoThis can be said of most actor systems. Using actors is a fundamentally different way of programming than non-actor-based multi-threaded systems. You do have to change your paradigm; but, when I have, I've found the experience to be really wonderful.
- RussianCow 4y ago> This can be said of most actor systems. True, but other languages/platforms have better built-in support for immutable data structures and don't force you to fight the standard library to implement a share-nothing approach.
- t-writescode 4y agoYou get there pretty fast in Ruby with DryStruct; and, Ruby has .freeze, which can also be helpful.
- faebi 4y agoWhile on the topic, I still don‘t get it why we have [].last but {}.last fails with a NoMethodError.
- saghm 4y agoAre hashes guaranteed to be ordered in some way (not just incidentally implemented that way, but specified so that changing it in the future would be considered breaking)? I thought they weren't, in which case there wouldn't really be any obvious way to define `last`, but I might be mistaken
- danielheath 4y agoRuby hashes are ordered, per the docs.
- sodapopcan 4y ago`{}.first` works, so no reason why `{}.last` shouldn't. I would argue, though, that it's best not to rely on hashes for ordering, though that's a relatively loose preference, and I've certainly use it for quick 'n' dirty scriptss
- latortuga 4y agoRuby hashes have been intentionally ordered since Ruby 1.9, which is ~15 years now.
- sodapopcan 4y agoYep, as I described in another comment I just don't like to exploit that, but it's more of a personal preference. It's cool by me if others choose to.
- BurningFrog 4y agoI agree that it's conceptually weird, but since Ruby guarantees the ordering, you might as well have features for it.
- matsadler 4y agoAdd support for bundle gem --ext=rust command. Cool to see support for writing extension gems in Rust shipping with Ruby.
- nine_k 4y agoTo complement, the evolution from 2.0 to 3.1: https://rubyreferences.github.io/rubychanges/evolution.html https://rubyreferences.github.io/rubychanges/evolution.html
- schneems 4y agoI’m excited to see my syntax suggest gem as a default gem
- akanet 4y agoReally pleased to see Enumerable.product make it!
- chairmanwow1 4y agoI have been playing around with django for the first time in almost 5 years recently, and it’s so much more productive. Wondering if I should try out rails.
- faraaz98 4y agoCompared to Rails, django will feel like fastapi Imo
- tommica 4y agoWhat does that mean?
- devoutsalsa 4y agoDjango is more comprehensive than FastAPI in terms of features and use cases it tries to address, so I assume they mean Rails offers more than Django. More != better.
- danmaz74 4y agoFrom a very long time rubyist: if you care a lot about code elegance, I think you could like ruby/rails more. If for you it's more important that there is only one correct way to do things, then probably sticking with python /Django makes sense.
- chairmanwow1 4y agoHonestly code elegance is less important than raw productivity.
- danmaz74 4y agoMy point is that your productivity with a given tool also depends on your own preferences/cognitive style. Between Ruby/Rails and Python/Django, my assessment, even if I don't know the latter anywhere as well as the first, is that your results will depend a lot on your preferences and cognitive style.
- ezekg 4y ago> "Find pattern" is no longer experimental. This makes me so happy. Pattern matching is amazing, and I use find patterns quite extensively. And I’ll be even happier to run tests without RUBYOPT='-W0' moving forward. Also great to see Regexp.timeout as well as the ability to initialize a Struct using kwargs without keyword_init: true.
- sacnoradhq 4y agoI can't influence people at work to use Ruby correctly or to learn it. It's a battle to ship linters amongst people who don't have CS degrees and express hostile disdain for any suggestions of software craftsmanship, much less curiosity. They want to use their dumb patterns and bad habits, and aren't interested in changing.
- matheusmoreira 4y ago> The following deprecated methods are removed: Dir.exists? File.exists? These names were really elegant, I wonder why they were removed. Searching the web, the only explanation I can find is they were removed because they were deprecated. So why were they deprecated?
- tomstuart 4y agoFor better or worse, the convention in Ruby is to name methods in a second-person style [0], as if addressing the object directly: “file, do you `#exist?`”; “string, do you `#start_with?` foo?”. So, for consistency, `Dir.exist?` and `File.exist?` have been preferred for a long time. [0] https://bugs.ruby-lang.org/issues/9041#note-1 https://bugs.ruby-lang.org/issues/9041#note-1
- matheusmoreira 4y agoThat's true for File objects responding to an :exist? message. For the File class, I think exists? makes more sense. Anyway, no big deal. Happy to see Ruby getting nicer and nicer every update.
- grzm 4y agoLink should be updated to https://docs.ruby-lang.org/en/master/NEWS/NEWS-3_2_0_md.html https://docs.ruby-lang.org/en/master/NEWS/NEWS-3_2_0_md.html. The current link is now pointing to News for Ruby 3.3.0