> Would it be fair to say that Zig is to C, what Rust is to C++?

I don't think that's the parallel I would draw.

Rather, I think both Zig and Rust aim to serve the use cases C and C++ do, but Zig and Rust pick different points on the tradeoffs involving safety. Zig feels like a "better C", in the sense of bringing modern language features to C, but it chooses safer rather than safe. Rust supplies modern language features as well, and chooses to prioritize safe; sometimes that comes at the expense of other factors, such as productivity or compile time. I personally prefer the point on the spectrum that Rust chose, but I think Zig still offers improvements over C.

disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around.

One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it.

Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand. And, in some cases, work around. It seems, from looking at others' code, that there is a very strong temptation to lean on `unsafe` instead of figuring out how to solve a problem within the constraints it normally applies.

That has me wondering if there's really all that much safety difference in practice? Simpler code is generally easier to understand, and it's generally easier to find and fix bugs in code that's easier to understand. I can imagine a world where it's a tradeoff between, "You definitely won't have any of this relatively narrow category of bug, unless of course you opt out of the static checks, which you will probably do sometimes, even though we tell you you shouldn't," and, "There are no particular guarantees, but you're generally less likely to have any of this broader category of bug."

"simple" is, unfortunately, not a simple concept, nor does everyone agree on its effects on programs written in a language that is or is not simple.

Some people do believe that, let's say "conceptually parsimonious" languages (using complicated words to describe simplicity is amusing to me, sorry) do exactly what you say. Others believe that complexity inherently exists, and you can put it in the language, where a compiler can tirelessly check certain properties for you or a runtime can do magical complicated work on your behalf, or you can put it in the programs, where users have to check such things themselves.

Another way I heard this expressed one time is Ruby vs Python. I once heard someone talk about how they preferred Python as a language more, because it was simpler, but enjoyed actually programming in Ruby more, even thought it was more complex, and they value simplicity. The reason is that all of that nasty ugly stuff Ruby lets you do makes you be able to make extremely nice APIs. Things you couldn't do, or just folks don't do, in Python. And therefore they ended up liking using Ruby more in practice.

I suspect that this is a topic that we, as a profession, will debate about endlessly.

> Others believe that complexity inherently exists, and you can put it in the language, where a compiler can tirelessly check certain properties for you or a runtime can do magical complicated work on your behalf, or you can put it in the programs, where users have to check such things themselves.

I think we'd all agree there's a spectrum, with, say, Assembly on one end and Idris on the other, where neither Zig nor Rust are near either extreme, and are actually rather close to each other. It's not a matter of accepting or rejecting a principle, but on picking slightly different sweet spots (hopefully) on a tradeoff spectrum.

Rust doesn't check at compile-time most things that could be checked at compile-time. In fact both language check almost the same things at compile-time, and almost the same things at runtime. The design differences come down to one or two things that are clearly tricky and that neither language "does for you" -- i.e. you still need to think about them -- but are, indeed, checked in different ways.

Yep. I agree they’re closer to each other than the extremes for sure.

There is also the notion of languages you love writing code in vs languages you like reading code in. Languages with more powerful abstraction abilities bring joy to the writer but make things tedious for the reader.

I don't agree with that. For example, I think it brings me joy as a reader that I can tell at a glance from a function signature which arguments are modified and which ones are just read. Without the abstraction of mutable and immutable references I would have to read the entire source code of the function and every function it calls to know for sure what it does with the pointers. It also brings me joy as a reader that common functionality like equality comparisons or string formatting can be derived by the compiler, instead of having separate hand-made implementations for each data structure, which might have subtle differences.

Totally.

I personally would not agree with

> Languages with more powerful abstraction abilities bring joy to the writer but make things tedious for the reader.

I find map/filter to be easier to read than a C-style for loop. Things that are conceptually denser make discussion between experts easier, even if it makes things harder for non-experts. This is why jargon exists, for example.

Ah yes - that makes sense. I should have been more precise - I meant abstractions that allow you to add opaqueness (like macros and operator overloading). Again culture plays a role here too - some communities normalize such abstractions more than others.

In short I believe languages that one can pick up in a couple of days and then read code where reasoning of the code is highly local would stand a higher chance of being perceived as simple.

As always it depends. If you're thinking about preprocessor macros and operator overloading from C++, sure, those can be annoying, it's more to do with C++'s implementation and usage of them than the features themselves. You might want to try Common Lisp sometime; so much of the base language is made up of macros without which programs would be neither pleasant to read or write, and the language itself provides facilities to ask "ok but what function(s) are actually going to get called with this data" so that even not-so-local things like e.g. transparent logging of a call's input/output become visible if you need to know. But CL is not a language one can pick up in a couple of days -- albeit CL shops report success in getting new hires to be productive after a week or two of reading a book and the company code, which is a common onboarding time at many companies with any language.

Programmers notoriously conflate "simple" and "easy" (classic talk: https://www.infoq.com/presentations/Simple-Made-Easy/) and so I believe languages that are easy for a lot of programmers will also be perceived as simple, whether or not that's accurate.

Without powerful abstraction (of course used sparingly) you will just copy-paste the same logic in multiple places. Which is error prone and unmaintainable. And I would argue that even though a small part of it may be easier to read, you will have a harder time getting the big picture with low abstraction.

Is

    char* c_foo(char* bar) { ... }

simpler than

    fn rust_foo<'a>(bar: &'a str) -> &'a str { ... }

?

On the one hand, c_foo is shorter and doesn't use strange symbols. On the other hand, rust_foo doesn't leave you guessing on whether the returned value needs to be free()d or not, and whether the heap allocation backing `bar` can be free()d after the call or not.

(You have a tiny typo; you forgot the <'a>. Also, I know you know this, but for those that don't, this signature could be written as

  fn rust_foo(a: &str) -> &str { ... }

but Arnavion is trying to be explicit here to make a steelman.)

Yeah, I fixed that typo. And yes, foo is arbitrary, so one can assume it has another * / & parameter such that the lifetimes can't be elided any more.

The first example is definitely simpler, yes.

You are talking about the simplicity of a line of code. The topic being discussed, though, was the simplicity of the language itself.

The simplicity of the language is directly correlated to the simplicity of that line. The fact that the language makes relationships between inputs and outputs explicit is a feature of the language, because of its borrow checker, at the expense of being syntactically verbose compared to C.

Not at all. A single line will use a tiny subset of language features. It will show you nothing about the overall complexity of the language, just about those things it happens to use.

In my experience unsafe tends to be used really sparingly by most users, if at all. And besides, unsafe doesn't really turn off static checks - it allows you to do a few extra things that can't be proven to be safe statically, in tightly scoped specially annotated regions. It's mostly about bending the rules temporarily, for 1-5 lines of code at a time.

Side note: Nothing is provable in rust because it does not have a formal, verifiable specification. We have a reference implementation that we believe does the things it says it does on one particular architecture. But trust, not proofs, is indeed required. >:) (don't downvote murder me, I love rust)

A subset of Rust has been formalized and proven, but you're right that we're still working on it.

> It seems, from looking at others' code, that there is a very strong temptation to lean on `unsafe` instead of figuring out how to solve a problem within the constraints it normally applies.

Are you sure those examples of unsafe Rust code were written using unsafe in order to work around safety constraints due to difficulty?

I ask because there are some very real and valid use cases for unsafe code in Rust that have nothing to do with the fact that writing the code safely might be more difficult.

Not sure at all - I have effectively zero working knowledge of Rust - and certainly not looking to second-guess people's motivations for using the feature.

The big bias I'm working from here is that, as an outsider, I have a hard time reconciling all the big talk about how Rust makes it impossible to experience certain classes of bugs, with the existence of a known set of things that its type checker can't check, and which includes a lot of things that are difficult to avoid. One could be forgiven for thinking that the Rust community has a habit of keeping its fingers crossed behind its back when talking.

I don't want to make the perfect the enemy of the good, of course. I realize the feature is there for an important reason. But it sure looks to me like Zig is also good despite being imperfect. Perhaps they're both similarly good languages.

Proper use of 'unsafe' in Rust is to write safe code that the compiler cannot prove is safe. In fact, this is done to implement many parts of Rust's standard library. See the split_at_mut example in

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

The spec here is to turn one mutable slice into two non-overlapping mutable slices. The operation does not violate memory safety; we wind up with only one mutable reference to any part of the object. But the compiler does not know how to verify that the programmer has done this correctly. Here, 'unsafe' means 'I certify that this is safe, use that as a lemma to do further checking'.

All systems programming languages need the ability to do unsafe stuff, the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible.

It is a big difference to have it on your face that something might need to be properly double checked and having each line of code as possible security exploit.

> the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible.

Would you consider Oberon to belong in the former or latter category? On one hand, there's no explicit code blocks as such (syntactically). On the other hand, unsafe primitive operations are limited to the SYSTEM module, so functions calling operations in the SYSTEM module can be considered doing unsafe things.

If you read Oberon documentation, modules importing SYSTEM are tainted and considered unsafe.

Just like Modula-2 already does it.

Well...that's what I meant. But which one is it, then?

Just like the languages that have unsafe code blocks it is relatively easy to track down unsafe modules, same thing.

And just like languages with unsafe code blocks, there are compilers that have switches to forbid the use of tainted modules unless explicitly allowed.

In any case, way better than what C, C++ and Objective-C offer, regarding security per line of code.

No type checker can catch all buggy programs (that involve solving the halting problem). In practice, Rust strikes a good balance: in over 120,000 LoC of Rust code that I have helped write and maintain, we have maybe 10 lines of unsafe, with performance matching or exceeding that of the C/C++ counterparts.

> No type checker can catch all buggy programs (that involve solving the halting problem).

It's far worse than that, the problem is that the machine can't know what was intended. The result 5 from calling sum([1,2,1,1]) makes sense, but alas this function was intended to produce the product not the sum, the inputs were supposed to be [1,2,3,4] and the desired result was 24... the machine can't hope to guess that.

A program may be buggy even if it its meaning is transparent and exactly reflects its effect, simply because it doesn't reflect the intention of the person who wrote the wrong program.

This quote is attributed to Babbage:

'On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question'

But that is what we wanted, even if we obviously can't have it.

It might help to better understand the motivations behind unsafe Rust by reading some of The Rustonomicon[1].

[1] https://doc.rust-lang.org/nomicon/

I think they solve some similar and some different problems, with some similarities and differences!

The biggest difference in the problems they solve, in my view, is that Zig does not aim for safety. It'll be easier to write safe programs yourself with Zig than it might be with C, but it doesn't give you any guarantees.

Zig also seems like it may be a better fit for embedded programming; there's a big community around embedded Rust, and it sounds like there's a lot of progress, but still an uphill battle.

But yes, Zig:Rust :: C:C++ has merit in that Zig is a much smaller, less feature-rich language.

Thanks for the response. I'm excited for as many viable alternatives to C/C++ as we can get.

I write/maintain multiple code bases for XMega, SAMD, and STM chips. The kind where 32K ram is cool and 256K flash is lots. I'm curious if either of these is ready for normal humans to cross compile for these kinds of targets (M0 and the ilk). Zig looks very interesting to me.

Many people say this, and there's some truth to it, but like all analogies, it can be useful in some contexts but not others.

The issue with this analogy is that it assumes that C, one of the languages used in the most diverse set of circumstances ever, means the same thing to everyone. Same with C++, frankly.

> Would it be fair to say that Zig is to C, what Rust is to C++?

There's definitely something to that analogy, but I think it also misses a lot of really important details. For example, Zig has generics, which right off the bat makes it hard to say that it's "like C". Also Rust enforces memory safety, which isn't like C or C++.

I mean, C11 also has generics, but I would really suggest not using it X). See https://en.cppreference.com/w/c/language/generic

Of couse, it's a much less powerful feature, there's nothing like interfaces or stuff, just a way to "overload" based on the type.

Thank you. I had no idea that you could do such a thing in C11 preprocessor

_Generic() is not a preprocessor feature, but a "real" language feature (I was confused too when I saw it first though).

The only preprocessor part in the example is mapping the function-like macro 'cbrt(X)' to the language keyword '_Generic(X)'.

i love that zig doesn't have a special syntax for generics, it just allows anything to be resolved at compile-time -- including types. which gives you generics 'for free'.

I've only cursory of Zig, so bear with me. Does this mean that Zig templates are like C++, that is, duck typing? Or is there a notion of constraining the type arguments?

It's duck typed but it's not based on a funky and limited syntax, but rather types at comptime become normal arguments to functions that you can then inspect using normal Zig code.

I wrote a blog post about comptime if you want to learn more: https://kristoff.it/blog/what-is-zig-comptime/

It's duck typed but let's say your "template" takes an integer and divides by two depending on some boolean (perhaps you need to return a lookup table of sometimes half the bitwidth of an integer type). That function called by your template at compile time to maybe-divide-by-two is in the same language as runtime zig, and you could even conceivably call that very same function as a compiled entity in the runtime context.

You can constrain type arguments with a compile-time `if` check, and generate a compile error on violation.

I think that's correct with some overlap, yes. Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less.

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.

> I feel like Rust wants to replace C but it also wants to replace C++.

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.

You can find Zig's explicit goal as stated by the creator on the homepage:

> Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

Touche! I heard you on Corecursive, which is where I got that from.

Keep up the good work, I'm excited to see where Zig goes next.

I believe the creator is on record on some youtube video or something stating that the intent is to replace C.

The guy you are responding to IS the creator of the language.

yes, I'm aware, and he's aware of who I am too =D

We already have c/c++ as low level bases, now zig/rust are coming for the throne, I really hope contenders dont keep spawning like rabbits. If everyone got behind a smaller # of initiatives the worlds codebase would be simpler going forward?

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..

I don't want contenders to spawn like rabbits. I want the industry to coalesce around just a few contenders to maximise network effects so as to kill off C and C++ more effectively.

While I would absolutely love to have that job, I’m afraid I’ll never get to do it. Language cross-compilers seem to keep getting better. It may be that case that one day, you will run a legacy program through a babelfish and get something understandable to you back out.

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 really hope contenders dont keep spawning like rabbits

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'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..

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.

The reason that we have programming languages at all is that English and all other natural languages are too ambiguous to be used for this purpose.

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) ?

Eventually maybe only the same amount of time it takes the average programmer to understand your meaning.

So like months and years? On every project I’ve worked on, the programmers conception of the requirements evolves until the minute they stop working on it. And they only understand the part they worked on, not the whole thing

The discussion is not about understanding "requirements".

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?

That might be true. But the comparison is not with another programmer. Rather, it's with the essentially instantaneous understanding that a compiler/interpreter has when you feed in a programming language.

This has been attempted many times in the last century but never happened, I think it's quite safe to say that this also won't happen in the next century.

> Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less.

The ZIG compiler requires a C compiler to compile to a native executable though.

To be fair, the C compiler also requires a C compiler. Bootstrapping is a common milestone in language development (Rust can bootstrap itself too), so while the current state of affairs for Zig might require a C compiler, that's not necessarily written in stone.

> 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.

Here's the info on zld status: https://ziglang.org/download/0.8.0/release-notes.html#Self-H...

By the way, check out this project by Zig core team member, Vexu: https://github.com/Vexu/arocc

> The ZIG compiler requires a C compiler to compile to a native executable though.

No it doesn't? Not unless you want to also compile C, which the Zig compiler is capable of doing because it bundles clang.

Zig/Rust aim to fit in the same systems/general purpose space which can be viewed as alternatives to both C and C++.

Take a look at my comparison of semantics that unfortunately not yet includes a sketch of memory and synchronization: https://gist.github.com/matu3ba/dda72ad5ee473e3ea26426c121e0...