It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me
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 demoted to warnings, perhaps with a compiler flag or debug build mode.
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.
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.
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?
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.
Batteries included, automatic memory management without a conventional GC and metaprogramming - is a really cool combination.
[0] - https://nim-lang.org/
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.
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.
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
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.
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.
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.
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.
There's not much magic in Zig. Keep hitting goto-definition and you can eventually see the OS switch statements and syscalls.
Zig is a return to “no magical effects,” except with reasonable safety
These reports are smoking crack. Rust scales gloriously well into large codebases, and it especially shines when it comes to making major refactorings. Please don't bother speaking about things that you don't understand.
Rudeness may be acceptable elsewhere. Not here.
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.
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.
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.
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).
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.
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!"
It's arguably the closest modern language (with a sizeable community) to the Wirthian languages.
There is Swift as well, although quite far from Wirthian compile times.
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.
If you only ever think of tinkering for the purpose of execution speed ninjutsu, isn't it your definition of tinkering that's far too narrow?
I personally think the optimization challenge is fun. I like digging in to low level stuff, reviewing the assembly dumps and processor pipeline architectures. I fail or give up most of the time, but I enjoy learning in the process.
I’m just trying to show how Zig fits my tinkering well, since you said you can’t see how Zig would ever be a good fit for tinkering. I’m not saying it’s a good fit for all forms of tinkering.
what the heck has convinced you that logic is somehow flawed in a new low-level language? LOLLL
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.
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.
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.
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.
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.
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.