rabidferret

I will not stop shitposting on main though

I am odd, yes. I also care deeply about supply chain security and focused on it when I led the crates.io team as well as during my time at the Rust Foundation. You can rest assured that my occasional shitposts are not opening an attack avenue for your supply chain.

- Sage

Crap, I'm supposed to be an engineer?

No

If David had come forward when everyone else did about how this situation played out, and actually spoken to JeanHeyd or apologized ever, that's exactly what would have happened.

I'm the organizer who gave the invite. It was indeed explicitly framed as "you can talk about whatever you want". In my opinion it was pretty obvious this is what JeanHeyd would talk about before the invite went out. He told us about the topic in that same call. There was a member of project leadership in the call as well, no concerns were raised about the topic. The first time JeanHeyd learned of any concerns with it was when project leadership asked me to downgrade the talk

I used to maintain a library which actually tried to implement proper English pluralization rules. I can confirm you don't want to do that.

Why would they filter emoji specifically? They're such a major part of modern communication

I would just like to tack on that malicious code is against the crates.io terms of service, and something like exfiltrating secrets in a build script is something that very clearly qualifies as malicious. If you ever encounter this in the wild, please make sure you report it to the crates.io team, so it can be removed.

> Or now that I think about it, is it instead the case that a whole program including all dependencies will be compiled by the same compiler (of which newer editions will have the latest security fixes)

It's this. Rust doesn't (yet) have a stable ABI for functions that aren't marked `extern "C"`. Any security vulnerability that would affect code in rust-lang/rust would most likely be in the standard library, which doesn't change between editions. All code links to the same libstd. Only the compiler frontend changes

> I think that it's very straightforward, personally, with very very simple rules (especially in 2018).

I agree with you. It's a shame we don't have a simple visual metaphor to describe this

EDIT: Wait does hacker news just delete non-ascii? I tried to put an upside down smiley here how is this even worse than I thought

I have always wondered this!

    let plural = match cases.len() {
        1.. => "s",
        0 => "",
    };

;P

For purchases like the one in the article, you can absolutely purchase with stock in lieu of cash. This happens all the time, and doesn't have nearly the impact on the share price that selling for cash on the exchange does.

How much cash you could get in a vault isn't really a useful measure of wealth since cash isn't the only object of value that you can exchange for goods and services (which you even pointed out in your comment by mentioning gold)

Yeah, unfortunately there's not really much of an alternative here besides dropping libgit2 and subshelling out to git (which we honestly should consider, it just hasn't been a priority).

Often times database changes are a complex multi-stage process. Since we're still a small team, we're able to have them merged as a single PR and the author deploys each commit as needed. A complicated CD process would just add more burden on our team at this size, and is really more useful when you have enough people contributing that those sort of complex deploys block other people's work

Anything that doesn't require W+X would need an entire page allocated per closure, wouldn't it?

`void ()(void, everything_else)` is in my personal experience a much more common API than that of `qsort` (probably for exactly the point you're pedantically trying to make), so I chose to focus on that API for this article.

There's really no reason to pass a rust closure to `qsort` instead of sorting in Rust. That said, if there's demand for real world use cases that require passing Rust closures to C APIs that take only a function pointer and not a data pointer, I'll be happy to write a follow up.

It doesn't relate to it at all. The issues around linking to problematic object files mentioned in that article will apply to Rust as well, but that's unrelated to the subject of this article, it's a property of the linker you're using and the toolchain used to compile whatever C dependencies you have

Literally the second sentence of the article

I've never contributed to go in the past, why would I be transitioning to working on go full time?

In case it wasn't clear from the article, I'm moving from contributing to Rails to Rust, not as a user. Most of my contributions to Rails were around Active Record (the ORM), and I got into Rust by creating its most used ORM. My main role in the project right now is co-leading the team responsible for crates.io, the Rust package registry, which is a web application written in Rust.

So all of those things overlap quite a bit (also am I not allowed to expand the scope of things I work on beyond web frameworks? I'm not really sure why they have to overlap at all)

Yeah, it's a problematic model if we were to look at it as a solution to open source funding. It requires you to already be contributing heavily to a significant enough project that you'd be able to get these grants in the first place. Being able to get there without being paid along the way is a position of extreme privilege that not many have.

I spent a lot of time wrestling with the decision to even try this at all ("is it fair for me to do this when so many others can't?" and "will folks just think I'm abusing my position" are both things I had to come to terms with).

That said, if we do a better job of breaking down barriers to getting into that position in the first place, it's not a terrible model to start with. Getting a enough large grants to fully cover a salary from various companies a year is much more feasible than getting enough tens of thousands of individuals to contribute.

Working with these shorter sponsorships vs a full time employer also just feels more like the kind of open source work that got me wanting to do it full time. It lets me be much more flexible on when/what I work on (within reason, there are expectations on what "full time on crates.io/Rust" means). It's also helps to avoid situations where the employer is upset because you're spending time on a feature/bug/whatever that is important to the ecosystem but not directly useful to the company (e.g. working on a PG specific feature in Rails while employed by a company that uses MySQL)

Yeah, calling it "The Rust organization" was probably a mistake, as it can be confused for something more official than the nebulous non-official entity that I'm referring to

My goal wasn't so much to promote any specific answer, just to rebute the argument that the solution to memory safety bugs is to have better C programmers

Ah, I see. You're wanting to have destructors run on local variables assigned in `main`.

If you don't care about the specific error code as long as it's non-zero, just returning `Result<(), impl Debug>` does what you want on stable now, right?

Calling `std::process:exit(1)` at the end of main is identical to `return 1`. I'm not sure what your point is with `env_logger::init`. It sounds like you think destructors are run on static items? They aren't. In fact, until very recently you weren't even allowed to have destructors on consts/statics

Unless I'm misunderstanding you, [`std::process::exit`](https://doc.rust-lang.org/nightly/std/process/fn.exit.html) does what you want.

Just wanted to mention that your usage of `sql_query` is exactly how it's meant to be used, and exactly where I would reach for it. Great article!