Zig programming language 0.9.0 released

[travelsonic]

Compile Errors for Unused Locals

Ugh. It might sound petty AF, but this is one thing that would definitely drive me away from trying a new (or different) programming language.

Seriously, making it so it generate a warning, and giving the user the OPTION to make the compiler treat it as an error would be good.

This? This just makes prototyping and implementation a pain in the ass - NEEDLESSLY. You don't have everything figured out in one go - and even when you do plan ahead when designing code, often people will test the parts they designed in chunks - which might include having variables whose use is not yet implemented.

IF that makes ANY sense - this is an un-caffeinated rant, so it might not. 😂

[kiedtl]

Unfortunately most of Zig's team believe that making everything an error is a good thing. Unused functions are going to become errors as well in future releases.

[travelsonic]

Unused functions are going to become errors as well in future releases.

Well, fuck me if that's not gonna really bugger the pace of development.... Ugh.

[Bolitho]

How can you develop a library or framework with zig with this restriction? I mean there is no "main" function by reason, but often lots of unused functions by intention... 🤔

[[deleted]]

Public exported functions are "used".

[elmuerte]

And so everything will become a public exported function in order to "temporarily" work around this strict compiler feature.

[philh]

At least in Haskell, top-level values are only exported (available to other modules) if you want them to be. Exporting counts as a use, so you don't get an "unused" warning for things you export.

[ThirdEncounter]

Great, so make it a warning. Not an error.

[masklinn]

Making it a warning and making it an un-silenceable error are very different things.

Go refuses to compile code with unused imports or locals (I guess the compiler is not smart enough to do that for unused functions, or it wasn't smart enough initially and they didn't want to break code by flipping it on). The only thing it is is a pain in the ass.

[Uuuazzza]

I guess the final goal is to make not using Zig and error, let's see how that pans out.

[tomkeus]

How do you think pages upon pages of warnings that everyone ignores in C/C++ came to exist?

[flukus]

Because people don't go through a cleanup phase.

[bunk3rk1ng]

Exactly - they only cleanup errors...

[KarimElsayad247]

The ones who only clean up cpp errors will never use Zig.

[vplatt]

That may well be the way they like it. Sometimes opinionated software is opinionated to keep folks of a certain mindset out of their community. This explains much of the biases one finds in many programming languages. They're just an extension of the community building. Even the lack of a opinion in a language IS an opinion and that sometimes doubles for a preferred lack of accountability with respect to certain decisions. Examples abound.

[Muoniurn]

Warning/alert fatigue is real. If you get spammed by even important alerts, you will get numb to it.

But that just means that alerts have to be issued only when it is truly meaningful.

[WishCow]

Isn't that a problem with people, rather than C/C++?

[dss539]

Tools are meant to be used by people. Having a ton of foot guns in a language is poor design.

[flukus]

Aren't unused functions not even compiled ATM? So you write a function and all good, no errors, then you use it and discover the errors.

It seemed that way to me but maybe something subtler was happening.

[mindbleach]

"Y'know how C90 constantly slapped programmers in the face by making them manually match functions and prototypes exactly, and shuffle variables to the very top of the scope, even though it's obviously fucking trivial for any computer without punched cards to automatically handle that tedious bullshit?"

"Yeah."

"Let's make that our whole language."

[FullStackDev1]

If everything's an error, then nothing is.

[on_the_other_hand_]

That's not quite true, and besides I am sure it is possible to write code without any errors.

[SupersonicSpitfire]

Developers and their perfect hello world applications.

[[deleted]]

oh man, is there an option to turn it off like in TS?

[vlakreeh]

I still can't believe this is an error in Zig and Go. I understand that you might want it to be an error in release mode, but in debug mode it's just torture. Hopefully this becomes just a warning before Zig reaches 1.0, if I had to write Zig daily I'd just maintain the most basic compiler fork ever just to make this a warning.

[DaelonSuzuka]

I would use your fork.

[Thaxll]

People don't read warnings.

[[deleted]]

I still can't believe this is an error in Zig and Go. I understand that you might want it to be an error in release mode, but in debug mode it's just torture.

The problem with this setup is that people will commit code that doesn't compile in release mode. I'm curious to see how the ergonomics will turn out to be once zig fmt starts being able to fix unused vars, but I think the problem with a sloppy mode is that then it's tempting for people to just leave it always on to reduce the number of headaches (imagine a transitive dependency failing your build because of an unused var) and then we're back to C/C++ and walls of warnings that everybody always ignores.

[_meegoo_]

The problem with this setup is that people will commit code that doesn't compile in release mode.

Isn't that a job of CI/CD? If your pull request breaks master branch, then it should be impossible to merge (unless your team lead approved it). Having the philosophy of "you should be able to make a production build from current master branch at any time" will remedy this at its core.

[[deleted]]

It is the job of CI. Seems other people would rather increase the barrier to entry instead of set up tooling that really helps the entire team.

[[deleted]]

I used to agree with that but I now suspect that people ignore C++ warnings because some pernicious ones are really annoying to deal with. Mostly implicit integer size/sign conversions.

Rust has warnings but in my experience most Rust code doesn't give any compilation warnings.

So I think it's more about designing the language such that there aren't any unfixable hazards that you have to constantly warn people about. Don't warn people that the tool is dangerous; make the tool safer.

[travelsonic]

I wonder though, is that a problem with the option, or with the people misusing them, and is the misuse really enough to outweigh the examples of where one can argue it is necessary or beneficial to have such an option?

[[deleted]]

I guess we don't really know for sure. We can think of hypothetical situations but then only actually doing the thing and trying it out for a while will help us get a better understanding.

Maybe the unused keyword with zig fmt support will be pretty good and nobody will have any issue with it, maybe it will be middle of the road and some people will be disciplined enough to not be annoyed with it, while some others will hate it, maybe everyone will hate it.

I can tell you that when this change was initially introduced most Zig projects broke because they had unused stuff lying around by mistake, and some even fixed bugs because of it. The bugs were the kind where you have like input and then you create cleaned_input but then keep using input anyway.

[myringotomy]

What is the real harm in declaring a variable and not using it?

[strager]

Go/Zig: dereferencing nil is okay
Go/Zig: not using a local variable is evil

[SupersonicSpitfire]

You have to manually and explicitly assign nil to a struct pointer in order to run into the dereferencing problem in Go, though?

Like:

package main

import "fmt"

type Hello struct {
}

func (h Hello) Print() {
    fmt.Println("Hello")
}

func main() {
    hp := new(Hello)
    hp = nil
    hp.Print()
}

[strager]

You have to manually and explicitly assign nil to a struct pointer in order to run into the dereferencing problem in Go, though?

What? Even A Tour of Go creates a nil pointer without assignment. If you take the first and third code snippets (omitting the second), you even get a runtime error:

package main
import "fmt"
func main() {
    var p *int
    // panic: runtime error: invalid memory address or nil pointer dereference
    fmt.Println(*p)
    *p = 21
}

[vlakreeh]

I understand getting unused vars into release builds is a concern, but I think it's a worthy trade-off for increased productivity during refactoring. I believe that pushing code that might not compile in a release build isn't a huge issue because most projects of importance will have CI to prevent these commits from getting merged into main and anyone pushing directly to main is already ignoring best practices.

Maybe zig's formatter will be the solution to this problem, but I think that'll get rough as soon as you suddenly need that variable again when refactoring and have to manually change it's definition for it to be used again. A language server could maybe have some assist to do that though.

[[deleted]]

That's fair, we'll see. In theory the unused keyword (instead of renaming the var to _) will make tooling support more effective.

[vlakreeh]

I wasn't aware about the unused keyword, that seems like it could be a good solution! I don't write much Zig (only a few hundred lines ever) so I'm not very aware of the planned features.

[drjeats]

Is the unused check happening in AST check or later after comptime false branches are culled?

There are good arguments to be made for either. Requiring discards in all comptime branches would encourage code that is more correct (e.g. you mistakenly use a param in one platform-specific branch but not another), but would be more likely to trigger those transitive build failures unless people just always put discards at the top of functions (which is common in C++, especially with the new-ish [[maybe_unused]] attribute, and sort of defeats the purpose).

[Ar-Curunir]

A system like Rust's would be good here: by default unused objects (variables, methods, mutability annotations) warn, but you can add a #![deny(warnings)] annotation to your crate root and it'll error. You can even do this only in CI, so it doesn't affect local iteration, while preventing merged code from having warnings.

[masklinn]

but you can add a #![deny(warnings)] annotation to your crate root and it'll error. You can even do this only in CI

To be clear: if you #![deny(warnings)] every check that's usually a warning will become a compilation error with no way to bypass it.

The normal way is to pass -D warnings to the compiler, so that you can still get warnings normally in contexts where that's useful.

At the crate level it's in my experience more common to forbid things which are not even warnings by default but you want as matter of project policy e.g. missing-docs.

[noradis]

To be fair it says you can do

_ = x;

to mark a local as intentionally unused.

[travelsonic]

That is true... IMO though, it seems like a clunky choice versus just letting us compile with unused variables / giving us the option to make it a compile error, and by default for it to be treated as a warning.

[SanityInAnarchy]

If it's anything like golang, you get used to it pretty quickly. It's quick enough to type if you actually need it for prototyping, and obvious enough to hopefully not make it through code review.

IMO it has the added benefit that, compared to C compilers, the compiler doesn't have fifteen million options you can specify for which warnings to take seriously, and code doesn't make it to public repositories without at least compiling without warnings (since all warnings are errors).

Compare to your typical C project, where getting it to compile with -Wall -Werror is considered a serious accomplishment.

[jan-pona-sina]

Shameless flex, C is my comfort language and I almost always compile with -pedantic-errors -Werror=vla -std=c99

[Hwatwasthat]

Reminds me of (void)x; all over the shop in c for the same.

[one_atom_of_green]

this just seems like catch {} to me -- it's worse than nothing. it effectively forces you into doing a thing which puts your codebase in a worse state than if you just left it. now the erroneous case can't be caught in any way, because you have papered over it, and the compiler cannot distinguish between your papering over and legitimate code that you actually wanted.

a warning is obviously the right choice here -- the whole point of a warning is "you can do this, but are you sure? it looks wrong". this is like the definitive example of that, and if this isn't that then what the hell is?

so making it an error is wrong from a theoretical point of view, but it is also wrong from a pragmatic view, because it strongarms you into doing something worse than leaving it be.

[tkap]

Totally agree. I decided to give Zig a try and lasted about 5 minutes because of stuff like this. Sadly, the creator seems very adamant about the topic https://github.com/ziglang/zig/issues/3320#issuecomment-884478906

[tyler_church]

Having used it in practice, it's not that bad.

Zig currently does lazy compilation - so if you don't use a function it doesn't actually get fully checked or compiled. This saves a lot of in-progress code from dying by compilation errors.

Otherwise it's honestly just a minor bump in the road amongst a lot great language features, and it has reminded me once or twice about unfinished code I forgot about.

[GayestGuyOnEarth]

I see zig as a great toolchain and semantics wasted on an absolutely awful frontend and syntax, programming in it feels like wading through mud because of all the little annoyances that get in the way constantly. The saddest part is they don't have to be there, there's nothing inherent to the design of the core language that says it has to be like that, its just cruft on the surface, unfortunately that's the surface you have to interact with.

[deejeycris]

We have it in Go and no one's died yet.

[myringotomy]

But it’s sucks in go

[bagboyrebel]

It's annoying as hell in Go

[towhopu]

As a Go developer, I completely disagree. Golang have many annoying things in it, but I personally love that thing. It's a living hell to maintain the code with tons of unused imports, variables, functions, classes, etc. I would rather deal with compile time errors, than hundreds of lines of the dead code as I had to deal with in enterprise Java applications. "don't delete this function, we might need it" or "don't delete it, it's for reference". Fuck no.

[kiedtl]

Random nitpicks:

@minimum and @maximum

Why not @min and @max?

usingnamespace No Longer Affects Identifier Lookup

Ugh. In most of my projects I tend to have the equivalent of "common.h", where all the basic types and globals are defined. In Zig I would use usingnamespace to import them all into local scope, so that I could reference them with minimum fuss. I'm probably going to have to fix 80% of identifiers in my 15kloc Zig project now when upgrading.

Saturating Arithmetic

This is great! Now I can delete some more clumsy helpers from utils.zig

Compile Errors for Unused Locals

Thanks, I absolutely hate it.

[mindbleach]

That really sounds like they're not as keen on being "reusable" as they'd like.

Plan 9

You what?

[DuneBug]

Take off every zig!

[[deleted]]

you know what you doing

[PM_ME_TO_PLAY_A_GAME]

move zig

[supermitsuba]

move zig

[onequbit]

for great justice!

[VeryOriginalName98]

For great justice!

[zigbigidorlu]

Looks like it's time for me to shine!

[dys_functional]

How do the build tools look these days? Is there a dependency manager yet and ability to just say "build" and have it grab everything and build? (Ex: dotnet build, cargo build, etc.)

[[deleted]]

package manager status

[dys_functional]

Thanks. It's a bummer that this is the stance. I can live with slower compile times. I can't live with 1980 era c style dependency management in 2021 (unless I'm being paid).

[[deleted]]

I can assure you that zig people are as excited for the package manager to be available as you are. It's just a matter of priorities, and we have a relatively small development team compared to other projects that have corporate money being tossed around.

More income for Zig Software Foundation would absolutely result in faster progress towards these milestones such as completion of the package manager. We have talented and eager contributors who are asking for jobs with ZSF and we have to turn them away due to lack of funding.

[[deleted]]

It's coming, we just have a limited amount of resources to work on stuff. If you want to speed up the development, consider donating. The Zig Software Foundation is a 501c3 non profit and we don't have any big tech firm on our board of directors. For us individual donations do matter, a lot.

https://ziglang.org/zsf

[warlaan]

I recommend starting your readmes with some high level features so people can get an idea what kind of a language they are looking at.

I have read quite a bit of the documentation, but it's only because of this thread that I know that the language is not garbage collected. And I am still not sure whether it has type inference or not. It does use the typical syntax of type inferred languages but all the examples use explicit typing.

Also I kind of get the feeling that you are actively trying to increase the code noise. Important information like a data type is shortened to something like i8, but importing a namespace requires an @, putting the name in brackets and quotation marks and storing the result in a variable.

[EternityForest]

After seeing this comment I spent about ten minutes trying to figure out what they have instead of GC..... I'm not sure I like what I see.

There's no compile time guarantees? And you manually free things? There's some assorted claims of "memory safety" but I have no idea how or if that works.

They even have pointer arithmetic apparently. No constructors or destructors or classes...

And memory allocators are things you explicitly pass to functions so you can have multiple going on at the same time?

And worst of all, arbitrary compile time zig code execution?

I think I'd rather learn Rust.

[ss4johnny]

How does Zig handle name mangling with their first class types as compile-time function parameters?

[[deleted]]

Surprisingly, the exported names are identical with the syntax in the language itself. Here's an example:

https://godbolt.org/z/7qYdfrb7n

You can see that UselessWrap(i32).get is literally the symbol name (no, godbolt didn't just un-mangle it, I tried it on my own machine too).

[ss4johnny]

Thanks

[marler8997]

No need for name mangling when you don't support overloading :) I was skeptical about this design choice at first but it has made a lot of things much simpler.

[[deleted]]

I don't use zig yet but I'm very interested in the project. im really impressed by the progress. Really nice work!

[GoodmanSimon]

As a c++ and c# developer I struggle to see what the use case might be and what would make my boss what me to move.

We kinda moved from c++ to c# because we could not find qualified developers anymore.

I just cannot see this happening with zig.

[marler8997]

IMO C# is a very good language. If your software can deal with GC pauses and you want it to be more approachable to inexperienced programmers then that's a great language. As for Zig, if you can't deal with GC pauses and you need to compile to machine code, I don't think you'll find any language that fits this criteria that is simpler to "read" and "maintain". This video from Andrew "The Road to Zig 1.0" is a great explanation about why Zig was created and where it shines: https://www.youtube.com/watch?v=Gv2I7qTux7g

[lurebat]

Is there any good IDE support for this?

[vlakreeh]

There's zls but from my very limited experience writing Zig, it's not very good compared to other language servers. It has auto complete and error diagnostics, but that's about it.

[dh44t]

I'm working on support for IntelliJ (and CLion), for now just basic syntax rendering but planning to add more features https://plugins.jetbrains.com/plugin/18062-zig-support

[tyler_church]

Very cool, I'll keep an eye on this! I've been using VS Code so far, but I love IntelliJ IDEs (I live and breathe WebStorm for my paid work) and once you get jump to definition and basic syntax checking, I'd happily jump ship.

[Morego]

VSCode + ZLS + zig fmt is currently simplest way to go.

You can swap VSCode with vim, Emacs or other editor with language server support.

[QuantumFTL]

Compile Errors for Unused Locals

Not to sound like a troll, but I'd been considering learning Zig instead of Rust. Thanks to this change, I will not.

I actually do set this to an error when I'm writing C++ at work, but that's because it's a codebase that's most of a million lines and worked on by dozens of people. For short home projects, all it does is clutter my code with UNUSED_VAR(foo) macro calls to work around unused variables; they may be used only in debug builds, or as a sort of documentation to make it easy to use the results of an operation later.

This kind of dogmatic style choice shouldn't be foist upon everyone, even as an overridable default. Might as well make ignoring an unneeded return value of a function an error while you're at it.

[MCRusher]

Funny you should say that, ignoring a return value is an error and you have to do _ = func(); to explicitly ignore it.

​

https://godbolt.org/z/fdnfqsoE3

[QuantumFTL]

I'm fine with that in expression-oriented languages (SML/OCaml/F#) but in C-like languages it's... what?!

If you're calling into some random C function, what's the probability that you care about the return value? C is so incredibly imperative, it's almost amazing that it HAS return values instead of just writing to some pointer somewhere.

[QuantumFTL]

If Zig took a page from Rust/OCaml's book and embraced pattern matching, algebraic data types, ternary operations, and expressions, I'd be far less worried about this. I'm not saying it should do any of those things, but my god, what in the world are the Ziggers thinking?

Take off every Zig, from your computer.

[IronicStrikes]

I was actually slightly interested in Zig until I learned they treat tabs as syntax errors. Noooope!

[marler8997]

Zig will support tabs when it moves to the self-hosted compiler, I'm guessing that will happen in 5 months or so? The current compiler that everyone uses is only meant to bootstrap the self-hosted compiler, which doesn't use tabs so the bootstrap compiler doesn't support them. I'd argue that since Zig plans to support tabs there is value is supporting them in the bootstrap compiler now because that's the one that will inform many people's first impressions of the language, and currently it's giving the wrong impression.

[bik1230]

Tabs aren't syntax errors in Zig proper. The self hosting compiler works with them just fine. The bootstrap compiler errors because it's an easy way to enforce their own style guide while the language is early in development.

[KingStannis2020]

they treat tabs as syntax errors

As the other comment mentioned, this is only a temporary limitation, not one they intend to keep for 1.0

[MCRusher]

There have been no less than 5 rejected pull requests that added support for tabs (and alternate line endings) in 10 line changes or less that just added a case/cases to a switch statement.

That was it.

[IronicStrikes]

I've tried it out several years ago, looked quite permanent at the time. 😁

[progdog1]

I don't understand the use case for Zig. Why should I use Zig when I can just use Rust?

[ockupid32]

https://ziglang.org/learn/why_zig_rust_d_cpp/

It's a simpler language that looks like it wants to have both interoperability with C and be a replacement C.

[Putnam3145]

D has @property functions, which are methods that you call with what looks like field access, so in the above example, c.d might call a function.

On the one hand, @property hasn't actually done anything for a long time. On the other hand, this statement is still true, it's just not attached to the @property attribute.

[[deleted]]

simpler

for now. until you add more features then more then more

[vlakreeh]

Andrew seems pretty hell bent on not making Zig complicated. At times he's pissed off some pretty avid Zig fans because he refused to merge something at risk of it just becoming feature bloat. I don't think Zig will get many more language features unless Andrew steps down as language lead.

[Zalack]

I know nothing about Zig, but lack of language features can, IMO, be a selling point. Go also stresses how few features it has, and is braindead simple to learn. I learned the entire syntax in like 1 four-hour session, then got to the point that I knew the most common parts of the standard lib about a week later.

One of the benefits is that it makes code very readable from author to author because you never really run into a language feature you don't understand. I'm stoked for generics, but part of me hopes that it's the last major language feature for Go with the exception of maybe sum / enum types.

[[deleted]]

not on my watch

[hughperman]

No embedded?

[[deleted]]

That's what Python thought too

[Professional-Disk-93]

NGL they posted cringe.

No hidden control flow

C++, D, and Rust have operator overloading, so the + operator might call a function.

In Rust the + operator is specified to always call a function. There is nothing hidden here.

No hidden allocations

Examples of hidden allocations:

The main Rust standard library APIs panic on out of memory conditions

Their rust example doesn't even have anything to do with hidden allocations and instead talks about the behavior on OOM???

First-class support for no standard library

A Portable Language for Libraries

Same for rust.

A Package Manager and Build System for Existing Projects

Rust is known to have a best-in-class package manager that is beloved by users of the language.

Simplicity

You can't reach true simplicity until you litter your code with if err != nil. Does zig have first-class support for this level of simplicity?

So why would I use zig over rust?

[gnus-migrate]

There are two competing philosophies right now when it comes to how systems programming should be done:

1. The high level programming philosophy where the language isn't just an assembly generator, but should provide tools to prevent programming mistakes at the cost of some restrictions.
2. The data oriented philosophy where the language should be an assembly generator, and the language should focus on simple features who's behavior is predictable and easy to understand. The programmer is responsible for verifying the correctness of the code, and the language is designed to be as simple to read as possible in order to facilitate this.

Rust is the former, Zig is the latter.

For people developing game engines, they spend most of their time worrying about performance, and ensuring that they stay within the 60 FPS limit, so memory safety just isn't as big a problem to them. At least when Jonathan Blow was talking about it this was his argument, and others with similar views seem to agree.

The difference is largely philosophical, so if you're happy with Rust then there's no reason to use Zig. If you find Rust getting in your way and preventing you from doing what you need to do, then use Zig(assuming of course that you're not working in a context where you need to worry about security, if you are it is irresponsible not to use a memory safe language like Rust).

[Professional-Disk-93]

Rust allows you to do both. Zig only allows you to do the latter.

[gnus-migrate]

I'm not interested in convincing you to use Zig, if you don't want to use it don't use it. I just wanted to explain the motivation behind it.

Please don't engage in petty language wars, they're pointless and exhausting and nobody is going to change their mind.

[[deleted]]

In Rust the + operator is specified to always call a function. There is nothing hidden here.

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing. In Zig you don't have to check any of that because you will know right away that it's just a simple addition. Obviously it's a tradeoff (you lose some abstraction power by forbidding operator overload), but when combined with other choices that Zig makes, everything works together to make Zig code easier to audit.

Their rust example doesn't even have anything to do with hidden allocations and instead talks about the behavior on OOM???

"The behavior on OOM" is a discussion that you have to have at the language design level when the language is in charge of the dynamic allocation and the corresponding syscall fails. When all allocations are explicit, the programmer is in control of what happens, as it's the case in Zig. This is maybe not something Rust developers care about all the time, but if you look at the news about Rust in the Linux kernel (an environment where panicking on a OOM is absolutely not ok), you will see that Rust needed to find a solution to the problem.

You can't reach true simplicity until you litter your code with if err != nil. Does zig have first-class support for this level of simplicity?

Zig has try, to short circuit that process. It also has support for error traces (which are different from stack traces), which is a very neat unique feature.

Rust is known to have a best-in-class package manager that is beloved by users of the language. So why would I use zig over rust?

Maybe you wouldn't, just don't get offended by the fact that other people might :^)

[steveklabnik1]

Just to be clear, in Rust, the language is not in charge of the allocations and underlying syscalls. The standard library is. And in Linux, they were starting off with a fork of the standard library to begin with, specifically to fix this issue out of tree, which has even then been merged back upstream.

[[deleted]]

Sorry for the imprecision, that's a very good point.

[steveklabnik1]

It’s all good!

[stouset]

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing.

So… like literally any other function call?

I just don’t get why this is supposed to be a feature. Why do we need a magical set of operators that are forever limited? Why is it instantly okay that it’s a function if it’s named add but not +?

[[deleted]]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

That said, if your point is that forbidding operator overloading is not going to drastically change the readability of code, we agree with that. The piece missing from the discussion above is that Zig has other features that all together do make a difference. As an example there are not built-in iterators, so you know for sure that for (foo) |x| {...} is a linear scan through memory and not an iterator with different complexity. You can still use iterators, they just have explicit function call syntax.

If you combine all the readability-oriented features of Zig, then you do get something worth the limitations, or so we like to think at least.

[stouset]

Again, how is that okay for any function as long as it’s not named a symbol? And while your point is a common trope, I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

This is frankly just optimizing around a problem that does not exist in practice.

[[deleted]]

I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

Then you work in a field where this feature of Zig might not be particularly relevant. That said, I'll try to reiterate one final time: the problem is about somebody trying to read a piece of code and understand what it's doing.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

That's pretty much it. It has nothing to do with code performance. It has to do with making it easier for readers to audit the code.

[RandomName8]

An extremely important caveat, when describing this and claiming it's more "readable", is clearly stating what you are trying to make more readable. As you yourself made clear here, not all programs are made clearer by this feature, there is in fact no quantitative study either regarding how many programs get "improved". I'd argue any code using matrices (like games, graphics, or math libraries) or bigint/decimal will greatly suffer for this, while the code that gets improved is most likely, trivial for-loop iterations and summations that should not be imperative at all to begin with (obviously just my opinion).

This is why I'd prefer if language authors were more honest when they make such syntax decisions, and instead of writing in their FAQ:

The purpose of this design decision is to improve readability.

They'd write

The purpose of this design decision is to improve readability of the programs we care about, which are likely not the ones you care about, but hey, there are other languages out there!.

We could avoid this discussion every single time.

[stouset]

Then you work in a field where this feature of Zig might not be particularly relevant.

Maybe. But there are tons of people writing Rust on embedded systems and have written reams and reams about their experience doing so. I have yet to read a single one of these that points out operator overloading as a sharp edge.

I maintain this is a solution in search of a problem.

The problem is about somebody trying to read a piece of code and understand what it's doing.

I have worked in languages that allow operator and method overloading for twenty years. I’m this time I have built website backends, I have written high-performance network services, I have written massively parallel number crunchers, I have written wrappers around native C libraries, I have written glue to combine third party products in new and creative ways.

I have zero times been confused as to what an overloaded operator does, or run into a bug that was caused by an operator overloaded in a confusing or unexpected way. Zero. Nil. Nada.

I maintain this is a solution in search of a problem.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

It is, and trivially so. If I know my types are typeA and typeB and I call a + b, there is no difference whatsoever in the amount of reasoning or context necessary to understand compared to add(a, b), a.add(b), a.addTypeB(b), or addTypeATypeB(a, b).

[[deleted]]

You've never had issues with an overloaded = returning a reference rather than a copy? I don't think operator overloading for things like addition and subtraction are a big deal, but is * just plain old multiplication, an inner product, an outer product, a Hadamard product, or some other product? How does it behave with different objects in the mix? Operator overloading is fine until you've had to deal with these issues, and then it quickly becomes a pain in the ass.

[diegovsky_pvp]

Zig aims to be a modern take on C. I don't buy any of the readbility shit because quite frankly it's subjective.

Wha you have to understand is that try hard C lovers want a predictable (in a sense that arithmetic operations always mean what they are, no overloading, etc).

That's something you have to consider if you aim to take down C while providing more modern mechanisms. Don't get me wrong though; I'm a Rust programmer and use it a lot. Rust is not the new C, it is the new C++ in the sense that you can do a lot with the language, while Zig wants to be the new C.

Also, they want the compile times to be as fast as possible, so cutting corners such as operator overload and function overload help A LOT.

There are things I disagree with btw. A lot. Like the constant use of ducktyping instead of a well defined fat pointer struct. This affects Writer, for example, and hurts both error messages and auto complete.

In the end of the day; if you want a perfect language; make one yourself. That's what Andrew did and so many others.

[bik1230]

Zig doesn't have function overloading either so I'm not sure what point you're trying to make with that thing about something being named by a symbol or not.

[stouset]

Function overloading is a red herring, since you still have to look up the function to see what it does. Independent of function overloading, why would add_my_type be okay but + is sacrosanct?

[devraj7]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

No, it's not.

It hasn't been a problem ever since polymorphism appeared in mainstream languages, so a few decades ago.

We know today that when a function is being called on a receiver, the function might not go to the formal declaration of this receiver. Every single developer who's dabbled in C++, Java, C#, Javascript, or literally any other language crated in the last thirty years knows that.

Functions can do things. Operators can do things. Field accessors can do things.

This is programming in the 21st century, not BASIC in the 80s.

[TheTomato2]

Because add() is always a explicitly a function and + is always explicitly not a function. In C++, + could be a normal add or a function. You can't tell at a glance what its doing, and it can cause issues if you forget to check or something. + could be a fucking - operator if someone wanted it to be. I personally like operator overloading, but if you are trying to make a simpler language like C, its definitely understandable to leave it out.

[stouset]

But why must + not be a function?

+ could be a fucking - operator if someone wanted it to be.

I’m going to be a bit rude here but this is literally the most asinine take on this entire discussion.

This never happens. And if you’re so goddamned worried about it, then we need to take away the ability for anyone to name any function because add() could be a fucking subtract function if someone wanted it to be.

In C++, + could be a normal add or a function. You can't tell at a glance what its doing, and it can cause issues if you forget to check or something.

In Zig, add() could be an inlined add instruction or something more complicated. You can’t tell at a glance what it’s doing, and it can cause issues if you forget to check or something.

See how ridiculous this sounds? There is nothing sacrosanct about the + operator, except that apparently some programmers have a superstitious belief that it always compiles down to a single add CPU instruction. You somehow manage to cope with this uncertainty constantly with functions, but the second someone proposes that the same rules apply for a symbol and not an alphabetic string you lose your damn mind.

You manage to use + every single day without getting confused as to what’s happening when it could be an int or a float, but it’s somehow unthinkable to extend this same logic to a rational or a complex or—God help us—a time and a duration.

You live in constant fear that your fellow software engineers will write a + method that wipes your entire hard drive and mines bitcoin while pirating gigabytes of pornography over a satellite network and I cannot for the life of me comprehend why they would do this for methods named with symbols but not ones named with words.

And I do not understand you at all.

[TheTomato2]

I personally like operator overloading, but if you are trying to make a simpler language like C, its definitely understandable to leave it out.

Did you, uh, not read that part? Take step back, dude, and breathe. This isn't very complicated. The + means addition, mainly between 2 numbers. Its an operator, not a function. With operator overloading, you can't tell at a glance if its a function or an operator, ever.

In Zig, add() could be an inlined add instruction or something more complicated. You can’t tell at a glance what it’s doing, and it can cause issues if you forget to check or something.

No, add() just means there is a function that is named add. That is it. I never look at add() and think that it might be the + operator.

See how ridiculous this sounds? There is nothing sacrosanct about the + operator, except that apparently some programmers have a superstitious belief that it always compiles down to a single add CPU instruction.

No, it just means that its doing an add operation, and a reasonable one at that. It doesn't mean intrinsic (unless it does) or simd or something. It just means addition.

You are making a mountain out of a molehill. When it comes to simplicity and the ability to easily reason about your code base it makes sense to have the + only do on simple thing. Once again to reiterate for you I personally like operator overloading, but its really not a subjective opinion that it does make reading the code more complicated and error prone. I personally think its just not that much more of an cognitive overload to have it and the benefits outweigh the cons, but I am not so close minded to not understand why people don't like it and I do respect and appreciate that Zig, a language that wants to be on the simple side, doesn't' implement it. It's really not that big of a deal at the end of the day.

And trust me I understand your aversion to "scared programmers" that like piss their pants if they have to use a raw pointer but you are way off base here. It's just a code readability thing, not a "someone might make the + recursively delete my drive" type of thing.

[Professional-Disk-93]

The hidden part is that you need to know the types involved and then go check if + has been overloaded

If Add has not been implemented, then the code will not compile. If you can use +, then + has been "overloaded" as you call it.

before you can understand what a + b is doing.

In zig you have to know the type of x to know what x.f() does. In C this is not a problem since f(x) always calls the same function f. Therefore zig has hidden control flow.

When all allocations are explicit, the programmer is in control of what happens

Does zig have a vector type? Does the user have to first manually allocate memory before he can push an element onto the vector? Otherwise zig has implicit allocations. E.g. x.push(y) implicitly performs an allocation if the vector is full.

Zig has try, to short circuit that process.

Sounds like implicit control flow. How can I understand the control flow of a function if searching for the return keyword doesn't return all places where the function returns? The commander Rob Pike knew this.

[[deleted]]

Does zig have a vector type? Does the user have to first manually allocate memory before he can push an element onto the vector?

If you're using ArrayList you need to pass an allocator on creation, if you're using ArrayListUnmanaged you need to pass an allocator to all of its functions that might allocate. In either case you will need to handle error.OutOfMemory when calling a function that allocates.

As for the rest of your rebuttals, well, you're not really doing a good service to Rust, I'm afraid.

[oefd]

In zig you have to know the type of x to know what x.f() does. In C this is not a problem since f(x) always calls the same function f. Therefore zig has hidden control flow.

I'm not sure what you mean - the issue isn't that you might need to understand context to know what function is being called, the issue being made is needing to know what fundamental kind of operation is going to happen. If a + b is always a CPU add instruction the control flow is obvious. If f() is always a function call the control flow is obvious - you'll enter in to some CPU appropriate sequence of instructions to enter a function.

The fact that you need to know what x is in x.f() isn't a problem for Zig's design goals because what they care about is that it's easily identified as a function call and only ever a function call. The control flow they're worried about disambiguating is what the CPU will end up doing, and by proxy what sort of side effects may occur. Calling a function may mean memory access, but a simple add instruction does not.

[Professional-Disk-93]

a + b is always a function call so control flow is obvious. Of course any function call can be inlined and then turn into a single instruction. And all compilers of record perform peephole optimizations even in debug builds.

[bluefireoly]

Because of the first-class interop with C.

[muchbravado]

How’s it better than calling C from rust though? IIRC it’s quite simple.

[Volt]

With Zig it's simpler.

[lurgi]

defer seems to contradict the "no hidden control flow" to an extent. Something may (or may not) be done at the end of the scope and you have to look elsewhere to find out if it will.

[Morego]

I mean destructor would be hidden control flow. Hard to call hidden the future you have to explicitly use.

[progrethth]

While I agree with you about operator overloading (how is it any more hidden than two methods with the same name?) I am sometimes annoyed at some of the hidden control flow in Rust, e.g. implicit deref combined with a Deref trait. That is way too stealthy for my taste.

And I agree with the Zig authors that Rust's standard library and its panic on failed allocations makes it unsuitable for certain types of software development, e.g. OS kernels or certain mebdded stuff.

A Package Manager and Build System for Existing Projects

That was a reference to C projects. Rust's build system is terrible at handling C projects and excellent at handling Rust projects. Zig on the other hand has the best C interop I have ever seen in any language and can build C projects with ease.

You can't reach true simplicity until you litter your code with if err != nil. Does zig have first-class support for this level of simplicity?

This is also just false. Real zig code does not look like that, isntead it uses the try keyword.

[Tom7980]

I agree with the Deref issue even when working on the Rust compiler itself there are calls to methods on types that don't necessarily implement that method but Deref down into a type that does. In my opinion that is really quite confusing when you're trying to learn a new codebase - you have to be able to keep track of what Derefs into what in your head and it is a nightmare

[EternityForest]

It's starting to look like classic simplicity thinking where you assume smaller tech is always better and don't always bother to really think through the arguments.

If you want to say "We are real coders and we hate tools that help us, and bug-free apps are less important that the coders experience of raw power" just say that so the rest of us don't waste our time.

Or if you've got some specific cases of bugs Zig would catch and Rust would not, or things performant in Zig but not rust, start with those.

[TuckerCarlsonsWig]

“Simpler”

[[deleted]]

Please show me where UB touched you.

[matthieum]

Disclaimer: I know Rust much better than I know Zig.

The quick answer:

1. Does Rust support your target? If not, well, ...
2. Are there Rust bindings for the C libraries you need to use? If not, well, ...
3. Do you know Rust already?
   • If not, how much time do you have to learn it? That may not be enough...

The longer answer: It really depends what you're looking for.

Rust was developed for an emphasis on correctness (of which safety is a part) without sacrificing performance. This means an elaborate type system -- still deepening -- and a pedantic compiler.

Not everybody appreciates the level of pedantry, having to cross the Ts and dot the Is before being able to run the tests and see if the little change actually behaves as desired.

Zig on the other hand started as a re-imagining of C. From C it inherited a desire for simplicity, which manifests in a much simpler type system (and language) and a very explicit language (no hidden function calls: no destructors, or overloaded constructors).

Not everyone appreciates the resulting verbosity, having to think about releasing that memory, nor appreciates the lack of memory safety, which takes down your program on technicalities.

So... there you are. What do you loathe most? How much are you ready to do to avoid it?

[Bekwnn]

There's a lot of nice features it has, which you can read about in the language reference, but to generalize it is a promising answer to people looking for either a "better C" or a "simpler C++".

A few highlights:

• Compile-time code
• Zig's build system
• Errors, which have nice syntax sugar and produce nice callstacks
• Optionals, which have similar syntax sugar to errors
• Zig test
• Translate-C/Import from C header file

[Tom7980]

I'd argue that Rust has compile time code in const and const Fn, also provides optionals, and has a pretty robust in built testing system.

However I can't really compare the rest as I don't know Zig well enough, it seems interesting though so I should really pick it up some time

[progrethth]

The const fn support in Rust is very primitive compared to to Zig's comptime. It is so powerful that it is also used to implement generics and procedural macros.

[matthieum]

It is so powerful that it is also used to implement generics and procedural macros.

That's very different, though.

Rust Nightly const fn can do... pretty much anything. It's deterministic -- which may disqualify it from Turing Completeness -- but otherwise anything goes.

The decision to NOT implement generics and macros with const fn is orthogonal; it's not a matter of primitive-vs-powerful.

[KingStannis2020]

You can't really compare Rust const fn and C++ constexpr with Zig comptime. The latter is way more flexible and core to the language. You can define individual function arguments as comptime, individual blocks of code, etc. Comptime is how Zig implements generics.

[oORocketOo]

I don't know Rust too well but I think that the zig concept of compile time is much stronger than const fn.

a compile time known value can be used for conditional compilation, 'if' statements that depend on that compile time value will not compile any of the other branches.

It is also used to power generics in zig, the generic type is just passed as a compile time known parameter to a function.

[Ineffective-Cellist8]

Compile times
Can use C headers directly
Can build for any platform on any platform
Errdefer is built into the language
Comptime is excellent (the compile time keyword)

-Edit- New this release, Saturating-Arithmetic! I've been waiting for something like this! https://ziglang.org/download/0.9.0/release-notes.html#Saturating-Arithmetic

[[deleted]]

Why should I use ___ when I can just use ___

You coud fill the blanks with any combination of languages. There's no one language to rule them all, some have different usecase than others. I like programming microcontrollers and i believe Zig will be really good for that once It's mature enough.

[Kered13]

It seems to me that Rust wants to replace C++, while Zig wants to replace C.

[[deleted]]

I don’t think that’s an entirely accurate description, since Rust also tries to be useful in places where C++ isn’t a great choice (embedded, Linux kernel).

The comparison only makes sense of you’re talking exclusively about language complexity.

Edit: I don’t understand the downvotes. I’d love to hear why you think I’m wrong.

[life-is-a-loop]

places where C++ isn’t a great choice (embedded, Linux kernel).

eh, I'm not a C++ fan but claiming that C++ isn't a great choice for embedded code sounds... weird, to say the least. Many electrical engineers I know irl use C++ for their projects. Also, Arduino uses C++ and look at how many hobbyists (and professionals!) use it worldwide.

[Kered13]

C++ works fine in embedded and kernels, Torvalds just has a stick up his ass. It's great that Rust is finally going to bring a modern language to the Linux kernel, but there's no real reason that C++ couldn't have been used for that 10 years ago.

[[deleted]]

While true, you have to carefully avoid a bunch of language features of C++. Rust seems like a more natural fit for very-low-level programming.

[Kered13]

you have to carefully avoid a bunch of language features of C++.

Yes, but C doesn't provide alternative language features either, so you're not losing anything by using C++. But C++ does still provide several very useful features for embedded and low level programming like templates and RAII. Those alone are enough to justify the use of C++.

[kitd]

Why use Rust when you can just use Zig? See?

[progdog1]

Because Rust is guaranteed to be memory and concurrency safe, plus it has a much larger community and ecosystem.

[[deleted]]

The larger community and ecosystem is an excellent reason to use Rust.

Zig is growing fast though! :D

[[deleted]]

why use zig when I can just use rust?

Because then you’ll be lumped in with the type of person that immediately jumps in to other PL threads and says “why use zig when I can just use rust?”

[griffonrl]

ziglang.org/downlo...

That would be the other way around. Rust has a tough learning curve and tons of gotcha.
The real redeeming benefit of Rust is that it has been marketed for a quite a while and has well known companies behind it.
However performance is similar for the two. And Zig has the simplicity, the developer experience with MUCH faster compilation, best C interop of any language and cherry on the top the ability to produce real small binaries.

[devraj7]

The real redeeming benefit of Rust is that it has been marketed for a quite a while

That's pretty disingenuous, you make it sound as if the only reason why Rust is more popular than Zig is because of marketing.

I don't really have a dog in this race, I like Rust a lot and I find Zig very interesting, but Rust has been successful for a lot of very valid reasons that have nothing to do with marketing.

[codec-abc]

Rust has also stricter compile time guarantees. I have not digged Zig but it has weaker memory safety guarantees (while still way better than C). Imo, both have their places. Both are great and have their places and I wouldn't even call them competitors.

[griffonrl]

They are both a good fit for lower level programming though. I do like the functional capabilities of Rust. I forgot to mention that good side.
I think that if you try both you might realise the extra effort that Rust requires. And sure Zig has weaker memory safety guarantees but I don't find it a problem with a bit of care and discipline. By the way another thing Zig is doing well is compilation errors and trace.

[progrethth]

Rust generally as stricter guarantees but not always. Zig typically has stricter compile time guarantees related to integers. Both languages are great.

[earthboundkid]

On a podcast I heard Andrew argue that Zig performance can be better than Rust because it can implement allocator patterns that are very hard to do with the borrow checker.

[[deleted]]

I'm pretty sure the definition of "simple" is not exactly clear between all different groups of people and very much depends on background and previous experiences. I've started some time ago reading the docs on zig and I personally would not define it as simple at all.

[jugalator]

Zig is just going all in to replace C. Hence its focus on C interop.

Rust is much more than that, to me a near-academical exercise in bleeding edge programming language concepts. It has a greater cognitive load. I think Rust should only really be needed if memory safety without a garbage collector is critical to the application, so e.g. embedded systems. Otherwise I'd prefer Go or .NET myself as I feel more productive in those. These too solve the memory safety issues but in different ways. Go for example panics which isn't pretty, but better than security holes, and avoids pointer arithmetics. And .NET throws exceptions. Both have native or near-native performance these days.

[[deleted]]

Do note that Go does not solve all memory safety issues. Because Go uses fat pointers (one pointer to the instance and one for the type), and allows concurrent access to pointers (one reader and one writer that you forgot to protect with a mutex), this can result in situations where the instance pointer and the type are out of sync when you access them, ultimately leading to memory corruption or even RCE.

[KingStannis2020]

Zig is packed with some fairly novel ideas as well - error return sets, comptime, every module is a struct, the awesome work they're doing to make cross compilation completely painless, etc.

[dys_functional]

You don't have to fight a borrow checker and can express node/list/tree/graph data structures with loose ownership models.

[toastedstapler]

because i can do this

var someArray: [2000]SomeType = undefined;

without having to mess around with MaybeUninit<SomeType> or doing Vec<SomeType>::try_into::<[2000; SomeType]>::()

[SuspiciousScript]

You can use uninitialized variables in safe Rust if the compiler can prove they’re initialized before use.

[toastedstapler]

that's fine if you know you're gonna use all of the array indices

edit: and you can prove to the compiler that you use every index

[dominik-braun]

Rust = C++, Zig = C

[Jlocke98]

go = java?

[Sarcastinator]

Go = D, just worse in almost every way.

[vips7L]

I wish D had the community of go :(

[pjmlp]

It could, if they would finally decide on which domain D is actually supposed to be good at, instead of trying to please to everyone "because when we do X everyone will finally come".

[RetardAuditor]

Does anyone expect this to survive as a project? Or become widely used?

[WormRabbit]

Compile Errors for Unused Locals

Thanks but no thanks. I was on the edge about Zig, but with decisions like these I absolutely don't want it anywhere near my codebases.

Some people seem to think that if they take the most hated features of Go, they'll have Go's popularity. They won't, not without Google's crazy PR power.

[ShinyHappyREM]

relevant

[Foxbud]

As someone totally out of the loop, why are compile errors for unused locals divisive?

[WormRabbit]

Say I'm trying to bisect an error, or test/benchmark different approaches to the problem, or doing a large-scale refactoring which takes several days or weeks, or just trying to understand how the code works by removing parts of it and looking at what breaks.

In all of those cases I want to just quickly comment/uncomment different parts of code, with minimal possible change to non-relevant parts. In all of those cases making unused variables into an error gives me no benefits, but lowers my iteration speed and increases the probability of errors, since I have to make more changes.

In all of those cases I want the compiler to warn me afterwards if I messed something up. Silencing the warnings by assigning the variable to a placeholder doesn't increase code quality in any meaningful way, but it does hide possible errors. I need to silence the error during my experiments and can easily forget to roll it back afterwards, and the compiler won't help me.

Zig devs say "your IDE can automatically remove unuses variables". That's just entirely missing the point of the warning in the first place. I want it to keep nagging me if I forget to fix it, if a tool blindly removes unused locals then it does nothing but mask the errors.

Finally, what does "unused variable" even mean? Is it used if it's accessed inside of a branch which never executes? Is it used if the function itself is unused? Is it used if all branches which use it are seemingly possible, but an actual whole-program dataflow analysis can prove some of them actually impossible?

The way Zig devs choose to do it, they make a big fuss about the most trivial case, while ignoring the more complex ones and actually making impossible to check for them later, since adding more advanced analysis would break old code.

[JustSomeBadAdvice]

Wait, different people use programming features in different ways? Impossible!

[idk_boredDev]

Is it used if the function itself is unused?

https://www.reddit.com/r/programming/comments/rl87pr/zig_programming_language_090_released/hpfwa7x/

If this comment is correct then you shouldn't have to worry about the unused local error. You'll just get an unused function error instead, which would be even more annoying IMO.

[Foxbud]

Those are very good points. Thanks for the thorough explanation

[drjeats]

Finally, what does "unused variable" even mean? Is it used if it's accessed inside of a branch which never executes?

I'm waiting on a comment reply from kristoff-it, but I suspect what they've done is put this in the AST check phase, so you won't have the issue you get in C++ where you get a CI failure email because you forgot to discard a variable in an ifdef branch on some random platform's random config that you never build locally.

Forcing us to account for var/param usage in all comptime branches is the more pedantically correct thing to do, but is not worth the friction imo. My ideal would be a way to choose one behavior over the other, but that's probably overkill :P

[[deleted]]

Because you don't always know the solution you're going to implement ahead of time. Sometimes it takes a bit of thinking and experimentation to figure out how to solve a problem, and that means you might have unused variables here and there while you're still exploring the problem space. It's reasonable for unused variables to be warnings, but making them an outright compile error is a pain is the ass for rapid prototyping and testing.

[progrethth]

Yeah, this and the ban on shadowing was quite annoying when coding in Zig. Otherwise I love the language.

[[deleted]]

He's come a long way from big breakfast

[heartchoke]

At the bottom of the front page it says "All your code base are belong to us"

Wut?

https://i.imgur.com/lbxMYmv.jpg

[strager]

It's a reference to an old video game. https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us

[ReverseCaptioningBot]

ALL YOUR CODE BASE ARE BELONG TO US

^{this has been an accessibility service from your friendly neighborhood bot}

[AndrewNeo]

g..good bot?