ken-yshl.jpg

@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.jpg

Public

Notices where this attachment appears