Subj : Re: macOS 26 To : Nightfox From : tenser Date : Thu Dec 04 2025 11:14 am On 03 Dec 2025 at 11:13a, Nightfox pondered and said... Ni> Re: Re: macOS 26 Ni> By: tenser to Nightfox on Thu Dec 04 2025 07:20 am Ni> Ni> te> Rust is, frankly, a better language than either C or C++, but with go Ni> te> reason: it had 35 years of C and 30 years of C++ history to learn fro Ni> te> when it was designed. Plus it could also draw on lessons learned fro Ni> te> research in the wider PL community over those decades. But it's easy Ni> te> do better when you've got so much data you can learn from. Ni> Ni> I don't doubt Rust is a good language. I have yet to try it myself; Ni> that's mainly because I haven't worked on a project that uses Rust, and Ni> I haven't really looked into using it for one of my own projects. Ni> Ni> At the same time, sometimes I'm not sure about a programming language Ni> forcing certain rules & paradigms, etc.. All programming languages force rules, paradigms, idioms, etc, on programmers. Even assembly languages do this. C, for example, has some very abstruse rules for the promotion of integers of various types to other types; these can often surprise people who aren't used to them. For example, pop quiz: uint16_t mul(uint16_t a, uint16_t b) { return a * b; } Is this little function portable and well-defined? Ni> C and C++ let you do pretty Ni> much anything, and IMO that's not necessarily a bad thing. Well, except that they kinda sorta really don't. I mean, on some level they're all Turing-complete; in the limit I can write a Rust interpreter in C, but that's not a particularly useful thing in the context of workaday programming. But on a more practical level I cannot, for example, directly manipulate the frame pointer in C code; I need to jump to assembly for that (whether inline or some other way). But what people tend to mean when they say such things is that, in C, they're programming at a very low level, and can thus manipulate the state of the machine in a much more direct way than in, say, Python or Java. But that's ALSO not really true, because 9 times out of 10, programs that do that kind of thing need to rely on some sort of externally defined standard (e.g., an ABI like the SVR4 one to define the size and alignment requirements of primitive types, and define the details of structure layout and function calling conventions). And when doing so, one has to be _really_ careful to avoid the dreaded, "Undefined Behavior". I've seen C programs that have "worked" for decades suddenly break when a compiler got a point revision, because it turned out the program relied on the compiler behaving a certain way for UB, and all of a sudden the compiler started treating that differently. A lot of programs that people think are "correct" are really only correct on accident because older compilers had relatively sensible behavior for things like signed integer overflow, aliasing, and so on. I've written a couple of kernels in Rust (and of course some assembly code) and the bits of C that make it usable to manipulate low-level state are _also_ available in Rust. *Plus* I get goodies like iterators, sum types, type-safe IO, bounds-checked slices, pattern matching, parametric polymorphism, closures, sensible scoping rules, explicit type conversions (with error checking!), language-level support for error checking via the Result monad and `?` operator, traits, built-in support for unit testing, and so on, that I just don't get in C. The canonical build system even supports a robust library ecosystem. Some of these I can get in C++, but not all; it's like the Rust designers sat down and said, "gee, what would it look like if we designed a language that fixed the major problems in C++ that we've observed over the last 20 years?" :-D Ni> Just be Ni> careful not to do stuff that will cause bugs. :) I know, there's always Ni> human error, and everyone will eventually make mistakes, so I suppose Ni> it's good if the language can help avoid that. That's really the thing. 50 years of experience have shown that our best and brightest programmers write buggy C and C++ code. "Just write correct code" simply doesn't work, even for some really brilliant people. The best engineers know that the most robust artifacts come from using many approaches to improving quality: better languages, better practices, better tools, etc. These are not training wheels on a kids' bike, they're chain guards for power tools. Ni> Sometimes I'm torn Ni> between that and the adage that "it's a poor craftsman who blames his Ni> tools". There's the old joke that a person goes to see a doctor and Ni> says, "My arm hurts when I move it like this," and the doctor says, Ni> "Then don't move it like that." Ah, but the skilled craftsman also carefully curates, maintains, and selects the tools for the job at hand. It is the poor craftsman who reaches for a hammer when a screwdriver is called for. The experienced craftsman is always looking for newer, better tools, and understands that often the safer tool yields the better finished product: the bespoke jig for moving the large panel across the saw allows the craftsman to concentrate on the cut itself, because the piece is secured and won't kick-back, as it is not being forced through at an angle. Similarly, the plane iron is kept sharpened and clean, and the sole waxed and square. Not only is this safer, the resulting work is higher quality. I don't, generally, remove the guard from my chainsaw, even though I try to be very careful when I use it. Why should I treat the tools that I program with differently? Ni> te> These conspiracy-theories about control, evangelism, attacks on softw Ni> te> freedom, etc, are just uninformed nonsense. Ni> Ni> Honestly this thread is the first time I've heard about any conspiracy Ni> theories about control on software freedom due to evangelism of a Ni> programming langauge.. The Rust-in-Linux people have faced a lot of resistance from a number of long-time developers who are resistant to moving away from C; most of that is FUD. But it gives fuel to a number of ankle-biters swirling around the Linux community make these sorts of wild claims, but they don't tend to produce a lot of software: no one takes those people seriously. Similarly, Rust does have a problem with too many fanbois who blame _all_ software problems on failure to write everything in Rust. Those folks _also_ don't tend to write a lot of software, and again, no one takes them seriously. But their behavior tends to interact with the Linux peanut gallery types to create a pretty toxic mix, and amps them all up. The result is a lot of noise and heat, and almost no code, but everyone else has to wade through this ridiculous and unnecessary cesspool. Torvalds seems pretty bullish about Rust in the Linux kernel, though, so we'll see where it lands up; OTOH, the maintainers keep burning out and quiting because of the FUD and the crazy nonsense. --- Mystic BBS v1.12 A48 (Linux/64) * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101) .