[portly]

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly".

For me it is now the go-to "tinker in my garage" language.

[xyzsparetimexyz]

> But nothing gets in your face how to use the programming language "correctly".

It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me

[foresto]

> It doesnt let you have unused variables

Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.

It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.

When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.

When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.

What an aggravating, disruptive, and completely unnecessary waste of my time and attention.

I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.

[trueno]

> Ugh. This is something I hate about Go

Yeah it drives me insane. Working in any ide's golang lsp/plugin that tries to solve this for you every time you hit save also drives me insane. Feel like something is lost experiencing/learning/becoming masterful at a language when these types of decisions get automated while you're hand crafting.

I actually really valued my exploration into C where if i did that, id get a fat warning on compile, but I could still proceed to test my stuff. When I'm ready to commit to some cleanup efforts which is usually a headspace-thing, then I go cruise around and cleanup unused variables.

[yarn_]

Well its also just idiotic in terms of how some huge number of people write code.

I know I'll need so-and-so import, so i write it at the top of the file before i even start, I press ctrl-s and it dissapears... I honestly laughed out loud the first time i used gopls.

[defen]

I love Zig and I am generally very happy with Andrew's benevolent dictatorship and the benefits of having one single smart tasteful person in charge of decisions, but the unused variable one really hurts. My guess is that he's seen what a mess C code can be with regard to warnings and so is just totally unwilling to compromise by adding the concept of warnings to Zig. But if I had one wish about the language, it would be for a command-line flag to disable unused variable errors. So much effort has been put into making iteration fast (all this build system stuff, the custom backend, incremental compilation) and then there's just this giant blocker preventing fast iteration on the editing side.

[galaxyLogic]

Why not just comment out variables you "want to keep around" but are not used anywhere?

[throwawayk7h]

it's just annoying to have to do that.

[galaxyLogic]

The converse is that if you have many unused variables some of them are used in some contexts but not others and then when you use FIND to find occurrences of a variable you will find many which are not relevant and some which are.

Overall the code gets smaller and easier to understand when it only has things that need to be there. If you comment out a an unused variable you can see from find-results that in effect that occurrence cannot matter.

Unused variables are "noise" that hide actually important things.

[saintfire]

The unused variable error drives me insane

If they wanted the release build to be an error I wouldn't care. Having the current solution be "have the editor automatically change code to include or remove the underscore" is so wrong to me. Just invented a problem that needs tooling to modify source code to fix.

[latexr]

> It doesnt let you have unused variables

Andrew Kelly on that:

https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s

Looks like you might be able to get rid of the error easily with annotations.

[xyzsparetimexyz]

So your ice turns 'let unused = func();' into 'let _ = func();' automatically? Okay but then do I later have to grep for 'let _' to find all these unused variables and delete them? This is silly and a has consequence of zig not having any system for warnings

[cdud3]

Why not ignore unused variables in debug and warn in release mode?

[xyzsparetimexyz]

Warning everywhere makes sense. BMG zig doesn't have warnings at all. Just errors

[yarn_]

as a fan of him this rationale did not make a shred of sense

"Both parties can have their preference" - this was already true of C where you can just turn enable unused variable warnings or turn them into hard errors, this has nothing to do with the decision.

I also don't want my lsp randomly rewriting my code (???)

[MrBuddyCasino]

Very nice interview. The clarity with which Andrew Kelly speaks is refreshing.

[afirmativ]

I agree - can't create and toggle between rough code sketches of functions in a source file without these features. It's more than annoying.

[tomjen3]

You can discard a variable like so:

_ = variable_to_discard

I am sorta unsure why Zig doesn't have multiline comments, but its also not at version 1 yet, so that will likely come, along with better IDE support.

[galangalalgol]

What do you like to ise those features for?

[xyzsparetimexyz]

In rust, having unused variables as a warning (but not an error) let's you refactor code, test it and see what is now unused as a result. You can then remove the unused items. Zig requires you to remove the unused items (e.g. with '_ = ...;' which is then something you might forget about) before testing, increasing friction.

Multiline comments are less important, but its still convenient for commenting out large chunks of code. IDEs make this a bit easier when you can press e.g. Ctrl+/ to comment out the selected lines with //, but it doesn't work in all cases.

The friction stops zig from being fun imo. A shame because I really like comptime.

[galangalalgol]

Thanks, there is always a risk of people jumping on replies like that to scream that you are doing it wrong. I just wanted to see how other people do stuff. Hope everyone stays nice.

[Weebs]

Not the person you replied to but I leave unused variables as future TODOs. It's a warning in F#. I also often use them for inspecting data in the debugger

[ACCount37]

Is it really that good?

My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

[dmit]

Have you ever thought "Ugh, this bit of Python code is running much slower than I expected on my computer. Wonder if anyone has written a native library for this"? That's probably the closest use case for someone who matches your description -- a language that is much more ergonomic, much more 'modern' feeling (in all the good ways), while still extremely compatible with C.

As for the language itself, it's going to be more verbose than your Python code. Cons: you'll have to spell out a lot of things that you thought were obvious assumptions. Pros: you will be able to look at a page of code and know with a great degree of certainty that there are no hidden gotchas. No monkey patching, no __init__. Basically, it just does what it says on the tin.

And finally, about the std lib and batteries: there's HTTP(S), compression algorithms, hash algorithms, RNG, I/O, the basic data structures you'd expect, JSON. Third-party libraries, if you choose not to vendor, are handled by including the repository url in a file (also automated by a CLI command), and then adding it to the build script (not automated). The `zig` command handles fetching and ensuring sanity, but otherwise assume a bit of elbow grease will need to be involved.

[archargelod]

That's actually a great argument for Nim[0]. Easy interop with C, native-speed performance, and a syntax very close to Python in both readability and how quickly you can get something working.

Batteries included, automatic memory management without a conventional GC and metaprogramming - is a really cool combination.

[0] - https://nim-lang.org/

[tatjam]

Aggh if only its LSP was better! I have always run into issues when using Helix with it (it kept crashing), and I'm absolutely spoiled by good LSPs in other languages :(

Wish I had the time and skill to actually contribute to the LSP, if you have ever used Nim it's a seriously underrated language.

[elcritch]

Araq the Nim creator is working on a rewrite of the Nim compiler called Nimony that'll become Nim 3.

It's making fast progress and will provide the basis for a proper LSP! Nimony already supports incremental compilation and parallel which are key pieces for good fast LSP.

[pmarreck]

it is my second choice next to Zig and does have a lot of cool features, for sure.

The nice thing is that all these languages feature easy C interop so you can use a C FFI as the interface between them if you want to experiment with, for example, writing a module in Nim

[ACCount37]

Rarely. Most tinkering tasks just don't have enough heavy duty computation in them to as much as strain a modern CPU. And most of the rest are covered by packages like numpy or pytorch.

For the rare exceptions, I make a C lib and call into it to get my numbers crunched. I get that Zig is a viable replacement for C there. But I don't see it replacing Python.

[miki123211]

And if you really need more performance (or, more often, fast startup times), Go gives you 90% of the speed with 30% of the effort. Rust if you really want to squeeze everything that can possibly be squeezed of that CPU.

[wmedrano]

Zig gives you more control than Rust, which should theoretically lead to a higher performance ceiling.

There's not much magic in Zig. Keep hitting goto-definition and you can eventually see the OS switch statements and syscalls.

[kibwen]

Neither Rust nor Zig give you any more control than the other. If you want raw pointers or inline assembly, Rust supports that.

[tomjen3]

Go does not give you control. Much of the speed comes from choosing the right algorithms - including memory management. In Go you have GC, you don't have that in Zig.

Linked lists are a lot less slow if you use Arena allocation around your hotspots and make sure to allocate space for as many as you thing you need, since they will be carved out of a contigious block of memory and will stay in CPU cache.

Golang also requires you to write more code, as it lags Zigs try operator.

[pmarreck]

that’s not what the benchmarks say about Go, and based on multiple reports, Rust does not scale well into large codebases, which eventually become brittle and very difficult to change

Zig is a return to “no magical effects,” except with reasonable safety

[Philpax]

I would be very surprised to see a large Rust codebase being harder to maintain than a large Zig codebase. The former makes it much easier to maintain invariants at scale.

[Synthetic7346]

Link to said benchmarks?

[kibwen]

[flagged]

[archargelod]

> For the rare exceptions, I make a C lib

The problem is that most people using Python don't have enough expertise in C to do the same.

It also kinda destroys the argument that Python is good if your solution for performance is to use a different language alongside it.

[itishappy]

The argument is that the ergonomics of using Python are worth the squeeze of learning two languages. Are the ergonomics of using Zig really enough to justify replacing Python on the happy path, or would it end up replacing just C?

[tasuki]

I find Python extremely unergonomical. Sure, it's nice to read (pseudocode, yay!) and sure, its library ecosystem is beyond amazing.

But... the LSPs I've tried (and I've tried a bunch!) are all atrocious: false positives and false negatives galore. Perhaps I'm spoiled by LSPs from languages with better type systems. Our code is strewn with (to me) mysterious comments such as `# NOQA 1234` which my colleague uses to make his Python tooling work with the codebase. I'm used to languages like Elm or Gleam in which a LSP error means there is an actual problem with your code, and a lack of a LSP error means the code will compile and run.

[lenkite]

Even if you are fine with Python's speed, its memory consumption DOES effect things and can be an extraordinary pain when you need to fit the result of your tinkering in any sort of constrained environment.

[maccard]

By the time I’m memory constrained even on my laptop the processing cost of whatever I’m doing has gone beyond shoving it in the first scripting language I can find. Every device I write code on has at least 16GB RAM - most of them are 64 or 128

[p-e-w]

Not to mention that where heavy computation is required, Python often has libraries that are much, much faster than anything you can quickly hack together in C or Zig.

[maleldil]

As long as you can express everything you need on the library's terms. As soon as you write a Python loop, your performance plummets.

[bluecalm]

Only if you doing something thousands of people has done before. Anything new, even very simple and you are on your own and Python is 100x slower than naive C implementation on many tasks.

Last little project I remember is writing a solver for a puzzle game my friend published. Python just doesn't work at all for such tasks.

I think you are wrong about speed of those libraries as well. In my experience naive code designed for a specific task beats highly sophisticated general code and it doesn't take a rocket scientist to get huge speed-ups over some well established fast library.

[conorbergin]

I don't think performance has got much to do with tinkering. IMO the real benefit of Zig is you get the flexibility of C with the ergonomics of a modern language.

I like Python as a tool language, and I am very impressed by projects like Micropython, but you always eventually run into a wall. I.e. you are never going to write a compute shader in python, but I assume someone is going to try.

I think the programmer should meet the hardware in the middle, and Python has a few too many layers of indirection to do this well.

[dmit]

> I don't think performance has got much to do with tinkering.

Yes, in general, but also there are cases when you realize you can, idk, parse a CSV file in 0.2 seconds instead of 200 seconds. That kind of improvement unlocks a new level of tinkering.

[norman784]

Zig is low level, so it will certainly not replace your python usage, it is more like a modern C than anything else. There’s a video of a recent interview with Andrew Kelley, if you want to watch it to understand better what Zig is for, it’s on Jetbrains YouTube channel.

[ACCount37]

No, I get that, but Zig being low level is kind of why I don't get why it would be a good tinkering language?

When I want to tinker, I just want my logic to work, first of all. In 9 cases out of 10 that means going for high level. Even if the resulting code works with low level things like binary structures.

[andyferris]

Low-level programming gets a bad name because C has many footguns and the spec leaves much behavior undefined - a fact that implementers use almost adversarially (which I'd support, if the goal was to refine the spec...).

C++ adds more high-level conveniences without actually removing the footguns and undefined behavior (much C code compiles in a C++ compiler).

Zig tries to keep the low-level C philosophy but have things more well factored and well defined. The result is you _can_ tinker in high-level code, yet "drop down" into low-level code as you desire.

(Compared to rust, you get fewer compiler-enforced guarantees, but unlike C the language isn't trying to make high-level code adversarial).

[jcul]

It made me laugh to think of C implementers being adversarial! It can feel that way.

I haven't really used modern C, not sure if it's evolved as much as modern C++, which I feel is a joy to use, and a lot safer. But then I've been writing C++ for decades.

I feel like C evolved from basically syntax sugar for assembly, so that's where all the footguns come from, rather than being actually adversarial.

[robinsonb5]

If some of the things that the C standard left undefined had instead been made implementation defined then the compiler would at least be obligated to do something that makes sense on the target architecture, rather than having license to take the lawful-evil route. (Plenty of architectures have addressable RAM at location zero, for instance.)

For some reason this always brings to mind that moment in Red Dwarf where Kryten, devoid of his behavioural chip, deems it appropriate to serve roast human to his crewmates. "If you eat chicken, obviously you'd eat your own species as well, otherwise you'd just be picking on the chickens!"

[uecker]

Both C and C++ compilers (in fact, they share this part) very aggressively exploited undefined behavior for performance. But I this was certainly not adversarial. Programmers also regularity picked optimizations over safety. I think nowadays the unsafety of C with modern tooling vs the safety of - say - Rust is very much exaggerated.

[pjmlp]

Basically what the world has lost by ignoring Modula-2 and Object Pascal, and going down the C path.

[archargelod]

The spirit of Pascal lives on in Nim.

It's arguably the closest modern language (with a sizeable community) to the Wirthian languages.

[mcdonje]

You have a weirdly restrictive definition of "tinker"

[maccard]

Almost all of my tinkering is “download this thing, cache it (because it’s huge), run a program or a series of programs on it, and package the output up somewhere.” When I’m writing the thing that does the work I’m not tinkering any more..

[ACCount37]

Not really?

I've been places, from embedded bare metal to ML AI, and that "embedded bare metal" end is the one place I don't use Python directly in. Embedded bare metal is just ruled by C forever.

Bit of a shame, because C is kind of bad at its job, but nothing else has the "compatible with everything" badge of honor.

The tooling around embedded devices though? Python.

[cornstalks]

When I want to tinker it’s usually because I want to make something faster than anyone else has done. Does that help illustrate why some might prefer to tinker in Zig, and why your definition of tinker seems a little narrow?

[brabel]

Tinkering means different things to different people! Want to tinker with your hardware, as bare metal as possible? Or extract every inch of performance out of your CPU? Zig is great for that.

[pmarreck]

> I just want my logic to work

what the heck has convinced you that logic is somehow flawed in a new low-level language? LOLLL

[flossly]

You both like different types of tinkering.

Some people put a generator on a tesla cybertruck and call that garage tinkering.

Some people make a go-cart out of a lawnmower and call that garage tinkering.

The first is the "batteries included Python" tinkering, the second is the "low level Zig" tinkering.

[miki123211]

And not only that, if you're doing something in Python, somebody has done it before. Maybe not this exact thing, but something close enough to it. LLMs know it, Stackoverflow knows it, whatever esoteric protocol or file format you're trying to interact with, somebody wrote a library for it in the Python 2 days and has ironed out all the bugs since.

There's no other language quite like Python in this regard. Typescript is a close second, but the lack of metaprogramming facilities, no access to the type annotations at runtime, and the lack of operator overloading make some things needlessly complicated and uglier than they have any right to be.

[lll-o-lll]

“Tinker in my garage” for low level things. If I’m playing around with a custom layer 2 protocol, python is not my language of choice.

Basically, if what you are tinkering needs precise control over the bits and bytes, Zig (or C) are designed for it.

[OtomotO]

That's so funny.

At university we didn't use Python, but mostly Java, C++, C a bit of Haskell and some even more esoteric ones.

Sure thing I got exposed to Python, but to this day, I don't like it.

All that whitespace typing just kills me xD

I am not normally someone who cares the slightest about Syntax.

I've written Rust, C++, C, C#, JavaScript, TypeScript, Haskell, Kotlin, Scala, PHP, and many, many more in my spare time and being paid to... Yes, I've also been paid to write Python and I use it for some scripts instead of bash occasionally, but boy will I never like Python

[danielEM]

Well, I feel you very much about Python! Also was coding in plenty of languages for past 30 years (assembly, pascal, C, D, java, visual basic, typescript, C++, and so on and so for) and every now and then I wonder if that aversion of mine towards indentation based languages (python, nim) comes from lack of enough flexibility of my mind/aversion towards training my brain to use and recognize different coding way or it is simply because it not ergonomic enough once you reach certain skill level.

[tomjen3]

Control. Its a replacement for C that is a lot nicer to work with.

So basically if you either need your Python code to interact with a native library or need more control in a specific place, you can use Zig there.

Zig makes it trivial to control which part of the code e.g allocate memory, so you can guarantee that your rendering or audio loop has no stuttering.

I would still keep Python as the main driver for where dev speed is the most important part.

[FpUser]

I once had to write software that would go through whole bunch of PHP code (more than 5000 files), parse / discover certain patterns and write report with proposed fixes or same but with the fixes applied.

For whatever reasons I had to do it in Python. It was total nightmare to debug as the execution speed in debug mode was insanely slow.

I could've written it in C++ in exactly the same time and not to have any of the performance problems.

[dtj1123]

The only language I've historically been able to claim to know without feeling like I'm straight up lying has been Python, and having got past my first maybe 1000 lines of Zig I can say pretty confidently that whatever magic makes Python feel comfortable to write, Zig has too.

It requires more of you in some ways, notably that you have to understand the basics of memory management and the behaviour of the stack, but so far I've found the affordances that the language provides for handling this stuff feel very intuitive.

The only sharp edges I've felt so far have been the sometimes hard to guess locations of things in the standard library, and the permenant anxiety that arises from knowing I'm going to be a few more versions behind the current release with every month that passes.

[lioeters]

It's true that Zig is very readable. I haven't yet seriouly studied or written much of it, but browsing through codebases of popular Zig projects, a lot of it just makes sense intuitively. In that way it has a Python-like friendliness of syntax.

I enjoy the community and culture around Zig too. The other day I found a forum thread where people were sharing what they're currently building, and there were so many fun projects from small hobbyist things to large ambitious ones. For the latter, the main concern is the stability of the language, but the good thing is that everything is out in the open, everyone knows Zig hasn't reached version 1 status - but I can see concrete steps are being made to find a good solid interface, including this I/O stuff in 0.16. As someone casually learning the language, I find it refreshing to have insight into the development process.

[portly]

I like that you have more freedom. You can play around with some idea but once you want to do something "serious" you can break into it directly. I start simple but sometimes blip into some performance obsession and I find Zig allows that.

[trueno]

took me a minute but once i started tinkering with compiled outputs and not dealing with runtimes and venvs my ability to tinker went super crazy. being able to pass something off to my vps with no dependencies if i was tinkering with something hosted was fantastic, or sharing a sidequest with a coworker that's buttoned up and ready to go with no additional environment setup for them

[jasdfasd8]

Crazy flexing a gateway programming language that everyone and their chachi knows.

[samuell]

My main issue with this is I expect Mojo to become the go to tinkering language for me.

[asibahi]

It’s definitely a great tinkering language but .. eh .. the Zig team and community are extremely opinionated about how to use the language correctly.

[0x696C6961]

This has not been my experience.

[xyzsparetimexyz]

https://www.reddit.com/r/Zig/comments/onzsfl/illegal_tabs/

[0x696C6961]

I don't understand how this is relevant to the thread.

[j16sdiz]

I won't call it "opinionated about how to use the language correctly."

Space is valid and it compile, Tab don't --- that's it.

When one say "opinionated about how to use the language correctly", I would think JavaScript with or without end of statement semicolon and being yell at even when your program works.

[mcdonje]

Not really