Recent searches
Search options
Administered by:
@pancake To me this looks more like a community feud over the project direction than a statement about Rust. I feel *any* big change that effects several sub systems will run into exactly the same problem,
I should point out that knowing C gives you a huge head start on learning Rust. It's different, but you can see an underlying C-ness to it.
Most notably, references are really just pointers except the compiler can check whether they're still valid at any given point in the program. If you're a C programmer, you were already doing that pointer validity checking in your head, so this'll be far more familiar to you than to a JavaScript/Python/etc programmer.
@argv_minus_one @hunger @pancake
even when you're 60 years old?
@wolf480pl @argv_minus_one @pancake The question is how a project can stay relevant, when catering to the old guys only. You need an influx of young people, and they tend to not do C too much anymore.
I'm in my 40s and I don't do C any more either.
C has a metric crapton of cases of undefined behavior, and although you could get away with a lot of shenanigans when I was young and compilers were dumb, they *will* blow up in your face if you try them with a modern optimizing compiler.
Fun fact: signed integer overflow is UB in C, and yes, modern compilers *will* optimize based on the assumption that signed integer arithmetic will never overflow. If it does, 
.
@argv_minus_one @hunger @pancake
(unless you use -fwrapv / -ftrapv, IIRC kernel uses one of those by default, but yeah it's extra effort to make it not a foot-nuke)
Yep. As far as I know, no language other than C and C++ has this many ridiculously obscure ways to cause UB.
Most languages, including but by no means limited to Rust, try pretty hard to not give you any way to cause UB without some sort of incantation. Java made a big deal of “no UB” back in the '90s.
Rust's innovation, rather, was “no UB” while still using pointers and still letting you control memory management (stack, heap, reference counting, etc).
@argv_minus_one @wolf480pl @hunger imho the weak points or rust are:
- complex language
- moving and evolving target
- only one compiler exists
- heavy cpu and memory requirements
- added tech debt as custom wraps need to be handcrafted all the time
Gccrs is unfinished but i want to assume it solves some of these problems, what about the others? im trying to be constructive and not get into a flame. Im not a rust or a kernel dev, despite i wrote drivers, kernel patches and wrote some rust too, so im probably not seeing the whole picture.
PD: I would love this thread can become into a constructive discussion.
@pancake @argv_minus_one @wolf480pl where do you see heavy CPU costs? Is that for compilation?
I also do not see "one compiler" as a problem at all. In fact I thing an RFC based process based on implementing a feature in the compiler everybody uses wins flat out over design by committee languages.
@hunger @pancake @argv_minus_one
Until you have a second compiler implementation, you can't know if the spec is sufficiently specific.
Unless you're arguing for not having an authoritative spec and having an authoritative implementation instead?
A formal Rust spec doesn't exist at all right now. The closest we have right now is the Rust Reference, which has a warning on its front page that it is not normative. https://doc.rust-lang.org/reference/index.html
To what extent this is a substantial weakness of the language, I'm not sure.
To be fair, Linux is not standard C and relies heavily on GCC extensions that also don't have a formal spec. So, if having only one compiler is a problem, then Linux already has that problem.
@argv_minus_one@mastodon.sdf.org @wolf480pl@mstdn.io @hunger@fosstodon.org @pancake@infosec.exchange Except Linux can be compiled under LLVM/Clang. No idea the exact steps you need to take (always done it with gcc) but ChromeOS ships builds under LLVM/Clang. (And presumably any patches they use are going to be available under ChromiumOS)
@argv_minus_one@mastodon.sdf.org @wolf480pl@mstdn.io @hunger@fosstodon.org @pancake@infosec.exchange Also if I remember correctly - the Linux kernel is using https://github.com/Rust-GCC/gccrs (because they primarily use gcc). gccrs is still a WIP but it’s not the same as rust’s compiler (because that’s built on LLVM which is clang’s backend)
@argv_minus_one@mastodon.sdf.org @wolf480pl@mstdn.io @hunger@fosstodon.org @pancake@infosec.exchange which is kind of funny actually because I just said "well linux can compile under clang/llvm" and then here we are where Linux is adopting a gcc frontend for rust instead of relying on rustc
Wait what? The Linux docs say it's using the regular LLVM-based Rust compiler: https://docs.kernel.org/rust/quick-start.html
@argv_minus_one@mastodon.sdf.org @pancake@infosec.exchange @wolf480pl@mstdn.io @hunger@fosstodon.org huh?? I could have sworn. Seems like the intended goal for gccrs is to replace rustc. Sorry.
For building Linux, you mean? I don't know whether that's the case, but I wouldn't be surprised. LLVM is missing some of the targets that Linux supports, so Linux people are probably going to want to use a Rust compiler that uses GCC as a backend (either rustc_codegen_gcc or gcc-rs) once it's sufficiently mature.
As of this moment, though, they're using the LLVM-based rustc, according to their documentation.
@argv_minus_one @puppygirlhornypost2 @pancake @wolf480pl I keep hearing that gcc supports more targets than LLVM, and I do notmdoubt that. But can you name one such target that is still relevant outside of a historical context.
Anything that has vague community or commercial backing has a LLVM target by now.
@hunger @argv_minus_one @puppygirlhornypost2 @pancake
m68k seems to be still in use in some embedded systems and getting fixes for those:
https://github.com/torvalds/linux/commit/a0a8306c823986c43ea58be13e8b366999a93cb2
Also, there's c-sky which is a pretty new architecture.
LLVM seems to have backends for those two in some shape or form, but not enough to build Linux for those architectures with clang:
https://docs.kernel.org/kbuild/llvm.html
@wolf480pl @argv_minus_one @puppygirlhornypost2 @pancake Wikipedia lists the Motorola 68000 as discontinued in 1996. I would firmly count that into the historical context. Wikipedia has nothing on C sky... does not look like a major player.
Are these seriously the two architectures we absolutely need gcc for?
@hunger @argv_minus_one @puppygirlhornypost2 @pancake
No.
These are *a* two architectures.
There's also SuperH, DEC Alpha, PARISC, OpenRISC, MicroBlaze, Xtensa, ARC, NIOS II.
I do not know which of those are still being used in some embedded systems. The kernel maintainers for those architectures probably know, you'd have to ask them.
Motorola 68k is still alive: https://en.wikipedia.org/wiki/NXP_ColdFire
You can buy those chips today:
https://eu.mouser.com/ProductDetail/NXP-Semiconductors/MCF54416CMJ250?qs=6NAriTSiIYtaMvUvjjtOUg%3D%3D
@wolf480pl @argv_minus_one @puppygirlhornypost2 @pancake So basically architectures that can not effort to have support in LLVM because either the commercial interest by its vendors is too small or there is no more vendor.
So nothing you can build on in earnest todays... just historical interest.
@hunger @argv_minus_one @puppygirlhornypost2 @pancake
I'm pretty sure there is work on adding supoport for half of those to LLVM.
Also, by your logic, NVidia is of historical interest.
@hunger @argv_minus_one @puppygirlhornypost2 @pancake
Anyway, what are you proposing to do with architectures of "historical interest"?
@wolf480pl@mstdn.io @hunger@fosstodon.org They'll get dropped by the kernel if the maintenance burden becomes too high to bear and nobody steps in. They've already dropped a bunch of really old ARM chips, for example.
In fact, the main reason the M68k port of LLVM exists is because GCC threatened to remove its own M68k port!
@wolf480pl@mstdn.io @hunger@fosstodon.org There are many reasons to feel concerned about a new language being added to the kernel, but "think of these legacy architectures nobody uses in production!" really ain't it. There's NetBSD for enthusiasts of those.
@wolf480pl@mstdn.io @hunger@fosstodon.org And keeps the kernel up to date, so that they would not be satisfied with an LTS?
@asie
apparently enough to keep the arch maintained in upstream kernel?
Anyway
> They'll get dropped by the kernel if the maintenance burden becomes too high to bear and nobody steps in.
This is what's already happening, so if this is what @hunger proposes we're arguing about nothing, and Rust doesn't get to be used in core kernel subsystems until it supports those architectures.
@hunger @argv_minus_one @puppygirlhornypost2 @pancake
Also, your logic is circular:
you want me to show you an architecture not supported by LLVM that is not "only of historical interest" while you define "only of historical interest" as "the vendor hasn't added LLVM support".
So you're asking for an architecture not supported by LLVM that isn't not supported by LLVM.
@wolf480pl @argv_minus_one @puppygirlhornypost2 @pancake Anything out of production is by definition a historical interest. Anything not used widely enough to show up on Wikipedia is also something I personally tend to ignore.
@hunger what makes you think ColdFire is out of production?
@wolf480pl Wikipedia lists it as in production, so its not of historical interest in my definition nor to unimportant to care:-) But I'd not consider it important enough to insist on gcc for that one, but other people will of course disagree:-)
Guess I need to stop claiming there is no target not of historical interest that is supported by gcc but not by llvm. Thanks for enlightening me.