Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #16940

Re: Rust (was: Optimization by programmers)

Cross-posted to 2 groups.

Show key headers only | View raw

In article <2026Oct11.174012@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <2026Oct10.161800@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[Anton Ertl:]
>>I do not know what you are referring to when you write, the
>>"fact that you did not find it"; did you not notice that I gave
>>you _two_ programs, one of which was pretty much the same as the
>>C program you gave?  What, exactly, are you referring to?
>
>I was referring to your safe Rust solution.  However, I did not look
>at it closely enough, especially at your insert, to realize that what
>you had done is to turn search into lookup, and that you do not call
>search from insert, like the C version does.

Clearly.

Forgive my saying it, but bluntly, this calls into question your
entire reading of my post.

>I just saw that there is a similar match in your insert as in search
>(and the non-recursive Java version would also have that) and set out
>to refine an existing linked-list implementation with insertion at the
>end into a tree insertion that does not repeat the match, and I used
>your match code from search for the parts that the linked-list
>implementation does not do.
>
>The list variant has the walk to the end separated from the actual
>insertion, and the C tree variant also does it that way, and I wanted
>the Rust version to do the same, but could not get it past the Rust
>compiler.  The insertion code did not look particularly nice, either,
>checking for something that is alreadu known in the search code.  so
>to work around the compiler problem, I eventually decided to inline
>the search code into insert, and I could get that to compile.
>
>For testing I then added a lookup, which was derived from the search
>part of insert, without mut stuff, so it's full circle back at your
>search.
>
>Anyway, yes, your insert does not work the Java version, but like the
>C version with search() inlined into insert(), and like the insert I
>finally arrived at.

Yes.  I take it that here, you are describing the process by
which you arrived at the program you posted in your response to
me.

>Which leads to the question?  Can an experienced Rust programmer do a
>search that works like the C search(), and an insert that calls
>search() and then uses the reference to either update a node or insert
>a new one?

Given that you did not read the first program in my post
carefully, I wonder whether you read the _second_ program in my
post carefully, or rather, closed over it like the first.  I
suggest having a look at that.

>>>Like your code and Java code, this has a separate type Tree with a
>>>field root and with its own new function, while in C a "struct tree *"
>>>variable can serve as root pointer; and this leads to an additional
>>>line each in insert and lookup.  Can we do without most of that
>>>(havibf a constructor is useful) and just use Subtree instead of Tree?
>>
>>Sure.  I do not think it is an interesting exercise, though.
>
>I tried it for a while, and did not get anything but more and more
>compiler errors.

*shrug* Is it useful as anything other than an academic
exercise?

>>>The integration of search in insert led to a duplication of most of
>>>the search code in lookup.  However, requiring a mutable reference is
>>>not necessary for the lookup code, so a search that takes a mutable
>>>reference and returns a mutable reference is too restrictive for
>>>lookup.  But maybe a more experienced Rust programmer can write a
>>>generic search that takes an &mut tree for insert, and a & for lookup.
>>
>>If it offends you that much, you could use a macro.
>
>Good to know that there is this option.
>
>>By analogy, in your C, how would it affect things if you wanted
>>to `const` qualify the tree pointer for lookups?
>
>C works perfectly fine without "const", so why would I want to do that?

Are you joking?  What if you have a `const struct tree` and want
to take a pointer to it?

More generally this is the sort of thing I'm referring to; Rust
is a different language than C, with different semantics, and
it imposes different constraints on programs than C.  One can,
if motivated, find some program that one can express in C, but
that cannot be expressed the exact same way in Rust.  But why is
that notable?  One could well invert this: I can define some
program that I express in Rust and ask why it cannot be
expressed in the exact same way in C.  But by itself, that's not
terribly interesting; what matters more is whether there are
problems, or perhaps more importantly categories of _problems_,
that are expressible in one and not the other.  I don't think
there really are; the solutions might differ in some ways, but
that's to be expected because the languages themselves are
different.

>By contrast, Rust is picky about "mut".  If I add it everywhere where
>the syntax allows it (which might be the analogon of leaving "const"
>away), the borrow checker will complain about programs that it
>accepted before adding all the "mut"s.

That's right.  The language imposes semantic constraints on
mutability and references; see my other post about this.  But
surely this is not surprising?

>>>I think that, in order to be the rightful heir, safe Rust should be
>>>able to do everything one can do in the other language that's not
>>>inherently unsafe, and do it without needing to duplicate code of
>>>other nastyness.
>>
>>I think that criteria is both silly and arbitrary, and has no
>>basis in actual practice.  You are asserting that an arbitrary
>>implementation detail of this one program is a useful yardstick
>>by which to measure a language's applicability to an entire
>>problem domain,
>
>Not one detail, the collection of all the details.  This is one.

All what details?  Your statemtn was that, "safe Rust shoudl be
able to do everything one can do in the other language that's
not inherently unsafe".  But missing here is your definition of
what you mean by, "unsafe".  I gave you Rust's definition: the
safety of a program is determined by whether or not the compiler
can infer that the program upholds the rules of the language vis
borrows, mutability, lifetimes, and so on; that is, whether the
borrow checker can do its job.  But there are cases where the
programmer has some insight into the context of the program that
the borrow checker just can't see into; hence, `unsafe` as a
part of the language.

>>>You may wonder about "inherently unsafe": I have no
>>>definition for that yet, but I would not kno why inserting a node into
>>>a search tree would ever fall into that category,
>>
>>Actually, I think perhaps it's the other way around: you do not
>>seem to know what "unsafe" means in a Rust context.  It is
>>merely a statement that the compiler cannot infer that the
>>"unsafe" code meets the language's memory safety criteria, and
>>that the programmer is asserting that it does; 
>
>I understand that.

Forgive me, but I'm not so sure.  Under that definition, the
entirety of a C program is `unsafe`; it's up to the programmer
to uphold the invariants of the language, and there isn't much
in the way of requirements on the _language itself_ to help you
out.  In this way, you seem to be putting a greater burden on
Rust than you do on C.

>>that is exactly
>>the same as every line in a C program.
>
>The decisive difference is that in a C program there is no end to an
>unsafe block, where I have to satisfy safety criteria that are beyond
>my experience level.

In seeming contradiction to what I wrote above, I think that it
_is_ harder to write correct `unsafe` Rust code than to write
correct C code, which is one reason Rust programmers try to
isolate `unsafe` code as much as possible.  The flip side is
that, if you do, the language gives you hard guarantees that you
can rely on to write correct programs; entire categories of
errors are eliminated by construction.

The thing that you wrote that does not follow is that `unsafe`
Rust code is never allowed to _violate_ those safety criteria;
it's just that the programmer takes on burden of upholding them,
with less assistance from the language.  It is not an escape
hatch to YOLO your program.

>>I'm afraid that sounds like a problem for you to deal with, not
>>a problem with Rust.
>
>Sure, and the way I deal with that is to not use unsafe Rust.

*shrug* That's on you, not on Rust.

>>>What I mean is the automatic dropping, and the fact that the Box stuff
>>>only occurs in the type declarations, but is automatically
>>>dereferenced or otherwise automatically handled; "let x = ..."
>>>produces a type automatically (but I guess you could put a type
>>>declaration there, though).
>>
>>Drop and box as a smart pointer is simply "RAII", which has been
>>in C++ since the 1980s.  Hindley and Milner created the type
>>inference rules you are referring to here in the 1970s.
>
>And?

...and so it's not "automagic".  It's simply an application of
well-known, pre-existing, techniques.

	- Dan C.

Back to comp.programming | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 18:29 +0000
  Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-10 14:18 +0000
    Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 17:31 +0000
      Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 15:40 +0000
        Re: Rust Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-11 14:26 -0400
          Re: Rust cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:14 +0000
          Re: Rust Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 21:15 +0000
        Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:13 +0000

csiph-web