111–120 of 193 posts
Earlier quoted context omitted.
I thought Go tried to be better C
Why should there only be one "better C"? Go has a very different philosophy than Zig, but both can be considered a "better C".
Earlier quoted context omitted.
That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.
There are use cases where safety beyond memory safety is required. But there are no use cases where memory unsafety is desirable, yet alone required.
There are plenty of 'use cases' where Rust's guarantees (some vague but unenforceable promises around memory) are not worth the cost of using Rust (a very high cost). This is doubly true if you want to, say, not use any third-party libraries. If you use third-party libraries, you get essentially zero guarantees. And if you don't, you have to reinvent the world - and writing new data structures in Rust is a series of research projects, whereas doing so in C is trivial.
There are many situations where guaranteed 'memory safety' (a Rust propaganda term for 'having the guarantees we can provide but not the ones we can't provide') is not very important.
Earlier quoted context omitted.
At some level you need languages that are not “memory safe”. Memory safety comes with a cost. Either you pay for a GC runtime (Java) or for reference counting (Swift) or by not being able to express a correct program (Rust). There are plenty of use cases where none of these tradeoffs are feasible. To add, Zig comes with its own story around memory safety. Not at the static type system level and it’s not as comprehens…
"Express a correct program" that might end up being incorrect due to programmer's fault. The difference is, you can use unsafe blocks/fns in Rust, in which case it becomes equivalent to C expressiveness-wise; but you can also do the opposite and forbid(unsafe_code) altogether.
does it support tabs yet?
Earlier quoted context omitted.
I don't need to prove you anything. Go and give it a try yourself.
https://programming-language-benchmarks.vercel.app/c-vs-cpp https://programming-language-benchmarks.vercel.app/c-vs-rust I understand that anytime someone brings benchmarks out, the next response points out that benchmarks are not real world use cases. Nonetheless, they are data points, and your claims are against the commonly accepted view of C being roughly as fast as C++ and Rust. If you have absolutely no data to…
Zig does not do any work because it does not have smart pointers and it does not try to be safe. It tries to be explicit and predictable, the rest is my job.
BTW: This is very real, I've been profiling this and I couldn't believe my eyes. And even if they fixed it already there would be many similar footguns. You can't write performant software if you can't tell what work will be done.
Earlier quoted context omitted.
1. It's typically at least as fast as C, unlike C++/Rust 2. You can do type introspection (and switching) during compile-time, and it's not just some stupid TokenStream transformer, you really have type information available, you can do if/else on the presence of methods, etc. 3. There are no generics, but your functions can accept anytype, which is still type-safe. See https://github.com/ziglang/zig/blob/9c05810be60…
> 1. It's typically at least as fast as C, unlike C++/Rust The typical urban myth that never comes with profiler proofs.
But apart from that the performance should be pretty much identical, after all it's LLVM that does the heavy lifting.
Earlier quoted context omitted.
> Rust has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result) ?!!??u32 is a perfectly cromulent type in Zig.
How do you express the difference between None and Some(None) in Zig?
const std = @import("std");
fn some(x: anytype) ?@TypeOf(x) {
return x;
}
fn print_my_guy(maybe_maybe_x: ??u32) void {
if(maybe_maybe_x) |maybe_x| {
if (maybe_x) |x| {
std.debug.print("that's Some(Some({d})) {any}\n", .{x, maybe_maybe_x});
} else {
std.debug.print("that's Some(None) {any}\n", .{maybe_maybe_x});
}
} else {
std.debug.print("that's None {any}\n", .{maybe_maybe_x});
}
}
pub fn main() void {
const a: ??u32 = 5;
const b: ??u32 = null;
const c: ??u32 = some(@as(?u32, null));
print_my_guy(a);
print_my_guy(b);
print_my_guy(c);
}Earlier quoted context omitted.
> Rust has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result) ?!!??u32 is a perfectly cromulent type in Zig.
How do you express the difference between None and Some(None) in Zig?
const std = @import("std") ;
const print = std.debug.print ;
pub fn main() void {
const simple_none : ?u8 = null ;
const double_optional_none : ??u8 = null ;
const double_optional_some_none : ??u8 = simple_none ;
print("none equals some none: {}", .{ double_optional_none == double_optional_some_none });
// prints none equals some none: false
}> If the Operating System is proprietary then the target is not marked deprecated by the vendor. The icon means the OS is officially deprecated, such as macos/x86. Not supporting proprietary OSes is a bummer. Especially if it is marked as deprecated since it is unlikely to change. People choosing Zig to anything choose their users to throw away their devices. .. the number of hardware and software just keeps growing…
So it’s not really zig deprecating 32-bit macos’s, but Apple, and there’s not a lot zig can do about that.
Earlier quoted context omitted.
> 1. It's typically at least as fast as C, unlike C++/Rust The typical urban myth that never comes with profiler proofs.
I don't need to prove you anything. Go and give it a try yourself.