Where did you get this? Of the three implementations I see here all three have available sources, Myte and Serpens don't have licenses, and Pyra has an Unlicense open-source license.
Doesn't it make it more likely unused variables stay in the codebase? You want to experiment, the code doesn't compile, you add this (probably by automatic tool), the code now compiles. You're happy with your experiment. As the compiler doesn't complain you commit and junk stays in the code.
Isn't it just bad design that makes both experimenting harder and for unused variables to stay in the code in the final version?
It is indeed quite controversial aspect of Zig's design. I would rather prefer it be a warning. Argument "warnings are always ignored" just doesn't hold because anything can be ignored if there is a way to suppress it.
there was a recent interview where andrew suggested if i understood correctly: the future path of zig is to make all compilations (successful or not) produce an executable. if theres something egregious like a syntax or type error, the produced artifact just prints the error and returns nonzero. for a "unused parameter", the compiler produces the artifact you expect, but returns nonzero (so it gets caught by CI for example.
if you have a syntax error in file A, and file B is just peachy keen, you can keep compiling file B instead of stopping the world. Then the next time you compile, you have already cached the result of file B compilation.
I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.
> I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster.
In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them.
> Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.
I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable).
This BTW this happens more often than you would expect. I have read PRs and had to reject them because I read the code and they wouldn't have worked, so I know the person had never actually run the code.
I am quite a tidy programmers, but it difficult for people even to write commit messages that aren't just "fixed bugs".
> I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable).
At this point what you need to do is stop treating compiler warnings as errors, and just have them fire the shock collar.
Negative reinforcement gets a bad rep, but it sure does work.
Yeah but this case just seem to be strictly worse. It makes experimenting worse and it makes it more likely (not less) that unused variables end up in the final version. I get being opinionated about formatting, style etc. to cut endless debates but this choice just seem strictly worse for two things it influences (experimenting and quality of the final code).
If you want to leave a variable unused, you can just assign it to _ (underscore) though. IIRC gofmt (which your editor should run when you save) will warn you about it but your code will compile.
It's a slightly different mindset, for sure, but having gofmt bitch about stuff before you commit it rather than have the compiler bitch about it helps you "clean as you go" rather than writing some hideous ball of C++ and then a day of cleaning the stables once it actually runs. Or at least it does for me...
You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.
Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). I work on TypeScript/C# code-bases and unless you force people to tidy up unused imports/using and variables, people will just leave them there.
This BTW can cause issues with dependency chains and cause odd compile issues as a result.
Not really. No. You can easily checkout repo containing the Dockerfile, add a Dockerfile override, change most of the stuff while maintaining the original Dockerfile instact and the ability to use git to update it. Then you change one line in docker-compose.yaml (or override it if it's also hosted by the repo) and build the container locally. Can't imagine easier way to modify existing docker images, I do this a lot with my self-hosted services.
It is straightforward, but so is the NixOS module system, and I could describe writing a custom module the same way you described custom Docker images.
But it works on Ubuntu, it works on Debian, it works on Mac, it works on Windows, it works on a lot of things other than a Nix install.
And I have to know Docker for work anyhow. I don't have to know Nix for anything else.
You can't win on "it's net easier in Nix" than anywhere else, and a lot of us are pretty used to "it's just one line" and know exactly what that means when that one line isn't quite what we need or want. Maybe it easier after a rather large up-front investment into Nix, but I've got dozens of technologies asking me for large up-front investments.
Nix is for reproducibility. Nix and docker are orthogonal. You can create reproducible docker image via nix. You can run nix inside docker on systems that doesn’t allow you to create the nix store.
This is a familiarity problem. I've never used NixOS and all your posts telling me how simple it is sounds like super daunting challenges to me versus just updating a Dockerfile or a one liner in compose that I am already familiar with, I suspect its the inverse for you.
I find the granular nature of dependency sharing in NixOS to be really nice. In particular, I like systemd as my hypervisor. With systemd I can still isolate and lock down processes, but they can still, for example, share memory pages of `glibc`. It is certainly less "secure", and with Docker at least you're sharing the same kernel. It's also hard to share resources between Docker containers. Getting 4 Docker containers to use the same instance of Avahi, for example, requires explicit configuration.
Docker containers also don't have a "standard" for where to put binaries (outside of CMD/ENTRYPOINT), how to configure users/uids (many still run as root?), whether to put multiple services in one container or separate containers, where to put user data, etc. NixOS coordinates this centrally like any distro, assigning paths and UIDs and ports.
I have found Nix and NixOS to be able to absorb any amount of complexity I throw at it with grace.
If a Docker image truly is the best way to use a bit of functionality (like Home Assistant), then I will just configure NixOS to run it in podman as a systemd service with host networking.
I have not come across something that I could not package. The trick is that Nix composes functionality in a way that Dockerfiles or docker-compose configs cannot, because it's one language, one system, one abstraction.
Shameless plug: I build a terminal text editor with quite the opposite philosopy. Modal, suckless/assemble it yourself, extremely hackable, plenty fast, written in Zig.
EDIT: seems to be open source, just isn't mentioned on the website https://forge.nouveau.community/nova
reply