Agreed. Zig's approach re-uses the existing machinery of the language far more than C++ templates do. Another example of this is that Zig has almost no restrictions on what kinds of values can be `comptime` parameters. In C++, "non-type template parameters" are restricted to a small subset of types (integers, enums, and a few others). Rust's "const generics" are even more restrictive: only integers for now.
In Zig I can pass an entire struct instance full of config values as a single comptime parameter and thread it anywhere in my program. The big difference here is that when you treat compile-time programming as a "special" thing that is supported completely differently in the language, you need to add these features in a painfully piecemeal way. Whereas if it's just re-using the machinery already in place in your language, these restrictions don't exist and your users don't need to look up what values can be comptime values...they're just another kind of thing I pass to functions, so "of course" I can pass a struct instance.
> Zig has almost no restrictions on what kinds of values can be `comptime` parameters.
Neither does D. The main restriction is the CTFE needs to be pure. I.e. you cannot call the operating system in CTFE (this is a deliberate restriction, mainly to avoid clever malware).
CTFE isn't "special" in D, either. CTFE is triggered for any instance of a "constant expression" in the grammar, and doesn't require a keyword.
Compiling to a single C file such that you can then compile the result via say clang is already supported (-ofmt=c). Automatic generation of C header files from your Zig library is WIP. The current recommend approach is to just write the C corresponding header files yourself, the issue mentions a couple of examples.
Zig and Go both let you silence the error with `_ = myvar`. It can still be annoying, but it avoids the recursive problem you mentioned. Language design is hard, and it's best to not just assume that people are "idiotic" for not thinking the way you do. Turn the volume down a bit, and maybe find a synonym for "literally" for the sake of variety.
So now you just silenced a warning and transformed it into a semantically correct form you have no way of recognizing from afar, making the original problem 10-fold worse.
It is a brain-dead feature, verbatim if you prefer that word.
You know, I used to think that design was a nuanced grappling of complex tradeoffs, but you convinced me: those you disagree with are just "brain-dead" "idiots". I think there is a relevant quote by Charles Bukowski about confidence, but it escapes me...
There often is nuance. I haven’t seen any positive for this feature, nor here, nor in the relevant github issues for the languages in question, which were quite argumentative.
But feel free to give me the nuance to this design issue that you so miss.
I'm running NixOS + KDE on the AMD framework and surprisingly it worked perfectly out of the box. All I had to do was disable secure boot to get it running, and after install I had to configure the global scale in display settings to 200% so it looked right. No weird hacks needed at all -- the 23.05 installer just worked, including wifi, which apparently isn't true for Windows 11.
The pre-populated options are $20 and $100 a month, which is a lot. I think he'd get a lot more supporters if he dropped those asks to more like $1 and $5.
The author lost corporate funding recently and is asking for donations. I just started giving 20/mo. I don't care about kernel drama; I just want a good COW filesystem for Linux and this guy is doing a thankless service.
> The author lost corporate funding recently and is asking for donations.
Just to be clear: This is apparently unrelated to the (not that unusual) not-yet-accepted PRs and their lkml review discussions.
From Overstreet's Patreon post:
"The company that's been funding bcachefs for the past 6 years has, unfortunately, been hit by a business downturn - they've been affected by the strikes in the media production industry. As such, I'm now having to look for new funding.
This came pretty unexpectedly, and puts us in a bit of a bind; with the addition of Hunter (who's already doing great work), I'm stretched thin, without much of a buffer."
Also note that this isn't Kent's first rodeo. bcache from the same author is an SSD-optimized block caching layer already in production in the Linux kernel. The idea is that bcache allows building of hybrid drives where the kernel has visibility and independent control over both the SSD(s) and the spinning rust drive(s).
My understanding is that at some point during development of bcache, Kent realized "hmm... if I just got rid of cache eviction and cleaned this up a bit, it would make a nice light-weight CoW SSD-optimized filesystem".
My understanding is that there are very few untried ideas in bcachefs, and it's a relatively low-risk project. Having been burned by over-enthusiastic early adoption of btrfs, I'm hoping bcachefs becomes a conservative alternative for distros that don't currently use a CoW filesystem as the default filesystem. (Okay, I did use rsync to weekly mirror to ext4, so maybe "burned" is too strong a word, but I did wedge btrfs a few times by over-filling it.)
Think about longevity. Whether I'm writing, drawing, making music, or anything else important to my life, will I still be able to view/edit that data in 20 years? Granted, even with offline-friendly software I may need to port it to new platforms and make sure I back up the data, but at least I have a chance. The data I still have from 20 years ago is far more precious to me than I thought it would be back then. Data that can only be accessed through an external party is ephemeral and it will inevitably disappear one day.
You are right to talk about the data first and foremost. 20 year old software is very rarely useful (yes there are exceptions) but the data is often just as valuable as before or even more so.
That is why I much prefer a web app that lets me download my data in an open and well documented format to a desktop app that locks my data into some obscure proprietary format or even into a particular device.
Richard is a great contrarian thinker. I remember him from GET LAMP, a documentary about text adventures, and his take on the power of text in games was really memorable: https://www.youtube.com/watch?v=Zctp972y_Eg
In Zig I can pass an entire struct instance full of config values as a single comptime parameter and thread it anywhere in my program. The big difference here is that when you treat compile-time programming as a "special" thing that is supported completely differently in the language, you need to add these features in a painfully piecemeal way. Whereas if it's just re-using the machinery already in place in your language, these restrictions don't exist and your users don't need to look up what values can be comptime values...they're just another kind of thing I pass to functions, so "of course" I can pass a struct instance.
reply