Only backend has been swapped out.
The tests will be fast too yes.
There is no real need to add an interpreter. Having custom backend s means that while currently it is being used for debug, far in future it might be able to compete with llvm for speed.
Adding an interpreter would be useless as u would still need to write a custom backend.
The problem is llvms slowness for debug and release.
it doesnt catch temporal memory errors, but what it offers currently is still better than most of its competitors [defer, explicit allocators, custom allocators with integrated support for valgrind and friends,etc].
Due to how easy to parse and work with the language is, we might see a boom of static analyzers for zig. There are some quite interesting demos that can even go beyond basic borrow checking and straight into refinement types.
Zig's integrated build system will make it easy to add these tools into any project. Or maybe the zig compiler itself will integrate it.
the future is quite hopeful for zig but it is probably not one that is restricted to just borrow checking. I personally think it can go beyond and slowly become what C+FramaC or Ada is now for the critical systems world.
> Due to how easy to parse and work with the language is, we might see a boom of static analyzers for zig.
Parsing is almost irrelevant for static analysis. The most important thing is how restricted are the semantics, which allow you to make assumptions and restrict the behaviour of the program to a small enough set that can be understood. From what I can see Zig is not much different than C on this front, and potentially is even harder to analyze due to `comptime`
my bad for using the word "parse", "working with the language" is better to explain my intent, the language is minimal [unfortunately it follows llvm's semantics but its planned to change].
Comptime cannot affect runtime, it cannot do syscalls and cannot go on forever. Due to how limited it is, we can simply let it evaluate and then work with the code that is left.
It is still a better method than either writing text macros[which are also fine but are a pain to use] or using proc macros which can do syscalls and open up a whole new can of worms.
In languages that dont have any metaprogramming support, you must rely on some thing of a generator which is most probably not provided by the compiler vendor and verifying and trusting it is now the responsibility of the user.
Now you are left with things like template metaprogramming where higher and more complex techniques are not supported by the standard or any verification tools and you must trust the compiler to take the right decision regarding the code and having no tools support its verification.
Out of all the options for metaprogramming for a language that must also be verification friendly, comptime is probably one of the best solutions, if not the best.
Zig not being much different from C in this aspect is quite an unexpected compliment because of plethora of work done for its verification. Those same tools can be modified to be used for zig but you would not have to worry about much beyond logic and memory allocation verification [there exists a prototype for both].
I guess formal verification tools? That is the peak that even rust is trying to reach with creusot and friends. Ada has support for it using Spark subset [which can use why3 or have you write the proofs in coq]
Frama-C exists for C.
Astree exists for C++ but i dont think lone developers can access it. But it is used in Boeing.
Im pretty sure valgrind and friends can be used in zig.
Zig is still not 1.0, theres not much stability guarantees, making something like Frama-C, even tho it is possible is simply going to be soo much pain due to constant breakages as compared to something like C.
Zig's is in the standard library. From the commits it was started by Joran from Tigerbeetle, and now maintained by mlugg who is a very talented zig programmer.
The popular Rust one is tokio's io-uring crate which
1) relies on libc; the zig one just uses their own stdlib which wraps syscalls
2) Requires all sorts of glue between safe and unsafe rust.
