Well -- never let it be said I wouldn't say it directly to you, and I hope after reading this you will at least understand why I feel the way I do.
I said what I said above, because I find your writing deeply incurious, and what is probably worse, directed towards others who are similar incurious, in much the same way say Fox News or MSNBC is in my country.
When I read your writing, I never have the sense you've ever thought critically about your opinions at all. There also seems to be only good things and bad things in your cosmology.
I hope you know this isn't to denigrate you as an engineer, or you as a person. You may be a wonderful person, and you have certainly built artifacts which are useful to your users. You do also seem to be very principled and sincere in your beliefs. And it's certainly not to say I always live up to my/these aspirations!
On the other hand, I think, when a software engineer expounds more broadly on software (which seems to be your only beat), they owe their readers a duty to be self-critical. For instance, as you, yourself, note: You're known for your Rust hot takes[0]. If you (or the comment readers) want me to get more particular see "Does Rust belong in the Linux kernel?"[1]. There you skip talking about memory safety to spend more than a few graphs on the "Trendiness" of Rust. An argument AFAIK that was never made by those seeking to integrate Rust into the Linux kernel.
And this is where I usually get off the Devault train, because it is another shallow strawman based on vibes. Not once do you ask, as someone who is intellectually curious might: "Maybe Rust is trendy because it provides lots of interesting and useful features. Perhaps I/Drew should try this new language, then I'd have some basis for the many graphs I wrote about 'Trendiness'."
Unfortunately for the reader, that never happens. Each blog post is one string of unschooled, untested assumptions tied inexorably to another string of assumptions, on and on, ad infinitum. I'll admit I've compared you to Tucker Carlson more than once because that is exactly what reading a Drew Devault blog post feels like, because yours is actually a deeply conservative breed of tech demagoguery, saying to your readers, again and again: "We already know what's right. Someone just needs to say it now and then..."
Similarly, re: your latest article[0], yes, you do, in a footnote, express that you thought Ted T'so's behavior was bad. But your solutions have nothing to do with remedying the bad behavior. Your solution is -- I was right all along, it was never going to work out, this couple needs a divorce. At every turn I keep expecting you to say: "Was I right? I think so because..." but, as a regular reader, I should know better. We are on the Epistemic Closure Express. Drew's writing only knows one destination.
TBC this beef doesn't just extend to your writing on Rust. Your writing on Linux packaging was what first bothered me[2]. Never once do you ask yourself questions like: Is there something wrong with the Linux model of 12 different package managers? What if a dev wants users to actually use his or her software, what should they do instead of wait? Do I really imagine distro maintainers are scouring the land looking for new software to land in their distros? Is there a software solution, perhaps a declarative language/system, which would make this easier? Your answer here is like your answer to bad behavior within Linux -- your problem isn't a problem. Because I can't tell my reader Linux has any problems? Because that would be too grey for my black/white world?
No matter the situation, no good can come from hatred. The RfL situation has already come from anger and bad, derailed arguments.
Instead of having beef with a stranger online and comparing him to an alt-right figure (which is very much not okay) I think having a good faith reply to a good faith personal opinion will at worst do nothing and maybe result in something at best.
Focus your hatred to the injustice of the world instead.
> No matter the situation, no good can come from hatred.
Appreciate this POV, probably ascribe to it. Suppose my "hate" for Drew is mostly re: his public persona. I "hate" Drew like I hate teams that play in the same division as my team, which is to say it that hate is lightly held.
So, yes, "hate" is probably too strong a term.
> Instead of having beef with a stranger online and comparing them to an alt-right figure (which is very much not okay)
I would disagree with this notion. In many ways, Drew is a demagogue and a populist and a (tech) conservative.
I am (tech) conservative in some/many ways too. But this disagreement isn't about our politics.
> I think having a good faith reply to a good faith personal opinion will at worst do nothing and maybe result in something at best
Agreed. But the problem I have with Drew don't extend to his good faith opinions. What bothers me is the incurious way in which he chooses to express himself, not what he believes.
Which I suppose it would be fine if he had a smaller audience, but he seems to want a broader relevance. I really do believe that 100 more and then 100 more people who express themselves in a similar way would be bad for any community.
>and comparing him to an alt-right figure (which is very much not okay)
When I read your reaction to being compared to one of the most influential conservative political commentators, I had an inkling that you were missing the forest for the trees. Twas such an egregious transgression that you were compelled to virtue signal about how "very much not okay" that is, then attempt to gaslight people with scary terms like "alt-right" (nowhere in his Wikipedia is he listed as alt-right). This is a common pattern I see from a certain segment of the population with a high propensity to have pronouns in their profile. As an experiment I click on your profile, and, well...
For what it's worth to me as a bystander you sound much more like Tucker Carlson or some Fox News host than anything that Drew has ever written (not that I pay particularly strong attention or that Inecessarily always agree with him). Instead of any arguments you essentially just attack the person with insults and strawmen.
I hope you don't just dismiss my post and it might trigger you to review your own style, considering that you seem to feel quite strongly about what/how people write.
> Instead of any arguments you essentially just attack the person with insults and strawmen.
Could you point out where I did this?
> I hope you don't just dismiss my post and it might trigger you to review your own style, considering that you seem to feel quite strongly about what/how people write.
Absolutely. Point out what you think is unfair about what I said above, and I will review. Thanks!
> More like an activist than ... well ... a normal well-adjusted person.
What then am I an activist for exactly? Rust for Linux and better package managers? If you think "activism" is my aim after reading my comment, I think you missed my point.
The point is -- I can't stand Drew's writing. And the reason why is not because he expresses strong opinions which I don't share, it's because -- Drew doesn't ever consider the possibility he's wrong. Even as a nodding feint to the reader that acknowledges intellectual humility is something we all expect. So, I will accept, in that limited space, I'm an activist. I am an activist for Drew writing better.
Do you really need another example of Drew's lack of intellectual curiosity? Well...
One might read Drew's "Rust is not a good C replacement"[0], and think wait a minute, Drew does actually collect some evidence there that Rust is adopting more features per year than C, Go or even C++. Yes, I'll admit Drew occasionally collects the worst evidence to make bad points.
Drew concludes: "[This prevalence of features] speaks volumes to the stability of these languages, but more importantly it speaks to their complexity. Over time it rapidly becomes difficult for one to keep an up-to-date mental map of Rust and how to solve your problems idiomatically." And this conclusion might be a reasonable inference to draw after one has worked with Rust over a year or so, and one can provide some examples of certain redundant or complex behavior, but Drew doesn't do that. He takes some information, which could be relevant, provides it out of any context, and simply moves on.
I'd note there is still no evidence Drew has ever even tried Rust in any of Drew's writing. He just doesn't like it from afar!
Or perhaps Drew could have provided an example of a feature that wasn't a good feature from the year of this blog entry (2019)? No, that might have required him to wrestle with his point a little, and that would be hard! As Drew says, "My approach wasn’t very scientific, but I’m sure the point comes across", failing to understand his superficial approach is exactly the problem with his writing, and this point.
His bullets in support are similarly facile. As Drew says: "C has a spec. No spec means there’s nothing keeping rustc honest. Any behavior it exhibits could change tomorrow." Left unremarked upon by Drew is how much of C's spec leaves C's behavior undefined, compared to the implementation defined behavior Rust, because that wouldn't serve to celebrate C and flog Rust. So we don't get the ordinary hemming and hawing one often sees in good writing ("It could be like this, but I think it's more like this..."). Instead, we get black and white. Heroes and villains.
This is the wildest single thing I've ever seen on HN. You decided it would be a good use of your time to try to explain - straight to someone's face - why you hate them. As though you were filing a Jira ticket about a human being. And you thought that was a good use of your time on this Earth.
> Not once do you ask, as someone who is intellectually curious might: "Maybe Rust is trendy because it provides lots of interesting and useful features. Perhaps I/Drew should try this new language, then I'd have some basis for the many graphs I wrote about 'Trendiness'."
From the article that you clearly barely bothered to read, and whose author you're accusing of a lack of curiosity:
>> I might even jump in and build out a driver or two for fun myself, that sounds like a good opportunity for me to learn Rust properly with a fun project with a well-defined scope.
> This is the wildest single thing I've ever seen on HN. You decided it would be a good use of your time to try to explain - straight to someone's face - why you (in your own words) "hate" them. Wild.
That's not exactly what I intended.
When I said "hater", I was poking fun at myself for being a "hater." Informally, in the US, a hater is simply a negative or critical person. You don't want to be described as a "hater", and I self-applied the term. But since "hate" is perhaps too strong a term for this forum (or is too US centric?), I disclaim that word as describing my feelings towards Drew, and apologize to him if I was misunderstood (Drew, I'm sorry!).
Now that we are past that word, how I feel about Drew and his writing is laid out in the parent comment.
> I mean, Drew literally says this in the article you're commenting on
I think you may have mixed up the two posts to which I was referring. It could be I wasn't clear enough.
>> I might even jump in and build out a driver or two for fun myself, that sounds like a good opportunity for me to learn Rust properly with a fun project with a well-defined scope.
I'm not sure how Drew claiming he might write a Rust driver in the future lends Drew credibility here? At least not the credibility I indicate is missing from Drew's post.
You're apologising to someone "if he misunderstood" when you said you hated them. How magnanimous.
Maybe one day you'll spend time composing your thoughts to put out there, looking forward to engaging in a discussion on a topic close to your heart, and instead you'll find someone saying they personally hate you.
I think both things can be true. The worst of the LKML are crybabies. The worst of Rustaceans are zealots. The worst of any community are usually a vocal minority. Rust for Linux can continue on their mission, and that’s noble. But conflict is to be expected between the babies and zealots, naturally. RFL is not mutually exclusive with a Rust Linux clone. Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project.
> But conflict is to be expected between the babies and zealots, naturally.
Let's note: that's not what happened here. A baby didn't meet a zealot. Here, a baby just lost it.
> Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project.
I agree a Linux compatible Rust OS is perfectly reasonable. I'm not sure it's a reasonable alternative. One contributor leaves because of technical nontechnical nonsense, so let's call the whole thing off? Rust was being included for a technical reason. Is this technical reason less true? Can Linux do without memory safety?
Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety".
Rust is merely a tool; a language that makes memory safety easier. It is not required for memory safety, nor does it, by itself, guarantee memory safety.
This is particularly true in supervisor mode, with hardware other than the CPU itself within reach.
> Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety".
I'm glad you were able to reason through it.
> Rust is merely a tool; a language that makes memory safety easier.
I suppose, if I overstated the effect Rust might have on memory safety, you risk understating it here.
> It is not required for memory safety, nor does it, by itself, guarantee memory safety.
No, but it does an incredible job?
This reminds me of a post, on this site, I saw which said something to the effect of "ZFS is only great because it is the only filesystem in its domain" which is ridiculous on it's face, but I think even more ridiculous as you dig a little deeper.
When someone who keeps shooting themselves in the foot says, "That safety doesn't prevent all the ways you can kill yourself". Sometimes you want to scream to that fool who manages to continue to avoid using the safety: "What more do you want?"
> This is particularly true in supervisor mode, with hardware other than the CPU itself within reach.
Of course, I'd agree to some extent, but I think your framing is again perhaps overly narrow. Rust is a really good tool. It's such a good tool I hear they are trying to write drivers with it in the Linux kernel.
>It's such a good tool I hear they are trying to write drivers with it in the Linux kernel.
And it's going to be a nightmare, because Linux famously makes changes every now and again which require maintainers monkeying all over code they do not know well to change references to functions and structures.
This is hard enough with just C, it is untenable with Rust.
Let's be honest. Linux isn't even that good. Is it worth the pain? The rust devs could get much more work done and without conflict if they worked on their own system, such as Maestro[0] (unix-like, AGPL but MIT if you go back just a few non-code commits) or Redox[1] (microkernel and multiserver proper, MIT).
> First, there is no reason why we have to choose between Rust in the Linux kernel and a new Rust kernel.
First, we may have to choose between those things because Rust in the Linux kernel is not gaining traction and major contributors are dropping out rather than seeing it through. It's valid to speculate about alternatives.
Second, software development is not a zero-sum game and such a rewrite can exist in concert with Rust-for-Linux (and even benefit from it). Drew is not handing out orders here anyway.
> Second, this would perpetuate toxic LKML behavior. I'd suggest maybe this bad behavior should be dealt with.
You've used the passive voice here, and the probable reason for that is that there is nobody who is or will ever be responsible for dealing with LKML's shitty "culture." It's a cesspool at every level and will continue to be so until everyone currently in a leadership position is gone.
In addition, the problem here is not technical. Rust is a solution to some technical problems, but technical decisions in a mature group effort are secondary to what Filho referred to as "nontechnical nonsense." That nonsense is the single most important aspect of the project, and too many of the Rust-for-Linux proponents don't seem to understand that. Without developer buy-in, none of your advanced futuristic solutions are even going to make it in the door. The fact that many of the developers whose buy-in you need are assholes is not grounds to reject the work. It simply makes the work less pleasant. Linux moves forward because the people who build it are moving in the same direction. If you want that direction to change, you have to convince a majority of the actors. You're not going to do that by telling them the tools they've used for decades are bad and wrong and the answer is this other shit you happen to be good at.
People keep making this assumption that Rust-for-Linux is hindered by technology considerations, but that was never the case. It is and always has been a sales pitch, and the Rust-for-Linux people have completely fumbled the ball at almost every stage.
There is a great example in Filho's linked video where he's showing get_or_create_inode and the C devs (poorly and abrasively) try to explain that this design means to implement special cases you have to go fucking around in the type system instead of just branching differently in the call site where the other logic is. Filho gets frustrated because he can't seem to understand that using types this way is not intuitive for many people, and the C people get frustrated because Filho's answers don't account for their objections at all.
There's another great example in this very thread where you declare that "the Rust devs showed an better/easier way." They, arguably, did not, if you're not a Rust dev. To someone who isn't accustomed to idiomatic Rust, it seems completely insane to have to go digging around in the type system in order to enable magic elsewhere in the call stack, when you can just tell the computer what to do. Nobody at any point is trying to demonstrate why the Rust approach is superior -- a position I happen to agree with, for the record -- and instead just bemoan these stupid C toddlers who don't take the same things for granted that Rust adults do. It's pointlessly demeaning, combative, and in this case self-defeating, and it's the primary reason I think projects which use Rust ab initio succeed more than these piecemeal approaches.
We mostly agree. I come to a slightly different conclusion. That more than a sales pitch someone needs to lead this project. GKH could decide to build something in Rust for instance.
Re: whether Drew's proposed solution is a reasonable alternative to Rust for Linux, I don't think the technical/practical reasons for wanting Rust for Linux have gone away. We use Linux. We want memory safety. We will be waiting a long time if we are waiting for a new kernel to appear.
> To someone who isn't accustomed to idiomatic Rust, it seems completely insane to have to go digging around in the type system in order to enable magic elsewhere in the call stack, when you can just tell the computer what to do.
I think this would be a fairer point if the interface was a well documented C interface, which demonstrated how to use the interface correctly but it wasn't.
Ask yourself when and how this can fail. I'm not sure those case are covered here, but they definitely were in the Rust type signature. If these C guys don't like types, fine. But these guys need summon help quick if the above is the best they can do.
The level of documentation is fairly demonstrably irrelevant. I agree it's garbage, but on the other hand all fifty or so filesystems in the kernel seem to get by without it, and have done for as long as the API has existed. Rust doesn't even have a specification ... still ... a year after deciding one was necessary ... so fingers point both directions here.
But even this is a sideshow, a distraction from the main point: these C people are the ones you need to convince. Bitching at them isn't going to make it happen. Until someone sits down and deploys sufficient empathy to figure out how to appeal to their priorities, good things will continue not to happen for Rust-for-Linux. No amount of technical evidence will do the job.
> I agree it's garbage, but on the other hand all fifty or so filesystems in the kernel seem to get by without it, and have done for as long as the API has existed.
Have they? I mean what we know from Asahi Lina is that other subsystems need help. That DRM is mostly garbage that needs fixing.
> Rust doesn't even have a specification ... still ... a year after deciding one was necessary ... so fingers point both directions here.
I'm not sure that's a great example. Especially re: C, with UB all over the place. C says "Sure we have a spec! It doesn't cover that much, and compiler writers are eager as hell to break your bounds checks."
> Until someone sits down and deploys sufficient empathy to figure out how to appeal to their priorities, good things will continue not to happen for Rust-for-Linux. No amount of technical evidence will do the job.
I think somebody needs to lead this project FFS. Either Linus or GKH. Someone needs to either make it happen or dump it. Screwing around with these Rust devs for years is effed up behavior.
