[m-dev.] Rust backend?

[Fabrice Nicol]

Thank you Zoltan for your clear reply, this is pretty much in line with
what I thought.

Yes, I did check the PhD-related papers on RBMM before asking. As they
looked promising, I wondered whether any progress had been made ever since.

Two points though:

1. The original implementation of GNU Prolog did *not* resort to GC, this
is made very clear in Diaz & al. 2010,  "On the Implementation of GNU
Prolog", p. 29.   Clearly confirmed in a 2013 SO reply by Diaz. In a
nutshell, they do not do dynamic heap allocation, they instead mmap all
stacks in virtual memory and use swap. Stack sizes are controlled via env
vars and generously set on startup. They may have been trying to fiddle
with GC of late,  anyway it is not an essential part of the gprolog
implementation.

2. Another case in point is scryer-prolog, a recent implementation written
mostly in Rust. Only compiles to bytecode this far, yet with no GC.

The motivation of my question was not predominantly code safety (even
though FLI via C is by design limited to unsafe Rust, a limitation that
would hopefully be lifted with a Rust backend).

It arose from my pro experiences with Rust over the past 2 years. I came to
be aware of GC footprint both on RAM use and execution speed a bit more
acutely than I used to be in younger years. A quick look at older Mercury
benchmarks (in which GC is deactivated on command line or alternatively is
not) confirms that GC footprints may be quite significant too.

Well, I'll give it a try at scryer therefore.

Fabrice







Le ven. 19 sept. 2025, 22:54, Zoltan Somogyi <zoltan.somogyi at runbox.com> a
écrit :

>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20250920/4e87f8ce/attachment.html>