llvm-project VS zig

I just reported this one, for instance! https://github.com/llvm/llvm-project/issues/73999

C++ compiler which compiles the Rust as if it were C++ (LLVM).

If you want something much larger, getting the gist of https://github.com/llvm/llvm-project could be useful. Not only is it cleanly written, but then you'll understand your compiler better!

> OTOH, the existence of an ISO standard with multiple implementations can benefit the portability and longevity of code.

This is true for ISO standards that actually standardize features. Fortran's standard, since F'90, has instead been inventing features, and doing so without prototyping in actual implementations. And without supplying standardized test suites to guide those implementations. The results, in actual practice, have been at best mixed. There are features that are "standard" but not at all portable, due to spotty and divergent implementations, and there are portable features that are not standard. Some features have been in the language for >=20 years without yet appearing in popular compilers.

So yes, standardization (ISO or otherwise) can be a good thing. But it hasn't really been so for Fortran. And I think things are getting worse; F'2023 has changes in it that actually silently change the behavior of existing standard-conforming code, which would have been viewed as an abomination in earlier days.

References: see the LLVM Flang documentation on extensions, non-standard features, &c. in https://github.com/llvm/llvm-project/blob/main/flang/docs/Ex... and a suite of various incompatible feature tests in https://github.com/klausler/fortran-wringer-tests .

flang [1], it's part of the LLVM project.

[1] https://github.com/llvm/llvm-project/tree/main/flang

LLVM isn't a virtual machine, but WASM is.

That's obviously a common misconception given the name -- LLVM was meant to be a VM early in its life, but never was, and isn't now. It's clarified in the first sentence of a home page - https://llvm.org/

It's basically a bunch of C++ libraries that implements an IR that changes over time, which help you write compilers.

Curiously, I think a decade or more ago there was a project at Google targeting the same space as WASM which made this mistake. They thought LLVM was a virtual machine! That was PNaCl or something.

I guess it's a little like LuaJIT freezing Lua at Lua 5.1 -- Lua was never a standard, but for the purposes of re-implementation, a specific version of it can be frozen. (But there are obvious problems with that approach, namely that the re-implementers don't know about all the bugs they're also freezing in time.)

---

I have raised some eyebrows at the "compromises" of WASM, but the once thing that you can't doubt is that it is in fact a virtual machine !!!

I watched a talk on the WASM GC, and the creators were up front about the compromises (e.g. you will need runtime casts at first, with the measured overhead being reasonable), which gives me more confidence in it:

https://old.reddit.com/r/ProgrammingLanguages/comments/17crk...

The fact that they haven't rewritten glibc's string parsing wouldn't make their criticism wrong.

If all of glibc had been written in assembly for every single target triplet, one wouldn't be wrong to point out that there was no benefit to doing that instead of writing it in C, and that it probably took more work and was more error-prone, even if they weren't willing to help port said code to C.

Just the same, they could have written this in C++.

Much of LLVM's libc is written in C++ with exposed C bindings (or all, I haven't checked 100%). For example, their libc stdio implementation is completely in C++.

https://github.com/llvm/llvm-project/tree/main/libc/src/stdi...

You could say the same thing about Rust and Relibc, but it seems much less likely that a C project would incorporate Rust than that it would incorporate C++.

C++ ABI has some per-thread globals: the number that is returned from std::uncaught_exceptions(), and the chain of currently caught exceptions. For example in llvm this is available with a cxa_get_globals call:

https://github.com/llvm/llvm-project/blob/b05f1d93469fbd6451...

These need to be saved/restored when switching fibers, otherwise fiber switches from catch clauses (and destructors!) are unsafe, throw without argument may rethrow incorrect exception, code that commits/rollbacks based on uncaught exceptions counter will not work correctly, etc.

One example I know where this save/restore is implemented is the userver framework, but it seems to be unexpectedly rare in fiber implementations last time I looked.

I think you're correct that it's a big problem that the serious compilers don't actually have coherent internal behaviour, but I think that's a distinct problem which has been masked by the provenance problem in C and thus C++. It meant that real bugs in their software can be argued as "Works as intended" pointing to DR260 rather than anybody needing to fix the compiler.

For LLVM the effect of Rust has been to drag some of these issues into the sunlight, as it did for aliasing problems previously. https://github.com/llvm/llvm-project/issues/45725

Once the GCC work is closer to finished, I expect we'll see the same there.

I disagree that you need to solve the C problem first to solve the compiler problem, and I think it was misguided to start there. You seem to have focused on the fact that exposure is even an option in Aria's implementation, but let me quote: "The goal of the Strict Provenance experiment is to determine whether it is possible to use Rust without expose_addr and from_exposed_addr". Setting PNVI-ae-udi as "the" provenance rule is your end goal for C, but there's a reason it's called the "Strict Provenance" experiment in Rust, the goal is something like what you call PNVI-plain.

APIs like map are key to that goal, Rust has them and N3005 does not.

So like I said, rather than just being a "translation" I think the most that can be said is you've got the same problem albeit in a very different context, and your solutions are related in the way we'd expect when competent people attack similar problems.

If you are interested in more low-level programming with manual memory management I would like to throw Zig (https://ziglang.org) into the mix. A while back I started trying to learn it after using Go almost exclusively for the last couple of years and I like it a lot. It has some modern concepts similar to Go (like defer) that just makes it nice to write. Just be aware that Zig is in early stages of development so documentation and stability can be rough at times.

https://github.com/ziglang/zig/issues/7295

Or is it that the three years it’s been around indicate it will never progress?

Actually it seems according to the issue that TigerBeetle (one of the bigger zig projects out there) noticed this issue [1]. It's also on their issue tracker [2].

[1] https://github.com/ziglang/zig/issues/17851

Zig’s issue tracker list them [0].

[0]: https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue...

Chapel has at least several full-time developers at Cray/HPE and (I think) the US national labs, and has had some for almost two decades. That's much more than $100k.

Chapel is also just one of many other projects broadly interested in developing new programming languages for "high performance" programming. Out of that large field, Chapel is not especially related to the specific ideas or design goals of Mojo. Much more related are things like Codon (https://exaloop.io), and the metaprogramming models in Terra (https://terralang.org), Nim (https://nim-lang.org), and Zig (https://ziglang.org).

But Chapel is great! It has a lot of good ideas, especially for distributed-memory programming, which is its historical focus. It is more related to Legion (https://legion.stanford.edu, https://regent-lang.org), parallel & distributed Fortran, ZPL, etc.

The answer was given by the Elixir community with burrito which enables users to pack up everything an Elixir application needs within a binary namely Zig Archiver to package the binary and Zig Wrapper that wraps the Erlang Virtual Machine to be used in multiple platforms (Zig + Rust in the same project 🤯).

Do not try implementing something by yourself, especially if you are like me ( loosing motivation instantly if something goes wrong ). So what to do ? Go to std , just try copying implementations from there. This leads to solid understanding how to write right code. If you don't understand something you can always go to documentation ( 2 ) and look there or into std itself and just discover tests that are written for specific structs, they really help a lot.

If you're not familiar, Zig is a low-level general purpose programming language that provides improved safety over C/C++ and powerful compile-time meta-programming called "comptime".

There's support for this type of OOM testing in Zig's std.testing:

- https://github.com/ziglang/zig/blob/1606717b5fed83ee64ba1a91...

- https://www.ryanliptak.com/blog/zig-intro-to-check-all-alloc...