About time they retired C. Oh, that’s not what happened?
Don’t force me to deal with your shiny language of the day,
WE HavE LegItImaTe COnCeRNs
Exact same shit as last time, some cranky old dude with the territorial instinct of a bulldog sabotages anything to do with rust under a very thin layer of so-called technical concerns, yet refuses to partake in constructive discussion. Like, literally, the changeset is just bindings in
rust/kernel? What even is there to complain about regarding maintainability ofkernel/dma, given that as far as I can tell the rust devs will deal with any future incompatibilities?Very shameful for the kernel community that this kind of aggressive sabotage is regular and seemingly accepted. The incessant toxicity is not a good look and very discouraging to anyone thinking of contributing.
A C/C++ dev acting this way‽ Well I am shocked, SHOCKED!
A C/C++ dev acting this way‽ Well I am shocked, SHOCKED!
We want to not announce our confirmed biases if we want to encourage people to consider what we have to offer.
Rust is dead. Haven’t you heard? We’re rewriting everything in Zig now.
Rust should be deprecated.
On a more serious note, having a CTO at Microsoft, of all places, jump in on your side is kind of embarrassing. With one exception, code written at Microsoft has been some of the worst, most insecure, in the world.
Rust is dead. Haven’t you heard? We’re rewriting everything in Zig now.
I don’t think the broader zig community has the rewrite spirit that the rust community has. For Rust, this mentality was also motivated by an increased security, which zig does improve over plain C, but not to the extent Rust does.
To preface anything that follows, I’m not a developer, so this is little-informed opinion.
Writing in rust just doesn’t seem very enjoyable. It’s a language with security in mind, which is a good thing. However, zig also isn’t inherently insecure (though it doesn’t provide the same security guarantees) and coding in it just seems so much more pleasant. To me, the language makes more sense, which is also something I like about Go. Even manual memory allocation looks well-designed. At no point did I look at zig and thought “oh, that’s an odd choice”.
The language isn’t frozen yet though, so everything you write in it may require changes later on, so I wouldn’t recommend it for anything in production. Notably, there’s no built-in async or something comparable. If you’re fine with these limitations, go ahead and try it out, and if you feel like it, maybe even rewrite an existing tool in it.
ncdufor example is such a tool where the original author rewrote it in zig for version 2.
That’s right. We need to rewrite it in a REAL language like java.
I think you forgot the -Script.
COBOL or GTFO
FORTRAN my man
Basically just “but two languages is HARD”
It is hard when you mix them in one codebase and need bindings and wrappers for interoperability. This always introduces additional work and maintenance burden. It’s always a tradeoff and for most projects not worth the effort. Tech corporations that do this regularly have dedicated teams to deal with boilerplate bullshit and tooling issues, so that regular devs can just code with minimal friction. Rust-in-Linux community decided to take it upon themselves, but I’m not sure if they can keep it up for years and decades in the future.
Though gradually getting of C is still a good idea. Millions of lines of C code is a nightmare codebase.
Yeah, even Linus said he wasn’t 100% sure it was gonna succeed but how else do you know unless you try it.
I’d even have sympathy for this argument that introducing another language is a major undertaking (and it is!) but Linux is already full of lots of other languages (Macros, Makefile, Shell, BPF, assembly languages, Perl, Python scripts…) and developers are willing to do the work to use a language that helps solve problems Linux cares about.
That’s not a good argument. Most of these additional languages are used for separate things, like build scripts and stuff. They don’t affect actual kernel code which is C and assembler language.
And? The GNU General Public License and every project that uses it (including Linux) have also been likened to cancer, as have many other things that impose and spread their conventions/restrictions/requirements when added to larger systems.
The phrase “going viral” works similarly. These metaphors may not be pretty, but they are not uncommon or inaccurate, either. Stirring up drama around their use doesn’t help the project or the community.
