The founding purpose of Ruby Australia is to further the use and adoption of the Ruby programming language in Australia, and to support and encourage a vibrant community around the language and related technologies.
Nice talk :) Regarding fibers going across threads, I think it's a reasonable idea for implementing work stealing, however the problem right now is threads also limited by the GVL, so in terms of parallelism, there is little to gain. We'd have to make threads work without the GVL for it to have real benefit. As it stands, it's probably not worth the effort without "free threading". Regarding actual Fiber going across threads, it was impossible before due to the default copy coroutine implementation, but I removed that and replaced it with a pthread implementation (fibers emulated on threads). Because of this, there is no longer any reason why fibers can't go between threads.
I feel that this code introduces a meta programming unnecessarily. I know it is a cultural thing in Ruby and Rails to look for elegance (or perceived elegance) than simplicity, but it comes at a cost. For example, * Why use symbols and then constantize it? Just specify the class name. * Why use meta programming to call the `inherited` hook and create classes dynamically. Just create the classes manually. In my experience, simplicity beats elegance.
Mu Fan congrats on sharing this comprehensive talk about the reinvention of the app. I find it interesting that ruby code tend to be structured in a slightly different way depending on the country or past experiences of a developer. Keep up the good talks!
I don't get it. You say that GIL prevents threads from executing in parallel, then in the last slide you suggest to use Threads for CPU intensive tasks. Did we suddenly start using JRuby or something? And example of Fibers in action would have been nice.
Ractors are not production ready yet. From a few benchmarks, they don't seem to offer any memory benefit over multiple processes. On the other hand Fibers are stable and was introduced a long time ago. They are production ready. With respect to use cases, Ractors are like sub interpreters to by pass the GIL/GVL. So if you have some parallel workloads, you can use this. Fibers are the equivalent of asyncio, event loop mechanism in Python and JavaScript equivalent. They can be employed where "concurrency" patterns solve your problem well. They are basically IO bound problems. For example, db calls, network calls, file reading and writing.
Steno-ing and live coding on stage while talking and trying to entertain is definitely not the same as just doing it at home :) The barrier to giving steno a try is lower than ever, so if you are even just a bit curious, I'd say give it a shot!
It is harder to speak and code at the same time than you would think. Im curious as well as you are on the coding experience.. perhaps more videos with less talking and more coding better can show what we will hit if we jump the steno wagon
Great talk!!! These are essential skills for great software teams IMO. A great tip I received once while working on a PR to an opensource project was that if you feel the need to leave comments on your PR explaining parts of the code, maybe consider instead breaking those changes out into their own commits with commit messages explaining the change instead.
It seems like isolating gems installed to those required for the current test set + prod gems would have caught this. Rubocop is needed during the CI lint step, but probably not during the testing stage. This still leaves you vulnerable to accidental dependencies on dependencies of your testing framework (which if minitest is only anything defined within minitest itself), but the risk is much smaller. Also perhaps running independent end to end UI tests in staging (or better yet, prod behind a feature flag). I may be missing something though. Either way, I loved the talk
Fantastic presentation! I wish I discovered the trick with multiple id's on Brave to settle down that nonsense poll with 'tabs' vs 'spaces'. Everybody knows we need to embrace more 'green' practices, stop wasting resources and littering 2, 4 and sometimes 6 'spaces' everywhere, when we can easily get away with only 1-tab. Just imagine how many wasteful 'space' characters are out there, wasting precious storage... OUTRAGEOUS
Thanks all for attending. I hope it was insightful and not too boring, I forgot half of my dad jokes though - It was a bit intense to present in front of such an Elite crowd, haha. Ping me if you need any clarifications / want to pair up. Also, UPD Re Sidekiq question at 37:00 on how to include a separate Sidekiq span into a calling span - there is a way to do it by updating your OT Sidekiq instrumentation config "c.use 'OpenTelemetry::Instrumentation::Sidekiq', { with 'propagation_style: :child }" Cheers and stay happy! The name... is TheFriendlyTelemetrAntz
Thanks Adam, just hauled some old codebases up to ruby 3.2 so was starting to look around at what "new toys" this has unlocked for us and was eyeballing YJIT with great "how much of a rabbit hole is this going to be?!" trepidation! Will give it a crack next hack day and see if I can get a similar shift on our APM graphs :)
