Conversation
Notices
-
Embed this notice
ins0mniak (ins0mniak@mikoshidata.cloud)'s status on Tuesday, 18-Mar-2025 02:11:49 JST 
ins0mniak
@TheMadPirate @david @phnt @p I don't think hes exactly wrong either lol
I haven't messed with it much but I just don't see the point of it lol- pistolero likes this.
- pistolero repeated this.
-
Embed this notice
Phantasm (phnt@fluffytail.org)'s status on Tuesday, 18-Mar-2025 02:11:48 JST 
Phantasm
@ins0mniak @david @TheMadPirate @p It's a great tool for some jobs that has been mostly misused and forced on by a cult. The syntax is a mess. And as always these C++ wannabe replacements somehow manage to be worse than C++. The syntax is a complete mess, because they wanted all the "good" features from the typical C-like languages while also adopting a lot from functional languages.
100-things-to-do-while-rust-compiles.jpg
i_do_not_care_for_rust.png✙ dcc :pedomustdie: :phear_slackware: and Another Linux Walt Alt like this. -
Embed this notice
Phantasm (phnt@fluffytail.org)'s status on Tuesday, 18-Mar-2025 02:13:25 JST
Phantasm
@ins0mniak @TheMadPirate @david @p
Write in C [1S1fISh-pag].webmpistolero likes this. -
Embed this notice
ins0mniak (ins0mniak@mikoshidata.cloud)'s status on Tuesday, 18-Mar-2025 02:21:43 JST
ins0mniak
@phnt @david @TheMadPirate @p Yeah that was the first thing I noticed. C++ is another language I almost universally ignore for that exact reason. I mess with it a bit on my nvidia dev board for the CUDA stuff but that's out of sheer necessity. -
Embed this notice
✙ dcc :pedomustdie: :phear_slackware: (dcc@annihilation.social)'s status on Tuesday, 18-Mar-2025 03:04:52 JST 
✙ dcc :pedomustdie: :phear_slackware:
@cjd @david @TheMadPirate @phnt @p @ins0mniak No more dommerisum sirs, rust will not win.
sam_doom.png -
Embed this notice
cjd (cjd@pkteerium.xyz)'s status on Tuesday, 18-Mar-2025 03:04:53 JST 
cjd
I spend 50% of my time writing C and 50% writing Rust.
Rust is gonna win.
What's gonna happen is someone will contribute some fast and loose memory management logic that breaks every single rule of safe design, but, uses a pile of Rust type system shenanigans to make the compiler (eventually) prove it correct... And for an extra 5% page fault performance, no one's gonna care that they need rustc to compile the kernel.
After that it's all a big downhill slide...
Hopefully someone will make the compiler faster though.Johnny Peligro and BSD/r000t repeated this. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Mar-2025 03:49:21 JST 
pistolero
@cjd @phnt @david @TheMadPirate @ins0mniak This has already been posted in this thread but this is the thing that sums it up.
i_do_not_care_for_rust.png -
Embed this notice
Phantasm (phnt@fluffytail.org)'s status on Tuesday, 18-Mar-2025 03:51:43 JST
Phantasm
@cjd @david @TheMadPirate @p @ins0mniak There's no point in "winning" a "language war". C is here to stay no matter how many people complain about it. It's the COBOL of the modern age.
You won't see Rust is embedded, because the binaries are huge and you'll probably never see Rust when writing embedded micro-controller stuff, because the things you do there are almost always inherently memory unsafe.
Where Rust will probably "win" is applications at the complete end of the chain. And maybe system runtime libraries, but it probably won't go deeper than that.pistolero and Johnny Peligro like this. -
Embed this notice
Johnny Peligro (mischievoustomato@tsundere.love)'s status on Tuesday, 18-Mar-2025 03:54:45 JST
Johnny Peligro
@phnt @david @TheMadPirate @p @ins0mniak @cjd i was telling this to a friend, c will stay for many reasons, and that's ok, rust will also keep progressing and is already usable thankfully -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Mar-2025 04:23:17 JST
pistolero
@phnt @cjd @TheMadPirate @david @ins0mniak
> It's the COBOL of the modern age.
A better analogue is probably Fortran. C fits in places that other languages cannot, it's got a lot of uses, and it's more or less a lingua franca. COBOL lived forever not because it was the best tool for the job, but because managers and government loved it and it gained a lot of inertia; Java or Perl would be more like a modern COBOL.
> Where Rust will probably "win" is applications at the complete end of the chain. And maybe system runtime libraries, but it probably won't go deeper than that.
There's only one compiler, it's LLVM-based, and this kind of dooms it to live inside a small ecosystem. When there's more than one implementation, then there's maybe a chance that it goes somewhere. C, Fortran, Python, Ruby, even hairy languages like C++ and Common Lisp have a lot of implementations.
There probably could be another implementation (and if it were done in Rust, that would free it from its own ecosystem and people could add better support for cross-compilation and new targets) but I don't think most Rust coders are interested in following St. Terry's advice. :terrywow:
> There's no point in "winning" a "language war".
Yeah. I think the Rust Evangelism Strike Force has that kind of mindset, though: annexation instead of expansion. -
Embed this notice
Phantasm (phnt@fluffytail.org)'s status on Tuesday, 18-Mar-2025 05:28:52 JST
Phantasm
@cjd @david @TheMadPirate @p @ins0mniak
What do you mean by embedded?
IoT. The fact that OpenWRT ships python in a system made to fit in a few megabytes already doesn't bode that well. And for the kernel, I don't see it seeping beyond the driver interface. The core functionality of the kernel needs to run on systems that Rust doesn't officialy support even though it's LLVM. Not to mention that hardware vendors writing drivers for their SoCs in Rust is probably only someone's dream right now. Fun fact: Rust is already sort of mandatory to build kernels, because CONFIG_PCI always builds Rust bindings.
What's important is that ABI-wise, Rust is basically C
Rust is NOT C. You can't link a Rust binary to a C binary without specifically defining the interface in Rust. C has no idea about the gillion of types that Rust has and never will.
Side note:
I also hate that this shitpost of a thread has turned into a Rust discussion thread, like they always do when anything is even slightly programming related and barely technical. It's the loli question of the computer world. And I already hate it.
Haelwenn /элвэн/ :triskell: and pistolero like this. -
Embed this notice
cjd (cjd@pkteerium.xyz)'s status on Tuesday, 18-Mar-2025 05:28:53 JST
cjd
I agree with you about the COBOL thing, though a big question is what will happen when AI progresses a little more.
> You won't see Rust is embedded
What do you mean by embedded? OpenWRT? It's there because of the python-cryptography dependency. In the kernel, it's optional for now, but as soon as someone starts upstreaming some faster versions of things, it's going to become defacto mandatory.
If you're talking about like 8 bit microcontrollers, sure, but that type of thing doesn't really have much of a future either. Nobody wants to run some special circuit with a vendor SDK based on a patched gcc when they can just use a slightly more complex RISCV circuit and standard tooling.
> almost always inherently memory unsafe
Same argument could be made about the Linux kernel, but it's not, because when everything is dangerous you care even more about tools to help prove correctness.
What's important is that ABI-wise, Rust is basically C. You don't have a VM or a GC or anything sneaking around behind your back and touching things you can't touch, so low level is actually possible. -
Embed this notice
Phantasm (phnt@fluffytail.org)'s status on Tuesday, 18-Mar-2025 05:38:00 JST
Phantasm
@p @david @TheMadPirate @ins0mniak @cjd
>When there's more than one implementation, then there's maybe a chance that it goes somewhere.
There's the gcc frontend for it, but the core Rust devs are somewhat hostile about it. They want one compiler probably because they like to move fast and introduce changes to the language, which would be impossible when two compilers would coexist. The shared "spec" the two compilers understand would then become the de facto standard for some time.pistolero likes this. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Mar-2025 09:00:38 JST
pistolero
@phnt @TheMadPirate @cjd @david @ins0mniak
> There's the gcc frontend for it
Ah, nice!
> but the core Rust devs are somewhat hostile about it.
Shouldn't be surprised, I guess.
> because they like to move fast and introduce changes to the language,
Yeah, it's got that disease where last week's code doesn't work this week.
> The shared "spec" the two compilers understand would then become the de facto standard for some time.
Or maybe a "Python 2" situation develops. Nice thing about Go is there's a test suite and it's all named after issues in the tracker. (Downside is Google owns the tracker, but Google owns Mozilla too.)Phantasm likes this. -
Embed this notice
ins0mniak (ins0mniak@mikoshidata.cloud)'s status on Tuesday, 18-Mar-2025 09:09:24 JST
ins0mniak
@p @david @TheMadPirate @phnt @cjd pistolero likes this. -
Embed this notice
RedTechEngineer (redtechengineer@fedi.lowpassfilter.link)'s status on Tuesday, 18-Mar-2025 09:09:29 JST 
RedTechEngineer
@p @david @TheMadPirate @phnt @ins0mniak @cjd if you have an issue with rust, you should submit it on the official Discord server! 😀 pistolero likes this. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Mar-2025 09:09:52 JST
pistolero
@RedTechEngineer @TheMadPirate @cjd @david @ins0mniak @phnt I can't, I'll get CoC-slapped. :cume: -
Embed this notice
cjd (cjd@pkteerium.xyz)'s status on Wednesday, 19-Mar-2025 02:22:13 JST
cjd
> Yeah, it's got that disease where last week's code doesn't work this week.
That's called idiots using the nightly compiler because Consume Feature And Get Excited For Next Feature.
My oldest Rust code is from 2021 and I do get deprecation warnings on some feature used in some library I forked, but I've never had to change Rust code because of a compiler upgrade.
The situation in C is actually somewhat worse, because every new version the GCC developers roll out some clever new warning. Normally this shouldn't matter, but in reality -Werror does trickle into codebases and then GCC makes an update and code stops compiling.
The other thing GCC devs like to do is invent clever new optimizations which turn undefined behavior that works into undefined behavior that crashes. Insert obligatory smuggy_just_write_valid_c.png, but since All Non-Trivial Code Has Bugs, this does end up being a language change (also, people with bosses and deadlines HATE smuggy_just_write_valid_c.png).
Anyway, I'm not really a language-warrior, I've invested a lot of time in learning Rust so I'm definitely talking my book, but really what I'm trying to say is I think Rust will continue to grow and C will not.pistolero likes this. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 19-Mar-2025 02:22:36 JST
pistolero
@cjd @phnt @david @TheMadPirate @ins0mniak
> That's called idiots using the nightly compiler because Consume Feature And Get Excited For Next Feature.
All of the C and Ruby and Perl and Go and Bourne shell and Forth code that I wrote years ago still works but cargo shits itself if I try to update librsvg and I get to chase dependencies. An unstable library sucks, but you rewrite one file and use a different library.
An unstable language or OS is a completely different matter: you get that far down the stack and whimsy becomes inexcusable. It's a mistake to push Rust until it's stable, and it's not stable but there are a lot of people pushing it. That's a transient thing, it could change tomorrow, but it's got to stabilize in order to be taken seriously.
If it works for you, go for it, have fun, hack. I hate both the language and the ecosystem.
> I've never had to change Rust code because of a compiler upgrade.
I don't even write Rust and I have to chase this shit down. Now that most of these projects have stopped using libboost, a development dependency on rustc is the thing that is a sign I'm going to have to spend a couple of hours coercing it into building.
> The situation in C is actually somewhat worse, because every new version the GCC developers roll out some clever new warning. Normally this shouldn't matter, but in reality -Werror does trickle into codebases and then GCC makes an update and code stops compiling.
"Some projects make a mistake that you can fix with sed" is a very different thing from "Maybe if I spend a couple of hours building the last release of this compiler, then another couple of hours rebuilding the project, it'll work this time".
So, I did say I don't write Rust but I did send a patch upstream for some firmware; it was a trivial change, two minutes to write, but hours to juggle versions to get the tooling to stop balking. This is a little different from altering the flags passed to gcc. `grep -r Werror` is really easy to type and runs as fast as your disk and doesn't take 30GB of memory. (Of course, nobody has this problem if they use Ken's C compiler. We should just use Ken's C compiler. Ken doesn't even work on it any more and it *still* got RISC-V support years before LLVM. Sadly, we do not live in that world, so I will put it back in my pants.)
I nearly ditched Firefox over the compiler version shenanigans (but I nearly ditch Firefox every week because since they adopted Chrome's release schedule, they fuck something up every week; from 2.0 through 3.6, every release fucked something up but the release schedule was at least slower).
> The other thing GCC devs like to do is invent clever new optimizations which turn undefined behavior that works into undefined behavior that crashes.
gcc sucks, sure. clang sucks worse than that, rustc sucks worse than that. C is a nicer language.
> Insert obligatory smuggy_just_write_valid_c.png,
No, that's a valid problem. Even dmr didn't like the standard. My smug is a completely different flavor; see attached. The UB fetishists are worse than the language evangelists, and if one more of them tries to use the "THE COMPILER COULD DO ANYTHING, IT COULD REFORMAT YOUR HARD DRIVE" then I will make them find me a one's complement machine so I can bludgeon them with the punchcard reader for it. "Undefined behavior" is just "we're leaving this up to the compiler writers" and some neurotics took a punitive approach to portability. Nothing for it. Integer overflow is left as undefined behavior, and that's fine: there is no way to make it work the same way on different machines without seriously complicating the machine code for basic math, so it's left undefined.
> but really what I'm trying to say is I think Rust will continue to grow and C will not.
C has a lot less trouble with weird operating systems and weird CPUs, because it is a very simple language. I don't know what you mean by "grow", as you can't go past 100%.
I have this big-ass distcc cluster, and I have had to ensure that all of the participants in it have the same version of gcc, but after that happens, it all works seamlessly. So I kick off a build job on my little ARM DevTerm and all the other machines on the network participate and I had trouble finding something that would build slowly. (A lazy enough guy--and I am that guy--can even use the qemu-binfmt trick and a chroot plus just shoving enough of the x86-64 userspace to run qemu-aarch64 into the chroot, and add the x86-64 machines to the cluster. I had to do this to get Firefox to build because at the time, I didn't have enough RAM in the ARM systems to make that work.) That's one tool, and it's one tool that would be really convenient for rustc (because rustc is extremely heavy) but there's not a Rust equivalent as far as I know; consider the amount of tooling Rust would need just to catch up.
Ultimately, I have trouble taking Rust seriously. It doesn't give me anything I want, no one answers the "Why care?" question with a real answer, just some vague hand-waves about memory safety. The overwhelming majority of languages are memory-safe: touting a common feature as novel is a marketing tactic, not an argument. I think there are people that actually believe the "Java won because of marketing" explanation and I think they are trying to engage in that same tactic with Rust and I don't like it: they incorrectly perceive that a scummy thing happened and have decided to be scummy because they want to win more than they want a good language. I don't like them harassing people to swap out working code for a Rust rewrite: it feels like a whiny demand to be included. I don't think you're doing those things but the members of the RESF are.
But the language doesn't bother me because I can ignore it until I have to recompile Firefox or Inkscape or someone gets evangelistic. Like I said, you write it, sure, have fun, but I do not care for it, for plenty of reasons (some listed here, some listed in that textwall image that has now been posted in this thread twice), some of which can be fixed, some of which can only be fixed in theory (that is, it would be technically possible but it will never be done for philosophical or social reasons), and some of which can't be fixed. So I expect that another ten years and the best-case scenario is it's another Java. That kind of niche: people can get jobs writing it, people still learn it, but there are plenty of people (I am one) that can get by just fine by only occasionally interacting with it in passing.
ken-yshl.jpgPhantasm likes this. -
Embed this notice
dobó istván (istvan@noauthority.social)'s status on Wednesday, 19-Mar-2025 03:16:54 JST 
dobó istván
>> ./configure
>> Checking libboost >= fuckyouYou know you are in for a fun afternoon. @p @david @TheMadPirate @phnt @ins0mniak @cjd
-
Embed this notice
Phantasm (phnt@fluffytail.org)'s status on Wednesday, 19-Mar-2025 03:17:26 JST
Phantasm
@istvan @p @david @TheMadPirate @ins0mniak @cjd pre-processor DoS: Brought to you by libboost Haelwenn /элвэн/ :triskell: and pistolero like this. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 19-Mar-2025 09:08:09 JST
pistolero
@istvan @david @TheMadPirate @phnt @ins0mniak @cjd
> You know you are in for a fun afternoon.
A C++ program that cares the gcc version is also nearly guaranteed to cost you an afternoon.✙ dcc :pedomustdie: :phear_slackware: and Phantasm like this. -
Embed this notice
david [blobcat] (david@blob.cat)'s status on Wednesday, 19-Mar-2025 09:08:31 JST ![david [blobcat]](https://gnusocial.jp/avatar/274443-48-20240803010127.webp)
david [blobcat]
@istvan @p @TheMadPirate @phnt @ins0mniak @cjd terminal says fuckyou and fuckurmother pistolero likes this. -
Embed this notice
pistolero (p@fsebugoutzone.org)'s status on Wednesday, 19-Mar-2025 10:05:50 JST
pistolero
@cjd @david @TheMadPirate @phnt @ins0mniak
> I take it you have your own distro (?)
I just use CRUX almost everywhere (I have a couple of Slackware systems kicking around). It is mostly source-based, and it's small enough that you can roll your own rootfs pretty easily. Anyone running a source-based distro is a canary in the coal mine.
There was, years ago, an expectation that a coder understood his OS; at some point sysadmins stopped being able to code and this was untenable so now it's called "devops".
> There's an age-old struggle between devs and distro packagers.
I'm familiar. If I were extremely happy with how distro packagers operate, I wouldn't be using a distro where packages are just tarballs.
You run into shit like "$package won't build without Boost $newversion and $otherlib $someversion. But version $someversion of $otherlib won't build without Boost $oldversion." And the most effective way to figure out what you need to do is to find the release date of the package (and a distressing number of projects cover the front page with marketing material and make it hard to find the source code), find out what Ubuntu was doing that day, and then try those versions of the dependencies. These people have not written their software for Unix or even for Linux, they have written it for Ubuntu version $x and no sooner or later: it is so brittle that if someone working on one of those projects says anything about "portability", it's hard not to laugh. It's not even portable to the same OS/arch from six months ago, and six months from now it won't build any more.
> IMO Rust doesn't really replace Java
I mean that I can see it occupying an analogous niche. There are Java programmers, there will be Java programmers for a long time, there are a few projects that are written in Java that end up being relevant even to people that avoid Java, like I've had to work with ElasticSearch and neo4j and Solr, and whatever you're working on, you'll occasionally bump into Java. For the duration of the career of anyone in the industry today, specializing in Java is possible. I think it's possible that Rust gets to that level; I don't think it's the likely case. C++ isn't going anywhere.
The last time I had to update rustc, I had to uninstall rustc: it wouldn't build with an older version of itself *present* on the system, because it couldn't cope with how cargo worked. (These are, again, releases, not snapshots.) Movefastbreakthings was abandoned even by webshits: stability precedes adoption.
> Rust more replaces C++ than anything IMO.
Yeah, for platforms where it runs, at any rate. I wouldn't hate for a thing to replace C++; I never liked C++. On the other hand, I think the best replacement for C++ is C. Your mileage may vary.Haelwenn /элвэн/ :triskell: and Phantasm like this. -
Embed this notice
cjd (cjd@pkteerium.xyz)'s status on Wednesday, 19-Mar-2025 10:05:52 JST
cjd
I take it you have your own distro (?)
There's an age-old struggle between devs and distro packagers. Devs want nice tools to make their lives easy, understandably. Packagers want everything to be the same to make their lives easy, also understandable.
IMO Rust doesn't really replace Java, Go does - and by that I mean it's an approachable language for problems where you're ok with having a GC running in the background. I'm NOT saying that Go has Java's problems, because it really doesn't, it's a pretty nice language overall.
Rust more replaces C++ than anything IMO.
By "grow" I mean new projects emerging that are written in it.pistolero likes this.
All GNU social JP content and data are available under the 
