I think you might just be misreading the original post. It could be rephrased as: “all developers who dislike TypeScript and Tailwind either haven’t used them or aren’t skilled with them.” If you could say that about anything, it would mean that developers never dislike tools with which they are skilled. I’m saying that’s clearly not the case.
Okay, so I’m saying that there are lots of languages for which that’s not true, i.e. people who use the language do dislike them.
The statement is “only developers who have never used them or aren’t skilled with them dislike them or prefer [the primary alternative]”. Is that what you mean could be applied to “literally everything”?
…no? I have heard (or made) plenty of complaints about various languages from people who know and/or use them professionally.
Eh, he also said “While not my favourite language it’s definitively one of the best new ones and I encourage people to use it for new projects where it fits.”
But…that’s exactly what’s happening. Rust is already in the kernel, with both Linus’s and GKH’s approval. CH is trying to singlehandedly reject any use of Rust in any part of the kernel where he has maintainer status. That’s pretty specific to R4L.
Christoph Hellwig isn’t criticizing Rust the language, and Hector Martin isn’t claiming that he is. This is about a project, Rust for Linux, that has been endorsed by both Linus and GKH, and one maintainer personally attempting to stop it from moving forward.
I didn’t use the word “personal”, but it’s inherently somewhat personal in that it’s one person trying to fight back against a decision that Linus and GKH have both endorsed (to put Rust in the kernel). “Crusade” is strong wording, but so is “I will do anything I can to stop this.” That’s far beyond simply “prioritizing [other] things.”
Hector Martin isn’t claiming that Hellwig’s crusade is against Rust, but against R4L. The problem is that the R4L project has always been about Rust in the kernel. “Don’t bring new languages into the kernel” is a crusade against R4L.
Do you take this sentence seriously, or not?
I will do everything I can do to stop this.
As far as I can tell, “this” here refers to literally any Rust code that isn’t constrained within a specific driver. That does indeed seem like a full-on attempt to stop the R4L project entirely.
He does appear to have a real technical concern regarding maintainability.
“Appear” is doing some heavy lifting there. Opponents of the R4L project always couch their objections in technical concerns. For what it’s worth, I can’t actually find any concerns of merit or substance in that particular thread, although navigating mailing list threads is honestly pretty error-prone, so I may have missed it.
Nope. I can’t find that exact screen, but you can find registration for the webinar here: https://go.oracle.com/LP=130256#On-Demand-Webinars
Unless you work for the committee or for ISO somehow, then I don’t think that really follows. C++ and JavaScript were both used in production for decades before they had standards, and the dissolution of the standards committee wouldn’t cause compiler vendors to stop developing compilers.
Wait, which one leaves you unemployed?
In addition to not actually being correct, I don’t think the information you’ve provided is particularly helpful in answering OP’s question.
The first part is confusing what “middleware” means. Rather than “duplicating” functionality, it connects libraries (I’m guessing this is what you meant). But that has nothing to do with a language being compiled versus “directly executed”, because compilation doesn’t connect different services or libraries; it just transforms a higher-level description of execution into an executable binary. You could argue that an interpreter or managed runtime is a form of “middleware” between interpreted code and the operating system, but middleware typically doesn’t describe anything so critical to a piece of software that the software can’t run without it, so even that isn’t really a correct use of the term.
The second part is just…completely wrong. Lisp, Fortran, and other high-level languages predate terminal shells; C obviously predates the shell because most shells are written in C. “Most original code” is in an actual systems language like C.
(As a side note, Python wasn’t the first scripting language, and it didn’t become popular very quickly. Perl and Tcl preceded it; Lua, php, and R were invented later but grew in popularity much earlier.)
Pretty much all languages are middleware, and most of the original code was shell/bash.
What? I genuinely do not know what you mean by this.
It is similar to old error codes, but I feel that this makes one always have to be mindful of error handling and the non happy path
Technically you need a separate linter (errcheck) to ensure you don’t just ignore errors. This is…not great. (That should have been a compiler error.)
I agree that it’s a “cop-out”, but the issue it mitigates is not an individual one but a systemic one. We’ve made it very, very difficult for apps not to rely on environmental conditions that are effectively impossible to control without VMs or containerization. That’s bad, but it’s not fixable by asking all app developers to make their apps work in every platform and environment, because that’s a Herculean task even for a single program. (Just look at all the compatibility work in a codebase that really does work everywhere, such as vim.)
Oh, I see, so you don’t exercise your muscle memory but you at least see the “raw” commands more often.
Looks like this was suggested in nushell, and someone came up with a way to emulate the behavior manually: https://github.com/nushell/nushell/issues/5552#issuecomment-2113935091
Edit: there’s another issue for this: https://github.com/nushell/nushell/issues/5597
Hopefully nu will decide to implement it properly in the future.
So…I’m not sure what that implies about the statement? “Someone probably believes X about Y” isn’t just true for any Y, it’s true for any X.