byroot

25 ms·

271.
by byroot 5y ago
Seems maintained to me: https://rubygems.org/gems/delayed_job https://github.com/collectiveidea/delayed_job
272.
by byroot 5y ago
Some professional Jargon are non-composable too when they use the same words for different meanings.
273.
by byroot 5y ago
> Why would the majority of gems have anything at all to do with Rails or need it to work as advertised? That's what your often hear from "Rails skeptics". According to them people don't even know what is Rails and wh
274.
by byroot 5y ago
I think "Jargon" would probably have been a much less controversial term than "Dialect" for expressing this idea. "Dialect" implies that it's a sub-language, but Ruby is still Ruby no matter how many metho
275.
by byroot 5y ago
> Unsure if CI services like buildkite have really made this that much faster Buildkite doesn't directly help with it, but since you bring your own hardware and that it's highly customizable, it does allow you to invest in impr
276.
by byroot 5y ago
In the grand scheme of things it doesn't matter that much. Once you starts parallelizing, CI time is: setup_time + (test_run_time / workers), so assuming money isn't a problem you can add more workers as you keep adding more
277.
by byroot 5y ago
> So is it worth the hassle of introducing a new language? Just because it's small in term of line of code, doesn't mean it isn't tricky to maintain and extend. It's all explained on the ticket.
278.
by byroot 5y ago
> spending now several months rewriting YJIT I think you overestimate the size of the YJIT codebase. It's a very dense codebase in term on developer hours, translating it is far cheaper than it was to develop it from scratch. It al
279.
by byroot 5y ago
> just do their own Ruby implementation instead "just"... Several other Ruby JIT projects (Rubinius, JRuby, TruffleRuby, etc) have poured tons of resources, and while they perform very well, the adoption is still very low becau
280.
by byroot 5y ago
> I wasn't even referring to CRuby, I was referring to YJIT especially. My bad, that's really not what I understood from your initial statement. But yes agreed. The only real downside is discussed on the ticket. Ruby is primari
281.
by byroot 5y ago
I just gave a couple examples I had in mind because they came up recently. The point was that the parent's assertion: > you wouldn't use ruby outside of Linux, Windows, Mac, FreeBSD, OpenBSD Isn't quite true.
282.
by byroot 5y ago
> you wouldn't use ruby outside of Linux, Windows, Mac, FreeBSD, OpenBSD and Rust has support for more than that[1]. Ruby has support for plenty of "exotic" systems like HP UX, AIX etc. It's unclear how many people ac
283.
by byroot 5y ago
> You may not believe this You may not need to be confrontational... > there are other ways of versioning software I'm sure there is. But some features and other improvements sometimes require to deprecate and remove some older f
284.
by byroot 5y ago
Yes, you'd need an automated way to catch the API breakage, which would be particularly tricky. And even with very strict typing, the breaking change showcased in the article wouldn't have been caught, the API stayed the same, it
285.
by byroot 5y ago
No the expectation is that users of projects stop assuming SemVer is followed by every projects. > pushing breaking changes at a yearly rate. That’s a horrible developer experience. That's your opinion. I much prefer these bite size
286.
by byroot 5y ago
Rails committer here. First I get that people are used to SemVer, but it is unreasonable to assume all projects follow it. And yes in semver terms, you can simply assume that Rails X.Y is a major release. Then, any breaking change in Rails
287.
by byroot 5y ago
Aircraft parts such as wings etc. Airbus facilites are split across several countries, so it's simpler to move oversize parts like this.
288.
by byroot 5y ago
Tons have happened in stabilizing them, 3.0 had lots of Ractor related bugs. But no new Ractors related features no.
289.
by byroot 5y ago
Again, your complaint, while valid, has nothing to do with autoloading, but with namespacing: https://news.ycombinator.com/item?id=29117535
290.
by byroot 5y ago
You'd think so but that's not the case. Anyway the problem is mostly an independance one and there was no other French companies doing this.
291.
by byroot 5y ago
> It is mostly about turbines Turbines used in nuclear power plants as well as nuclear ships. That sale was/is a major scandal in France.
292.
by byroot 5y ago
Beside the operational nightmare that it would be to deploy with such a strategy, it wouldn't work long term. JITed code can be invalidated and recompiled, so your forks would still drift over time. I'm a big proponent of unicorn
293.
by byroot 5y ago
Because JITed code will inline things like the address of some specific objects (typically constants) etc. To share code between processes you'd need to ensure all these references are exactly the same in each process.
294.
by byroot 5y ago
Yes. Basically the main reason it isn't the default now is the still rough executable memory management. Other than that it's been rock solid and offers decent speedup across a wild range of benchmarks and real world applications.
295.
by byroot 5y ago
Each process, a small part of it might make it into CoW during boot, but that won't make a big difference. If you don't have the free RAM for it and you app is small enough, you can try lower values. Also note that currently YJIT
296.
by byroot 5y ago
Yes, it work fine with Unicorn, YJIT is currently serving a small portion of Shopify storefront traffic, and that app runs with Unicorn. Of course since each of the unicorn process will generate its own executable code, the memory usage dif
297.
by byroot 5y ago
$ ruby -v ruby 3.1.0dev (2021-11-08T09:35:22Z master 7cc4e147fc) [x86_64-darwin21] $ ruby --yjit -v ruby 3.1.0dev (2021-11-08T09:35:22Z master 7cc4e147fc) +YJIT [x86_64-darwin21] $ ruby --yjit -e 'p RubyVM::YJIT.
298.
by byroot 5y ago
> I’m curious how the impact affects development, deployment, etc. YJIT is pretty much transparent in production, if not it's likely a bug. When we tried MJIT in production to compare it against YJIT, it causes lots of request timeo
299.
by byroot 5y ago
It's not swapped, both are available for now.
300.
by byroot 5y ago
While I agree that OP's complaint is valid, I think they're wrong in blaming the autoloader for it. If you were to remove the autoloader and to explictly use `require` in your app, when you `require a` if `a` also `require b`, you

More ›