The Case for Rust (in the base system)

Alain De Vos said:
One simple example . In C you can dereference a null pointer & a pointer pointing to the sky. Never possible in F# or ada
Click to expand...
Ada its quite easy:

Code: 
with Ada.Text_IO;

procedure Erroneous is
   type Int_Ptr is access Integer;
   P : Int_Ptr;  -- uninitialized
begin
   -- ERRONEOUS EXECUTION
   Ada.Text_IO.Put_Line (Integer'Image (P.all));
end Erroneous;

F# is just .NET so the typical bindings marshal errors allow it too.

Code: 
open Microsoft.FSharp.NativeInterop

#nowarn "9"   // allow NativePtr usage

let demo () =
    // Allocate stack memory for an int, but DO NOT initialize it
    let p = NativePtr.stackalloc<int> 1

    // ERRONEOUS / UNDEFINED BEHAVIOR
    let x = NativePtr.read p

    printfn "%d" x

demo ()

And since languages other than C or C++ need a *shedload* of bindings, this kind of dangerous stuff is very easy (and necessary) to creep in.
 
kpedersen said:
Ada its quite easy:

Code: 
with Ada.Text_IO;

procedure Erroneous is
   type Int_Ptr is access Integer;
   P : Int_Ptr;  -- uninitialized
begin
   -- ERRONEOUS EXECUTION
   Ada.Text_IO.Put_Line (Integer'Image (P.all));
end Erroneous;

F# is just .NET so the typical bindings marshal errors allow it too.

Code: 
open Microsoft.FSharp.NativeInterop

#nowarn "9"   // allow NativePtr usage

let demo () =
    // Allocate stack memory for an int, but DO NOT initialize it
    let p = NativePtr.stackalloc<int> 1

    // ERRONEOUS / UNDEFINED BEHAVIOR
    let x = NativePtr.read p

    printfn "%d" x

demo ()

And since languages other than C or C++ need a *shedload* of bindings, this kind of dangerous stuff is very easy (and necessary) to creep in.
Click to expand...

What do you think of my cppfront program , hello.cpp2 ,

Code: 
String: type == std::string; 
auto&   Cout =  std::cout;
#define Format  std::format

greet: (name: String) = {
    Cout << Format("Hello, {}\n", name);
}

sum: (a: i32, b: i32) -> i32 = {
    sum := a + b; // Type inference with :=
    return sum;
}

main: () = {
    x: String = "world";
    greet(x);
    s:=sum(10, 20);
    Cout << Format("Sum :  {}\n", s);
}
 
Alain De Vos said:
What do you think of my cppfront program , hello.cpp2 ,
Click to expand...
I like it to an extent. I do think extensions of C (and C++) do have a lot of merit as a solution for a next gen language.

But my worry is that they focus on the wrong aspects and miss the important things that need to be improved.
 
POSIX.1 said:
And you miss to name those things that you regard as important.
Think about all these kids reading here ... do you think that they know?? :-/
Click to expand...
The limitations of C++ are well cited in a number of papers. I don't expect every technical conversation needs to be suitable for kids.

Similarly to before, I can only recommend people read around if they are struggling to keep up 🤷‍♂️ .
 
kpedersen said:
And since languages other than C or C++ need a *shedload* of bindings, this kind of dangerous stuff is very easy (and necessary) to creep in.
Click to expand...
And this is where we wrap around to C being the lingua franca of programming. No matter what language you write in, if you want to talk to anything that isn't your language, you must speak some dialect of C.
C has become more than a language, it holds a regal seat of power as the FFI Protocol. If you don't speak C, your language (or runtime) is useless.

But as for the thread topic, I don't think Rust in base is a good idea yet. While it would be nice to have, it's not yet stable enough to warrant it. Though I am looking forward to a future where it would be a good idea, and it gets included
 
I'm not familiar with Odin, nim and Zig are definitely proper alternatives. My personal preference is Rust though, hence why I'd look forward to having it in base. Zig would be fun too, not sure what that would mean for build times though, considering it _also_ needs its own LLVM.
 
Putting language grammers and ecosystems aside.

Considering current toolchain of FreeBSD is basically LLVM / Clang, any new languages introduced into base should be implemented by LLVM project and shipped as part of LLVM. This way, what toolchain team on FreeBSD project are forced to do would be minimized.

And as rewriting everything at once is NOT realistic, assuring sane linking and working fine with this "mixed up" situations are mandatory. I think current policy of Rust project is completely against it at least for default configurations. To introduce current form of Rust, Rust project should change their mind and default to "friendliest to link against old codes".

These should also apply to any other candidates, too (not limited with Rust alone). FreeBSD project is not enough large project, lacking sufficient dedicated fulltime developers unlike Windows and some of Linux distros.
 
Rust has no problem doing interop. It requires a Rust version of whatever symbols your C code is exposing, just like C needs headers for linking to other libraries. Those "headers but for Rust" are what they call "bindings".
For Rust to expose functions in the output dylib (or staticlib if you prefer), there is extern "C", and you'll need a C header for those exported symbols to be usable. There is tooling to generate both the Rust bindings and the C headers. Naturally you'll want to verify the output, and correct it where needed, but that gets most of the heavy lifting done.
Incrementally adding or rewriting things isn't an issue so long as you keep the headers and/or bindings updated. Rust is luckily also built on LLVM, so it should be possible to build Rust with the rest of the system toolchain.

Rust is just an example here. Zig is also built on LLVM, nim transpiles to C (or a handful of other languages) and has an unofficial LLVM backend, and many other new langs are built on it too. And the principles are usually the same, make the code aware of what symbols to expect snd it'll work.
 
Yes, I know at least Rust uses LLVM backend, but it's NOT the same as upstream LLVM project's one itself. This is the fatal problem.
Near-fatal is that LLVM project themselves does NOT releasing Rust frontend.
These should cause significant additional, SHALL-BE-UNNEEDED maintainance burden for toolkit team if incorporating Rust into base is wanted.
This is NOT limited with Rust. But I consider this FATAL.
 
No, Rust doesn't use upstream LLVM as default setting. It does, however, support upstream LLVM:
Rust supports building against multiple LLVM versions:

Tip-of-tree for the current LLVM development branch is usually supported within a few days. PRs for such fixes are tagged with llvm-main.
The latest released major version is always supported.
The one or two preceding major versions are usually supported.
Click to expand...
From The rustc dev guide, Updating LLVM
 
Riven Skaye said:
No, Rust doesn't use upstream LLVM as default setting. It does, however, support upstream LLVM:

From The rustc dev guide, Updating LLVM
Click to expand...
See this long-standing PR 274743.
At worst, need waiting for PORT_LLVM option to be always default and never be (means, "at least theoretically" cannot be made) broken.

And this PR 292101 could be matter, too.

Using Rust for ports are fine. But to incorporate into base, the above needs to be mutually assured. To be honest, base LLVM/Clang are actually ported, maintained by hard works by dim@ and only few other volunteers. NOT BY TENS OR HUNDREDS OF FULL TIME WORKERS. Minimizing maintainance / porting burden should be considered mandatory for in-base toolchains.
 
kpedersen said:
The limitations of C++ are well cited in a number of papers. I don't expect every technical conversation needs to be suitable for kids.

Similarly to before, I can only recommend people read around if they are struggling to keep up 🤷‍♂️ .
Click to expand...
I read the link. If you suggest that it is important to be updated, it is a bad example. You can spend a lifetime studying only one fractal curve, a recent branch in topology, avoid this one.
 
You must log in or register to reply here.
Back
Top