101–110 of 286 posts
Earlier quoted context omitted.
To be fair this alone is nowhere near what Rust can do for you in terms of safety.
But Zig makes this tradeoff intentionally. By design.
Zig may strike a better balance than Rust does here, but it seems more like Rust stole its lunch. I don't know why I'd migrate from C/C++ to Zig instead of going all the way to Rust?
Earlier quoted context omitted.
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.
> If someone wanted to package clang to do that, they could. They do, in fact, that's how clang cross compilation packages work. 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…
... So? It can use most any you wish.
> Zig only bundles the sources, so it builds the C library on-demand.
Which it then caches, post-compilation, taking up binary space on disk comparable to if you just downloaded the pre-compiled target binaries.
Earlier quoted context omitted.
> It seems, from looking at others' code, that there is a very strong temptation to lean on `unsafe` instead of figuring out how to solve a problem within the constraints it normally applies. Are you sure those examples of unsafe Rust code were written using unsafe in order to work around safety constraints due to difficulty? I ask because there are some very real and valid use cases for unsafe code in Rust that have…
Not sure at all - I have effectively zero working knowledge of Rust - and certainly not looking to second-guess people's motivations for using the feature. The big bias I'm working from here is that, as an outsider, I have a hard time reconciling all the big talk about how Rust makes it impossible to experience certain classes of bugs, with the existence of a known set of things that its type checker can't check, and…
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
The spec here is to turn one mutable slice into two non-overlapping mutable slices. The operation does not violate memory safety; we wind up with only one mutable reference to any part of the object. But the compiler does not know how to verify that the programmer has done this correctly. Here, 'unsafe' means 'I certify that this is safe, use that as a lemma to do further checking'.
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…
Note that while strings are generally opaque bytes in Zig, there are standard library functions[0] to work with them as Unicode codepoints and such. But Unicode is quite large and complicated, and things like grapheme clusters aren't in the standard library (yet?). I also believe that that module is planned to be rewritten. So it's more the case that Zig plans to someday support Unicode at the standard library level,…
I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous im…
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 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 feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god forbid on a different platform than the original author).
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.
The author is not under any such impression. The key point is that Zig can cross-compile C/C++ code, while Rust can't. If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target.
That's a pretty big difference in practice. The point about the Python package example is not to say that Zig can get on platforms where Rust can't, but rather that the C infrastructure that we all use is not that easy to replace and every time you touch something, regardless of how decrepit and broken it might have been, you will irritate and break someone else's use case, which can be a necessary evil sometimes but not always.
This is a point I made in the section of the blog post dedicated to explaining the limits or rewriting code.
> since it does not compile to C.
Give it some time, it will.