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.
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].
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.
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.
I am pretty sure india is taking more steps than USA. you cannot blame them anymore. They are even pushing more money into nuclear and created a breeder reactor.
Wait just 20% thats a low number damn.
You said a lot and i was expecting...idk, 50%?
If Ada was used in domains where rust is used, like desktop applications, servers, high perf stuff, it would also do unsafe stuff you could never verify using spark.
But instead it is used in microcontrollers with runtimes provided by adacore and other vendors. Can you fully know if those pieces of code are 100% verified and safe? the free ones are not. atleast the free x86 one.
How ridiculous. The language you use is not memory safe btw. unchecked_deallocation can be easily used without any pragmas iirc. You need to enable spark_mode which will restrict you to an even smaller subset! You cannot even safely write a doubly linked list in it![you can with great pain in rust] [with less pain in Frama-C] [never tried ats]
Common Lisp is an amalgamation of every lisp they could find, they slammed it all in. Calling it well designed is funny because every single CL developer openly accepts that its a fucking weird language with hell lot of warts that cannot be polished away.
Ada is fine, just verbose, kinda fun, no comments about it except that its kinda sad how weak their formal verification is. I prefer Frama-C over it. You can compare Ada and rust but ada is horrible, sincerely horrible at working with ownership. Frama-C can run laps around it as you can verify EVEN arbitrary pointer arithmetic.
Calling rust a horrible abomination is weird. As someone who dabbled in CL for an year, I love the fact that it has proc macros and even tho its harder to use it, i can make my own DSLs and make buildtime compilers!!
That opens up a world of possibilities.We can actually have safer and stricter math libraries! Maybe put us back in era of non-electron applications?
The horrible part might be syntax but eh, its a stupid thing to care about.