101–110 of 527 posts
I'm afraid this article kinda fails at at its job. It starts out with a very bold claim ("Zig is not only a new programming language, but it’s a totally new way to write programs"), but ends up listing a bunch of features that are not unique to Zig or even introduced by Zig: type inference (Invented in the late 60s, first practically implemented in the 80s), anonymous structs (C#, Go, Typescript, many ML-style langua…
[flagged]
Earlier quoted context omitted.
> Type inference has left academy and proliferated into mainstream languages for so many years that I almost forgot that it's a worth mentioning feature. It’s not common in lower level languages without garbage collectors or languages focused on compilation speed.
Compilation speed — OCaml, Go, D, C#, Java “Low-level” languages — Rust, C++, D
One of the things I like about Zig is that it pretty explicitly recognizes all the weird edge cases that exist in low-level systems code. A rather large cross-section of languages kind of pretend these cases don’t exist because addressing it would violate the aesthetic they are trying to achieve with the language. Nonetheless, these are real cases because low-level hardware and system behavior doesn’t care about aest…
One of the things I like about Zig is that it pretty explicitly recognizes all the weird edge cases that exist in low-level systems code. A rather large cross-section of languages kind of pretend these cases don’t exist because addressing it would violate the aesthetic they are trying to achieve with the language. Nonetheless, these are real cases because low-level hardware and system behavior doesn’t care about aest…
For example, apparently the plan9 OS gets special page_allocator handling: https://ziglang.org/documentation/master/std/#std.heap.page_...
The final paragraph says "This is all quite surprising" -- why so? "and let one think that many advantages previously found only in interpreted languages are gradually migrating to compiled languages in order to offer more performance" -- sure, but Zig is hardly the first ... D and Nim both have interpreters built into the compiler that allow extensive comptime computation--both of those languages have far more metalanguage facilities than Zig, in addition to many other language features that Zig lacks--which is not necessarily a fault, as it aims for a certain kind of simplicity and close-to-the-metal performance ... although both D and Nim are highly performant (both have optional garbage collection, though Nim is more advanced in making GC-free programming approachable). One thing you can say about Zig though--it compiles like a bat out of hell.
P.S. Another thing about Zig worth mentioning that came up in some comments is cross compilation. I don't think people understand how Zig is different and what an engineering feat it is (Andrew has a writeup somewhere of how it's done--it's shocking):
If you install Zig, you can now generate executables for virtually any target with just a command line argument specifying the target, regardless of what machine you installed it on. Nothing else does that--cross compilation generally requires recompiling the compiler and library to target a different architecture. Zig comes with precompiled libraries for a huge number of targets.
I noticed a comment where someone said they love Zig but they've never programmed in it--they use it to cross-compile their Nim programs. (The Nim compiler has a C code backend, and Zig has a C compiler built in, so Nim inherits instant arbitrary cross-compilation to any target via Zig).
For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?
Earlier quoted context omitted.
Yes, very rare and there is a strong cartel of companies ensuring it doesn't happen in more mainstream langs through multiple avenues to protect their interests! From helicoptering folks onto steering committee and indoctrination of young CS majors.
This comment deserves a [citation needed] visible from geosynchronous orbit.
Earlier quoted context omitted.
Yes, very rare and there is a strong cartel of companies ensuring it doesn't happen in more mainstream langs through multiple avenues to protect their interests! From helicoptering folks onto steering committee and indoctrination of young CS majors.
If I had the ability to downvote a comment yet, I'd downvote you. If you're going to spout conspiracy-theory-sounding stuff, at least provide some evidence for your claims!
Not uncommon in this space though, especially as you get closer to the metal (close as cross-compilation is relative to something like React frontends, at least)
To author -- code sample as images is great for syntax highlight but I wanted to play with the examples and.. got stuck trying to copy the content. (also expected tesseract to do a bit better than this: $ wl-paste -t image/png | tesseract -l eng - - Estimating resolution as 199 const std = @import("std"); const expect = std.testing.expect; const Point = struct {x: i32, y: i32}; test "anonymous struct literal" { const…
const std = @import("std");
const expect = std.testing.expect;
const Point = struct {x: i32, y: i32};
test "anonymous struct literal" {
const pt: Point = .{
.x = 13,
.y = 67,
};
try expect(pt.x == 13);
try expect(pt.y == 67);
ocr ()
{
magick - -monochrome -negate - | tesseract stdin stdout 2> /dev/null
}Earlier quoted context omitted.
> I know that Zig doesn't allow attaching data to error for good reasons. If error data contains interior pointer then it causes memory safety problem IMO this is not a good reason at all.
Changed to "valid reasons"