91–100 of 286 posts
Earlier quoted context omitted.
Probably related to the following: https://github.com/ziglang/zig/issues/3180
Gee, IIUC it looks like it's been addressed by offering a new allocator that's able to detect use-after-free.
What I don’t understand is why Clang doesn’t do this? What’s stopping them from shipping libc’s for cross compilation? Given that they are a C and C++ compiler, surely this is in their domain.
People without incentive usually do not do this tedious kind of work, since "it works for me".
Earlier quoted context omitted.
I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or senti…
> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. You don't need a string type for that, you just need routines that handle UTF-8…
Earlier quoted context omitted.
The built in cross compilation is just LLVM; it's a narrower set of targets than GCC, and a _far_ narrower set of targets than where you'll find a C compiler. clang cross compilation is not really any harder, you just supply the -target flag.
> clang cross compilation is not really any harder, you just supply the -target flag. Yes, but it doesn't bundle and automatically compile the appropriate C library for the platform. Zig does.
Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]). > soon we’ll also have a package manager This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-…
I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or senti…
Then again, I'm not sure exactly what a type would be for Unicode. Basically just a flag that the array of bytes has been checked and is valid? It's nice to let the type system help you enforce your application boundaries, but I think you could wrap it pretty easily in a struct of your own if you needed that.
[0] https://github.com/ziglang/zig/blob/master/lib/std/unicode.z...
Earlier quoted context omitted.
I've been paying attention to Zig posts on HN, mostly just because it seems well-liked and I think Andrew Kelley is interesting/smart. Would it be fair to say that Zig is to C, what Rust is to C++? Or are they both just kind of...low-ish-level systems languages solving similar problems, differently?
I think that's correct with some overlap, yes. Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. I feel like Rust wants to replace C but it also wants to replace C++. And given the complexity difference between the two languages, that means that Rust will end up closer to C++ than to C. So there's some overlap based on how Rust positions itself, but not based on how Zig pos…
I'm imaging some poor software engineer in 2065, having to maintain an enterprise legacy stack... levels of FORTRAN/COBOL->C->C++->ZIG->RUST->PERL->PYTHON.... all the way up....JS..etc..
Earlier quoted context omitted.
The part that Zig does well, is that it bundles C headers and standard library sources with it. This is the hard part of cross compilation. The default install can build standalone executables from C programs for any supported platform.
If someone wanted to package clang to do that, they could. They do, in fact, that's how clang cross compilation packages work. But sure, to Zig's credit, they ship all the supported toolchains and so don't have many different cross compilation variants in the OS's package manager. But that's a bit like buying one of everything, even though you'll only use one or two.
Clang doesn't bundle a C standard library implementation.
> But sure, to Zig's credit, they ship all the supported toolchains and so don't have many different cross compilation variants in the OS's package manager. But that's a bit like buying one of everything, even though you'll only use one or two.
Zig only bundles the sources, so it builds the C library on-demand. IIRC it's smaller than most cross compiler toolchains.
The author seems to be under the impression that Rust cannot live harmoniously within the C ABI ecosystem, which is false. To some extent. Rust, due to relying on LLVM, is limited by its available targets; and so cannot enjoy the full access that C/C++ can. The same is true for Zig, however, since it does not compile to C.
So if you can't use Rust because it doesn't have the broad compiler support that C does, you almost certainly can't use Zig either for the exact same reason. And then the article touts Zig using their own in-house linker, which seems inevitable to have less platform support than LLVM will? Zig isn't wrong for doing that, but you can't claim that's a benefit at the same time the problem with Rust is it's lack of fringe system support... :/
Earlier quoted context omitted.
I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or senti…
> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. You don't need a string type for that, you just need routines that handle UTF-8…
Earlier quoted context omitted.
> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. You don't need a string type for that, you just need routines that handle UTF-8…
Agreed, and Zig also has a lib for that as well: https://github.com/jecolon/ziglyph/