APL\360

On Tue, Feb 02, 2021 at 08:50:56PM -0700, ben via cctalk wrote: [...] (I assume you mean "30 years earlier" here.) Two reasons, one of which I was already aware of back then in 1991, and one which is only obvious in hindsight. The first is simple toxic masculinity. It's more manly to write stuff in machine code (then) or C (now), apparently. The second is a combination of Moore's Law and computer science. To handwave wildly, Rust is what you get when you look at C++'s mistakes of the last forty years and start again. If you've used a C++ compiler from the 1980s or early 1990s, you'll have found the experience harrowing: computers were still too slow and too small to do a good job, and various important language design and code-generation techniques were not yet known and/or were too impractical to implement. It all improved rapidly in the 1990s and 2000s, bringing us more or less to the top of the sigmoid curve. u32::overflowing_add() returns a (u32, bool), i.e. a two-member struct. Those early compilers cannot return structs directly, so the caller would have to reserve space (on the stack, probably) and pass the address for the function to fill in. That simple add-producing-carry has just become a function with a half-dozen instructions, several of which are needed to check the carry flag and convert it into a integer, plus many memory accesses, just to provide a C wrapper around a simple add instruction. At that point it does make sense to toss the compiler and write assembly language. Modern compilers do a lot of heavy inlining as a matter of course, will split structs and perform dataflow analysis on individual elements, and generally avoid memory access unless they absolutely have to. u32::overflowing_add() should turn into a single add instruction and the carry flag will probably be tested directly by a branch instruction and never get converted to a boolean variable. It'll be as good as if not better than hand-written assembler. This is a particularly trivial function as well. Rust just wouldn't be viable with 30 year old compiler technology. RISC-V doesn't have a carry flag. It handles overflow by e.g. using the BLT instruction to branch if the result is smaller than the number being added to. So documentation which assumes the world is x86 will not make sense here. [...] There's no real difference between a "constant ... when called into use" and a pure function which returns a value based on the structure elements. That is an implementation detail which you don't need to know to be able to write Rust code. However, the len() method actually just returns the element count from the (pointer, element count)-tuple. The function is so trivial that it is guaranteed to be inlined so it's exactly the same as if you had accessed the field directly. Before you ask, no, you can't access the field directly for all of the excellent reasons explained by every "introduction to OOP" tutorial which I don't need to repeat. [...] Runtime bounds-checking can get rather expensive -- it tends to add an extra compare-and-branch to tight inner loops and may also foil automatic vectorisation -- so it makes code much faster if the compiler can prove the check is unnecessary and eliminate it, or at least hoist it out of loops. An ordinary Rust programmer doesn't actually need to know any of this. They write code and it goes as fast as is safe. If it's not fast enough for them, they can ask an expert who knows this sort of intimate low-level detail and optimisation tricks to poke at their code, much as with any other language. What decades of toxic-masculinity C programmers have taught us is that they'll eliminate the bounds-check without proving it was unnecessary, assuming they ever bothered to perform the test in the first place, and ship code which will be trivially compromised. But it'll be really fast right up until your credit card details are leaked!