I don't know the better way to ask this question, so I'm just going to ask it:
"Congratulations, you're right, and nobody cares."
Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?
I genuinely want to know where you go from this position.
I'm aware that there is more to Rust than enums, and that you were using that as an example of a correctness feature that is part of a gestalt of correctness features. My point is that people have been arguing that more expressive languages with stronger type systems will be better able to model problems and thus avoid logic vulnerabilities, and that hasn't panned out at all.
Since I don't think there's any evidence to support your point that's a Google query away from you, I guess something you could present that would weaken my argument is an example of a recent meaningful sudo vulnerability where idiomatic Rust, written in the manner that a typical Rust programmer would use to solve the relevant problem, would have foreclosed on that vulnerability. Obviously: we pre-agree about memory corruption vulnerabilities here.
While I appreciate Rust's correctness features and dearly miss `match` statements, as a software security professional with (I think I can say) a lot of experience looking for the kinds of vulnerabilities we're talking about here: I do not buy this theory of Rust's security advantage, like, at all. People have been saying things like this about strongly typed languages of varying sorts (Haskell was once a favorite) for over a decade, and it hasn't panned out. I think you'll find, if you look at the last (say) 10 meaningful sudo vulnerabilities, that there isn't a clear story about how enums would have steered you away from the problem.
Certainly, if there's an appetite for a reduced-fat version of sudo that caters to the 80-90% use case, I'm all for a Go, Rust, or whatever version of that thing. But then, C programmers were making the same argument 15 years ago, and nobody was able to sell the reduced-fat sudo (or, for the matter, the reduced-fat ssh, which we're all still dealing with). If it works out, great.
If it ends up gradually becoming a 1:1 equivalent to sudo, wartfeatures, and all, that's less great.
That's not really responsive to the concern. The issue is that we've already had decades of experience with the existing sudo codebase looking for logic vulnerabilities. And, in fact, that's what the overwhelming majority of sudo vulnerabilities are; they're not generally memory safety bugs. So rewriting in a new language to get rid of memory safety vulnerabilities is not, in fact, an obviously good tradeoff.
As a Rust programmer, I have the exact same lived experience of the language that the parent commenter does: that Rust can be relatively straightforward to write if you liberally clone things, but that the prevailing community norm strongly suggests that cloning is a code smell, or something you do in tooling-grade code.
The parent commenter was surprised that you suggesting liberal cloning was the way Rust code should be --- that, like, the median Rust crate should probably be written in the "clone liberally" register. You said that was the reason you wrote the Rust book aside. But I read that book and that aside and reached the opposite conclusion, and I think people who follow your link will mostly see why.
You haven't exactly cleared things up here, either. "For non-beginners, clone isn't a moral issue". Well, that's not what you just said upthread. I'm pressing you on this because it would be helpful to get an actual clear signal on this. Should most code be written with liberal clones, or should most beginner code be written with liberal clones? Like the previous commenter, I just want to understand what you're trying to say.
(A sibling comment here says the exact thing that I'm saying creates the mixed message here: that cloning is fine... in beginner code, but not in serious code.)
This is not, as we both know, a minor distinction in Rust; it is maybe the biggest stylistic distinction in actually writing Rust? Moreso maybe even than async?
The aside in the book says the opposite of what you claim it to be saying. Here, you suggest that liberal cloning is the way it should be; there, you say it's fine for beginner code, which is a very unsubtle nudge. Which is it?
You said "They for some reason didn't seem to want to use the right workflow", which by my lights manages to be both loaded and dismissive (if that was the goal, well played). I pointed out that the "some reason" is right there in the post, and you doubled down. I'm not sure why you did; you could have just said, "oh, interesting, thanks" and I'd have said "pip pip! cheerio!" but if you want instead to... uh... explore the contours of this controversy? I'm always game, which is what you're experiencing now.
If you want to keep me invested in a programming discussion, one very good way to do it is to imply that you can't for the life of you understand why someone wouldn't want to vendor Capstone.
For all the same reasons that vendoring isn't the default option in any dependency management system in any language: because there is a cost to vendoring. She didn't say that, but I wouldn't think she'd have to. You don't vendor all of your dependencies either: why not? There's your answer.
I'm wondering if maybe you've missed the part where they don't need this single dependency in the builds they're talking about doing.
It seems like the Rust community people responding on the ticket had no trouble understanding what the issue is. There's a difference between acknowledging something and conceding that it needs to be changed.
The reason is right there in the ticket. They have exactly one dependency, and it's optional. They don't want to vendor it just so they can build the no-capstone artifact in CI without having to phone home to crates.io or whatever. You don't have to agree with her, but you can't pretend she didn't give a clear reason.
I have trouble believing this, at least in any generalizable way. I'm comfortable in both Go and Rust at this point (my Rust has gotten better since last year when I was griping about it on HN), and it's simply the case that I have to think more carefully about things in Rust because Go takes care of them for me. It's not a "think more carefully and you're rewarded with a program that runs more reliably and so you make up the time in debugging" thing; it's just slower to write a Rust program, because the memory management is much fiddlier.
This seems pretty close to objective. It doesn't seem like a semantic question at all. These things are all "knowable" and "catalogable".
(I like Rust more now than I did last year; I'm not dunking on it.)
The page literally includes the words "Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers." This is not a good hill to die on.
I mean, come on. Are you on a bunch of Slacks? At least one of them has a :resf: emoji. It's not just random Rust users; there are people deeply involved in Rust itself that disparage other languages. Maybe that's gotten better recently, but, again, come on: look at the "About" section on this project --- which is a great project! --- and how it talks about C/C++. I happen to think Rust people are correct about C/C++, despite loving in my bones how it feels to write C code. But that doesn't mean I have to pretend that there's a real norm in the Rust community of respecting other languages.
To me, this whole thing about Rust and its decorum in language debates reminds me of those projects that don't have codes of conducts, but instead a "be excellent to each other" policy. I believe what you're saying is something the Rust project wants to be true. But that doesn't make it so!
I say this with love as someone looking forward to the next couple thousand lines of Rust I'm going to have to write at my job.
I like Firecracker too, more than I like Docker (which is, obviously, Go). I don't have any problem with Rust. The parent comment, about Go being suited for small/medium scale programming, was wrong.
Go is doing more stuff in large-scale deployments, processing more traffic, doing more transactions, than Rust is. I don't just mean there are a lot more Go backend projects (there are). I mean that some of those projects do a lot more work than Rust does right now --- I don't mean ubiquitous infrastructure things like Docker and k8s, I mean purpose-built components for specific large-scale applications/platforms.
For instance: "Today, most Dropbox infrastructure is written in Go." Or: "Today Go is at the heart of CloudFlare's services". Or: "Rend is a high-performance proxy written in Go with Netflix use cases [ed: all internal memcache] as the primary driver for development". Or: "The search infrastructure on [Soundcloud] Next is driven by Elastic Search, but managed and interfaced with the rest of SoundCloud almost exclusively through Go services." Or: "How We Built Uber Engineering’s Highest Query per Second Service Using Go.". Or: "Handling five billion sessions a day – in real time [at Twitter]".
I don't see where there's room for a "that said" here.
Yes, and, just to keep this clear: that debugging (or unit-testing-for-typos) time is coming out of your prototyping budget. Your Ruby program will fail to run for stupid reasons the first time you run it, which is not the experience Java and Go and Rust programmers have. I just remember when I first picked up Go, after about 5 years writing Ruby exclusively, how amazing it was that all my Go programs "worked" the first time I ran them. Obviously, they had bugs. But they didn't blow up for stupid reasons.
I'd been a C/C++ programmer for about 10 years! I guess I just forgot that compilers can catch typos if you let them.
... right! I agree! So, again: why were you volunteering opinions about the norms-compliance of this Cloud Flare project on Reddit, rather than just saying, "huh, no idea, wasn't involved"?
Hold on, you had no trouble judging whether it was good or bad on that Reddit thread. And, in case the subtext isn't clear: you've been at Cloud Flare for like, a minute. And as you said downthread: this is what you do: you advocate and evangelize. So this seems like pretty legitimate grist for discussion. Are you comfortable with your advocacy here, or having second thoughts about it?
:gif_of_homer_simpson_backing_slowly_into_the_hedge: is a totally legit response to this whole situation, for what it's worth.
(I'll reiterate: it would be amusing if your employer just smote me where I stand by revealing the large donation they've made to Jason's project).
Well, they took WireGuard, wrote a Rust implementation of it, refused to collaborate with Jason, who's been trying to get a Rust implementation of his protocol off the ground, then rolled it out as a proprietary offering that WireGuard itself is not allowed to connect to. This seems like the sort of analysis that would be pretty cut-and-dried among open source advocates (I'm not one of those, so I'm not saying it's cut-and-dried for me).
Your previous rooting interest in this story would have been for Rust itself. And Rust itself would have been been best served by having it host the dominant sanctioned userland implementation of WireGuard, not merely as an implementation detail for a commercial offering that also treats WireGuard as yet another implementation detail. Rust? Important! WireGuard? Important! Warp? Who gives a fuck?
So this is a bit of a surprising response to see from you.
Apologies for the late edit:
I should lay my own cards on the table here.
First, it's not much of a secret that I'm no fan of big Flare. But just to be clear: good friends of mine have worked there, and several other people I deeply respect have as well, and I don't judge any of them for that.
Much more importantly: Jason Donenfeld is, to my mind, the hardest working person in show business, and he's set himself on one of the most important projects in network security, basically all on his own, and the momentum he's managed to achieve doing that is insane and a little inspiring --- especially given the amount of shade he's been repaid with by network security luminaries --- and basically the last thing in the world he needs is to burn cycles worrying what some giant corporation is doing with his work (which, sure, does not include this Rust implementation, but very obviously does include all the hard protocol design and validation work he's been doing over the last several years, which, if it were easy and straightforward to do, several people would have done before him).
I've done about as much serious technical work on WireGuard as you have --- to wit: none, though I am a loyal, diligent distributor of WireGuard stickers. My partners all feel the same way, so we've just been sending the project cash.
If your employer has done the same, and dumped a giant bucket of cash on Jason in exchange for having gotten so much mileage out of his work, that would be an excellent rejoinder to this particular set of concerns.
Eagerly, therefore, awaiting my comeuppance on this thread! :)
Yeah just to be clear, you're simply at the leading edge of a phenomenon that's been puzzling me for awhile, probably starting with that Yegge/Grab piece (after which, from what I can tell, he was never heard from again). Don't fade away!
This is a genre of post that I've never really understood. Klabnik is great and all, but, ok? Sure? Were people really record-scratching over his totally reasonable decision to take a good-paying job at a big company?
It's obviously not just Klabnik. In fact, when we did Starfighter a few years back, I think Patrick did one of these posts as well. But: like every other post about Starfighter on HN while we were working on it, the whole thing was pretty uncomfortable. It's an experience I'd prefer not to repeat.
There are lots of excellent people taking all sorts of jobs at all sorts of places, and, unless those jobs involve, I don't know, mechanizing payday loans to squeeze poor people or hacking the phones of people the government of Bahrain doesn't like, nobody needs to justify them. Some of these posts seem like they might be good examples of content actually better delivered in a tweet.
It's possible that I just don't think Cloud Flare has earned the spotlight Klabnik is giving here. Who knows. But I felt the same way when Yegge announced his job at Grab --- just, "why am I reading this?" I'm sometimes reminded of the way Anthony Bourdain described the trailing years of Mario Batali's tenure at Food TV (Batali was a "lion" but not in a good way). Like: did you want to write this, or did Cloud Flare reallllllly want you to write this?
I think if you'd led with the UB thing, the notion of C targeting an abstraction rather than being an abstraction would have been more compelling to me (the perf argument gets back to a place where basically everything in every language is artifacts and leaky abstractions; it's worth visiting but doesn't persuade me in either direction).
I guess my issue, even with the whole outline laid out (thanks!), is that while C "isn't how the computer works" in sort of the same sense as a SPICE model isn't really how a circuit design works and ns isn't really how a network works, it's close enough to be illuminating in ways most other languages aren't (and has the virtue of most mainstream hardware being explicitly designed to make it, and particularly it, faster).
I think more developers should know C (though I think almost nobody should write in it anymore).
For F-500 corporations, a $10k day delivering a training course with assessments isn't unheard of. But nobody is close to 100% utilized doing that work.
"Congratulations, you're right, and nobody cares."
Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?
I genuinely want to know where you go from this position.