[m-dev.] Rust backend?

[Zoltan Somogyi]

On Fri, 19 Sep 2025 13:49:00 +0200, Fabrice Nicol <fabrnicol at gmail.com> wrote:
> Is there any project around aiming at a Rust backend?

No.

> With its growing adoption as a memory-safe alternative to C and runtime
> wonders one might be tempted to see it as a possible step forward for
> Mercury integration in a number of promising projects.

Generating Rust instead of C would not improve the memory-safety of the
generated code, for the simple reason that it is *already* memory safe.
Rust's advantage over C is that it proves memory safety, but the Mercury compiler
also ensures memory safety for the code it generates, and a second proof
would not help.

And since Mercury and Rust ensure memory safety through approaches
that are broadly similar (controlled mutability) but different in detail
(gc vs the borrow checker), even supporting the ability to link Rust code
into Mercury programs would not help *that* much. Such linking is already
possible because both languages have interfaces to C. The Mercury/C interface
is effectively limited to atomic data items (integers, floats, chars and strings),
with any compound Mercury data structures being effectively opaque blobs,
and any Mercury/Rust interface would also be limited in this way, due to
differences in data representations for compound data in the two languages.
So a direct link could improve the ergonomics, but could not really add any
capability that isn't already there in an indirect link to (unsafe) Rust via C.

> The elephant in the room here will be how to cleanly get rid of global heap
> GC. Not a minor hurdle to jump over considering the extensive use of the
> Boehm GC at runtime.

"not a minor hurdle" is a vast understatement. The Mercury implementation
*assumes* that the target language has gc, and changing that assumption
is literally a research project. Have a look at the papers on adding region-based
memory allocation to Mercury. A student spent a whole PhD on that, with
significant help from us (he even came to Melbourne for some weeks), and
the result was still an incomplete system: good enough for some benchmarks,
but not good enough for general use.

> Note that some stack-oriented Prologs like GNU do not
> resort to GC

The last time I checked, which I admit was many years ago, GNU Prolog
did use gc.

> So my
> question, before giving it a try myself: is the whole endeavour doomed from
> the start or is there any glimmer of hope?

Sorry to be the bearer of bad tidings, but I am afraid it is doomed.

Zoltan.