131–140 of 184 posts
Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.
Earlier quoted context omitted.
I worked for a large infra project that was mostly written in C with the kind of trickery that is being here ascribed to QEMU code (I trust the parent, but I haven't seen the code myself). It's a common thing to do in projects like this in C. While C++ solves some of the problems for larger projects, it brings so many more, it's usually not worth it. Projects of this kind, essentially, invent their own language, with…
You can define your own "language", the way you describe it, in C++ more easily than you can in C. C++ gives you more powerful and expressive tools for doing so. A program is not improved by foregoing these tools. There's nothing in C++ forcing you to do anything that makes anything "harder".
Earlier quoted context omitted.
> I'm not a rust user but if it lets me use classes and templates, I'll switch over Yer not switching any time soon then. Rust does have methods but not classes (QOM’s inheritance is specifically called as an issue in TFA) and it uses Haskell-style generics rather than C++-style templates.
I don't think he literally means templates and classes. Rust has equivalents that do the things you want templates and classes for (generics and structs/traits respectively). I completely agree with his point about reimplementing C++ badly in C. GNOME does this too in their libraries. He will be much happier with Rust.
Earlier quoted context omitted.
> As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. Most toolchains don't have as much churn as Rust.
> Most toolchains don't have as much churn as Rust. What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code. Now compare rust releases to this: https://gcc.gnu.org/releases.html
Earlier quoted context omitted.
To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the…
> I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. What Debian has is not a "stranglehold" but an ideology, and Debian continues to matter to (some) upstream projects because lots of users identify with Debian's hyperconservative, noncommercial ideology. Your complaint is basically, "it's too bad that the userbase n…
> Your complaint is basically, "it's too bad that the userbase not sharing my values is large enough to matter".
Arch and rolling releases have about the same market share as Debian. Indeed, ironically, Debian's widespread adoption is seen primarily in the enterprise space where it's free as in beer nature and peer adoption is a signal it's a suitable free (as in beer) alternative to RedHat. Without Ubuntu's popularity a while back making Debian not so crazy an idea, I think "Debian" philosophy would not have anywhere near the adoption we see in commercial environments.
Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.
The goal of non-rolling release distros is to have a predefined set of dependencies, which the distro maintains and fixes if necessary. If Rust decides that it no longer supports compiling on x86, or if it starts depending on a version of LLM that no longer runs on a supported architecture, Debian must fix that for their users. That leaves the curl2bash installers that are popular with fast moving tools and languages…
Then you stop publishing new versions of the toolchain for x86 releases of the distro? I fail to see the problem. Nothing prevents you from not making a newer version of the toolchain available. Indeed, that's the default.
> The same goes for crates, which can be pulled at any time for almost any reason and break compiles.
I never said you have to extend this by making all versions of crates available. You can freeze the crates using the same mechanism to redirect Cargo as they do today.
I'm going to ignore the rustup stuff as I wasn't proposing rustup be used for building the base Debian image itself - that was a comment more about the environment QEMU itself can advocate for for people building it & leaving it to the distros to solve their own packaging problems.
Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.
I find it funny and sad at the same time that an installer for a "safe" programming language teaches people to download a shell script from a website and run it. What a farce.
Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.
Because QEMU wants their thing to be packaged in various distros. Those distros don't allow packages to bring their own tool chain (for good reasons).
Earlier quoted context omitted.
To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the…
> I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way. Does Debian have a stranglehold? AFAIK every other distro does the same thing, and all of them for good reasons.
Earlier quoted context omitted.
> I'm not a rust user but if it lets me use classes and templates, I'll switch over Yer not switching any time soon then. Rust does have methods but not classes (QOM’s inheritance is specifically called as an issue in TFA) and it uses Haskell-style generics rather than C++-style templates.
I don't think he literally means templates and classes. Rust has equivalents that do the things you want templates and classes for (generics and structs/traits respectively). I completely agree with his point about reimplementing C++ badly in C. GNOME does this too in their libraries. He will be much happier with Rust.