Rust wants to make systems programming memory safe (and type safe while at it). It's not really about any specific language, it's about dragging the field forwards on the safety front.
Well it's not really Rust, it's the Rust community, which kinda wrestled it away from Graydon Hoare: the original inception of Rust was more of an applications language (what with the evented model and the split stack and the planned-though-never-really-implemented GC'd pointers) — which explains part of the historical confusion with / comparison to Go.
But then a critical mass of people took a look at this early rust and figured "we've got plenty of memory-safe and type-safe (ish) languages for applications, but this thing has precise control over memory and lifetimes and shit, we could actually build reliable infrastructure with that", and it coincided with a lot of memory safety issues news (which has been continuing ever since), and the rest is history, pretty much.
> Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Keep up the good work, I'm excited to see where Zig goes next.
I'm imaging some poor software engineer in 2065, having to maintain an enterprise legacy stack... levels of FORTRAN/COBOL->C->C++->ZIG->RUST->PERL->PYTHON.... all the way up....JS..etc..
Of course, the complexity might explode from there…or you might just not really notice it all that often. Anybody familiar with LLVM or WASM or heck even a language that can transpile to JavaScript can probably relate to this possibility.
The thing that’s harder to fathom is going from low-level to high-level. High-level -> intermediary low-level -> high-level is fathomable though.
I do, because that would mean that more attention must be paid to make languages work together, instead of each language ecosystem becoming its own little island. Maintaining a project built from a dozen languages (where each language does one thing well) should be just as simple as maintaining a mono-language project.
I have good news and bad news: That programmer will not know any of those languages, as they will just program in English and GPT-3000 will convert it into code.
GPT-3000 will have no problem understanding some interpretation of your English (or Spanish or Mandarin) "program", but will it be the right one? How long will it take to get GPT-3000 to understand what you mean when you can only talk to it in English (or Spanish or Mandarin) ?
A piece of software is a set of instructions that tell a computer how to do something. We use languages like C, Python, Haskell and Lisp to describe what to do in ways that avoid as much ambiguity as possible.
The question is: if you used a natural (human) language, how much confusion would (a) the putative GPT-3000 (b) another programmer (c) a compiler/interpreter incur when trying to understand your instructions?
The ZIG compiler requires a C compiler to compile to a native executable though.
Do you mean compiling the zig compiler or zig programs?
I think neither is quite the case. zig itself can build both Zig programs and C/C++ ones. Zig doesn't need to use a C compiler to build native Zig executables. It does need a linker, as does Rust, as do C/C++ programs and AFAIK zld is not yet ready.
However it's accurate to say that it's only able to compile the C/C++ code by leveraging libclang, the C/C++ compiler underneath.
By the way, check out this project by Zig core team member, Vexu: https://github.com/Vexu/arocc
No it doesn't? Not unless you want to also compile C, which the Zig compiler is capable of doing because it bundles clang.
I feel like Rust wants to replace C but it also wants to replace C++. And given the complexity difference between the two languages, that means that Rust will end up closer to C++ than to C.
So there's some overlap based on how Rust positions itself, but not based on how Zig positions itself.