> Or just once, to say the entire OSS committee was employed by Shopify,
Mike works at Basecamp (now and then). Based on comms I don't believe any of them acted on behalf of their employer i.e. no "team orders." Or if they did, they did so in ways that aligned with my perception of what I believed to be the correct read of the situation.
I also think that we (as humans) are much less incapable of knowing what things sway and influence our opinions than we think. We are much less capable of correcting for conflicts of interest than we would like. The study "tappers and listeners" is about adjusting for knowledge (curse of knowledge), but I think it applies to influence as well. Which is to say...I'm sure that everyone was influenced in many ways, but I felt they acted as individuals and reacted in real time.
There are other details of affiliations that I omitted from the former maintainers as well, that are true to state, and likely had some impact on their decisions ... but I used judgment to omit what I didn't think was fair or didn't think was immediately relevant. Not saying I got it all right all the time, but sort of chiming in to say "I'm not only omitting information in favor of one party." Yes, I'm biased...but I'm trying to correct for that bias. (A funny thing to state after just saying humans are bad at it, I know).
> (2 current, 1 former) of Shopify's technical leadership
You'll have to take me on my word about it...but if I saw this as a driver of the issue I would have included it. I think saying "shopify was involved" is sort of like saying "people talked about RV at Rails World." Shopify is huge and hugely invested in Ruby's OSS ecosystem. I have my own critiques of the company, but not here. I think they're a net positive for Ruby OSS. I wish the general response was "more companies need to step up, I'll go talk to my leadership" rather than knocking these volunteers for their involvement. I've said elsewhere that if I were in the committee or in their shoes...I don't think the outcome would have been different (even if details would have). Also, you are welcome to disagree and have a different opinion.
I agree that it's best not to have situations like this. PSF bylaws "Section 5.15. Limits on Co-affiliation of Board Members." and similar rules are generally good at preventing the perception of conflict of interest (which is also important...that the perception alone can be damaging).
Right now, the committee is 100% one company (me). Because I'm the only one on it. Which is also a problem. Also, we're in a rebuilding/re-prioritizing phase with all of this...so it's hard to onboard while things are in flux.
This was never in dispute from the two parties. Ruby Central and "the maintainers" agreed from the beginning that it was collateral damage. The disagreement was what that meant and what to do with it. Hence the Sept 10 message from the Ruby Central Committee that they should move it to the Ruby core org (which IMO is long overdue).
The original plan (by the oss committee)was to move bundler to the Ruby org, that's what happened. When it did, the community generally like it (on HN and reddit comments).
You got your reply already. To add: YJIT is the one that does "basic block versioning" (Which was Maxime's thesis) while ZJIT is a more traditional design.
I am confident in that description but don't actually know what it means in practice (yes I've seen papers and talks, but I kinda need not-compiler-engineer to explain it to me.)
As I understand it BBV still holds promise, but the sheer volume of knowledge of more traditional methods might mean it gets better outcomes (also IIRC ZJIT is still lagging YJIT).
Pedantic point: YC has ads, they are just blend in much better and are delivered in the same medium.
Hiring posts (definitively) and tech posts (maybe) by YC companies. The whole product is one big ad for a venture fund. Its generally well done and unobtrusive. So kudos to them for that it goes relatively unnoticed.
Relevancy is a big point here. HN readers work in tech or are super interested in tech, YC companies do very technical things so hiring posts or launches tend to blend right in for the most part.
Thanks. I was a genuine question and you answered it well. For some reason I've internalized that closures can capture variables sometimes, but I guess I'm not sure the conditions in which that's true (or perhaps I've learned/mis-remembered the wrong lesson a long time ago.
If the code in the closure moves a value, then the closure becomes an FnOnce and does move the value out of the context. That's what you probably have in mind.
So, Rust does support partially-moving closures, and does so automatically.
But the converse is also true: Rust does not move values just because. If the code inside the closure doesn't move the context, then it will only move context if you use the `move` keyword (in which case the lifetime of the closure is not restricted by borrows of the context; Rust doesn't automatically move things to satisfy the closure's required lifetime, that's a manual decision process consistent with how Rust behaves in other places).
There's still one difference to the macro case: the closure borrows all the values at once. So if it needs &mut access to some variable in the context, you can't take another &mut to the same variable outside the closure as long as it is alive (as determined per what the non-lexical lifetime borrow checker can do). Those cases need to be worked around by instead passing in the &mut as a closure argument. Code deposited by macros is not subject to bundling all captures together, hence the borrow checker has more allowance to reduce the borrowing time of each borrow.
I remember reading this when you published it! I was considering going at the time, as well as some years after, but this + work + starting a family had me choose different. I don't know if you've written a follow-up, but I would 100% read that.
Mike works at Basecamp (now and then). Based on comms I don't believe any of them acted on behalf of their employer i.e. no "team orders." Or if they did, they did so in ways that aligned with my perception of what I believed to be the correct read of the situation.
I also think that we (as humans) are much less incapable of knowing what things sway and influence our opinions than we think. We are much less capable of correcting for conflicts of interest than we would like. The study "tappers and listeners" is about adjusting for knowledge (curse of knowledge), but I think it applies to influence as well. Which is to say...I'm sure that everyone was influenced in many ways, but I felt they acted as individuals and reacted in real time.
There are other details of affiliations that I omitted from the former maintainers as well, that are true to state, and likely had some impact on their decisions ... but I used judgment to omit what I didn't think was fair or didn't think was immediately relevant. Not saying I got it all right all the time, but sort of chiming in to say "I'm not only omitting information in favor of one party." Yes, I'm biased...but I'm trying to correct for that bias. (A funny thing to state after just saying humans are bad at it, I know).
reply