When C++ achieved its 1.0 release, the only “proper build system” was UNIX make. It’s only in the past two decades or so that languages or frameworks came out with their own “build systems”. Personally, I don’t think there’s a “mess”, competition and having choices is good (not to get political, but there’s a certain U.S. senator that wondered why there should be so many different brands of toothpastes).
I don’t think comparison with other languages makes sense
I only brought up the other languages, not because of their features, but because “young” implies a certain time since an individual or other entity is born or created. Ten years is still young for a human because of the expected lifetime, but it could be argued that any software conceived ten years ago is not exactly “young”.
I apologized for my rant before I clicked the Reply button, because I didn’t want this to become a controversy over language features (which I admit I still don’t quite understand, or if I do understand them, I have reservations about them). Evidently, however, the rant was not ignored.
That depends on the size of the dev team and the resources available to them. The Zig project will not take money that would make it beholden to corporate interests, and the team has been quite small. In addition the project has gone through several iterations in order to arrive at the language you see today. That’s all by choice and no promise of doing things more quickly was made.
You’ve essentially said that you think Zig should be be further along than it is, and should being providing different features that you’d like. You should not expect a super friendly response to that.
I first took a look at Zig about two and a half years ago (at 0.10) and I had written the (simple) program that elicited the original post here. I didn’t pursue it much further then because a discussion IIRC at Discord, on another matter, sort of convinced me that it was still too early.
When I came back to it now (at 0.15), I was surprised because I had to replace a single line to get stdoutby three lines and a fourth to flush after each print, and a similar process with stdin including “tossing” instead of flushing. Furthermore, it appears this will have to be changed again for 0.16. But, I sort of said to myself, I can live with that because Zig’s ability to interoperate with C and perhaps to a certain extent with C++.
So, no, I dont think that “Zig should be further along”, but it is disappointing that my “too early” assessment sort of still holds. Yet I’m still going to continue trying it.
As for providing different features, I’m afraid that no language (programming or natural) is ideal for everyone, and very few of us have the zeal and knowledge to invent and write the ideal one for ourselves. The division of labor is what allows us to benefit from the work of those few who do.
going 5 versions in an unstable language shouldn’t surprise you with big changes.
Your 0.15 code is definitely doing more than your 0.10 code did, if you compare equivalent behaviour then the difference is not so big:
// 0.10 hello world example
const writer = std.io.getStdOut().writer();
try writer.print("hello, {s}", .{"world"});
// equivalent 0.15 code
var writer = std.fs.File.stdout().writer(&.{});
try writer.interface.print("hello, {s}", .{"world"});
// no flush needed since the buffer is 0 length
// buffered 0.10 example
// stores buffer internally, and a default of 4096 bytes
var writer = std.io.bufferedWriter(std.io.getStdOut().writer());
try writer.print("hello, {s}", .{"world"});
try writer.flush(); // yup you had to flush in 0.10
// equivalent 0.15
var buffer: [4028]u8 = undefined
var writer = std.fs.File.stdout().writer(&buffer);
try writer.print("hello, {s}", .{"world"});
try writer.interface.fush();
the only differences are: std.fs.File → std.Io.File writer(file, buffer) → writer(file, io, buffer)
some name space changes, and things that do io take an io parameter now, reader/writers store it so it isnt passed to each function.
And getting an io instance is easy with the juicy main init parameter.
I’m sorry but since I’ve never been involved in an unstable, pre-1.0 language before, my expectations were a bit different.
On the languages side, I did experience the Python transition from 2.7 to 3.x, which was painful, but the language itself was already stable and it transitioned to another, more or less well-defined state, so it was mostly an issue of waiting for the entire ecosystem (or anyone’s chain of depedencies) to deal with the changes.
However, perhaps I should know better, because on the general software side, I did create an open-source project and although I initially had a “vision”, that was changed when people actually started using it.
Thanks for patiently instructing me on all those little details.