Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.arch Subject: Re: Rust (was: Optimization by programmers) Date: Wed, 07 Oct 2026 05:41:23 -0700 Organization: A noiseless patient Spider Lines: 82 Message-ID: <86a4oplm30.fsf@linuxsc.com> References: <1177fdi$26ea4$1@dont-email.me> <119btc7$1n32h$1@dont-email.me> <86bj9hr91x.fsf@linuxsc.com> <20260928195833.00001d42@yahoo.com> <119j4g4$4kn$1@reader1.panix.com> <119jbt5$cn3a$1@dont-email.me> <86pkxtplou.fsf@linuxsc.com> <119otm8$2c89q$2@dont-email.me> <86ik3jo1js.fsf@linuxsc.com> <2026Oct3.131214@mips.complang.tuwien.ac.at> <861pa3m40z.fsf@linuxsc.com> <2026Oct6.172109@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 07 Oct 2026 12:41:24 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2988761"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19pyXjcrR+Qm6tMO4Z23egHmHFj2uy66XQ="; posting-host="f116a0ff36505fb6c1fca8f439768e04" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:8YXD6KJNK6cwxQd8JbAaJ6/bt1s= sha1:qKItP3DeNdUqxdVXxT1DUR40Gvc= sha256:Yc9CL4tamzWighINkAFJwE1ybZ70lRKFCnkn+SUq6hk= sha1:yvnrdMKBp43EaScHGxBxgmEd35s= sha256:4b1NDAikia5ztYzA257y+NELJwy6hAGA1weMkXfrahg= Xref: csiph.com comp.arch:118509 anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Tim Rentsch writes: > >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> >>> The reason was that I could not get a search-tree insertion technique >>> to work that can be implemented in e.g., Pascal, C, and Forth, but not >>> in Java (because in Java I cannot produce references to a field inside >>> an object). >>> >>> At some point I thought that one would have to use the more >>> heavy-weight reference-counting stuff to get through the borrow >>> checker. [discovered later not to be necessary] >> >> I think this test case is a good one. Somewhat disappointing that >> Rust makes it non-obvious. Do you know if what you learned would >> carry over to, for example, AVL trees? > > What I learned? No. I did not really learn it. I saw how I could > modify an example from the book to achieve what I want, and understood > the explanation of that example, but I do not know how to use this > stuff to build code from scratch. > > Whether it is possible to do AVL trees in safe Rust without resorting > to reference-counting and such? Maybe, but I guess there are too many > mutable references around in AVL tree operations at the same time. A simple search tree can do insertion only at the leaves. Other binary tree insertion methods typically modify interior nodes, and certainly AVL trees fall in this category. Except for the difference of leaf-node-only modification and interior-node modification, I don't see why they should be any different. Is there something about the Rust-safe code that you wrote that depends on modifying only leaf nodes? >>> Then I found the book "Learn Rust With Entirely Too Many Linked >>> Lists", and I found that the problem could be solved without reference >>> counting after all. >>> >>> Even after reading the second book, I am still disillusioned with >>> Rust. The Rust fans tend to say: "If it compiles, it runs." The >>> problem is that it can be harder to get a Rust program to compile than >>> to debug a program in, say, Forth (which has barely any checking). >>> For debugging, I at least have a method on how to proceed. When I get >>> an unhelpful compiler error, I am left to trying various things, >>> blindly. >> >> Can I ask how much experience you have with ML-style languages >> (e.g., ML, OCaml, Haskell)? I'm wondering how the type inference in >> Rust compares to the type inference done in those languages. > > A little with Miranda and Haskell (Hugs), and the latter is the reason > why I have this opinion of type inference: You get a long error > message that tells you that there is some inconsistency in the > inferred types; because the types are inferred from a significant > stretch of code, the problem could be anywhere in this code. > > My impression is that in Rust you tend to nail down things more often > than in Haskell, so the stretches are shorter, but there is more > automagic going on in Rust, with automatic defererencing and > referencing, automatic dropping, etc., and the borrow checker > interacts with the automagic, which makes it at least as hard to deal > with as th Haskell type inference. > > For Haskell I can at least make types explicit at various places to > reduce the area where the error might hide, but in Rust I have no way > to disable the automagic, and no way (or at least I don't know it) to > tell the borrow checker what I think it should be seeing, such that it > can tell me where my error is. > > I have investigated some tool that IIRC rewrite the Rust program to > give more information about how it understands the program, but at > least for my test case, it was not enlightening. > > As for the type system, a friend told me that he likes Rust because it > gives him what he likes about Haskell's type system in an imperative > language. Very interesting. Thank you for the long explanation. I am curious to know more but comp.arch is not the right place for that discussion so I will stop here (and perhaps continue in a better choice of forum).