- alchemio parentYou can use std containers in a no-exceptions environment. Just know that if an error occurs the program will terminate.
- Zig’s general purpose allocator might detect use after free in debug builds, however zig appears to be ok with dangling (invalidated) pointers/slices and use after free for stack variables, which is more concerning, especially from a security standpoint.
```zig
const std = @import("std");
fn get_ptr() i32 { var a: i32 = 6; return &a; }
pub fn main() void {
}var x: ?*i32 = undefined; { var a: i32 = 5; x.? = &a; } std.debug.print("{} {}", .{ x.?.*, get_ptr().* });``` These are trivial examples that Zig doesn’t even warn about, even though similar code in C or C++ gets a warning in gcc and clang.
This discussion:
https://ziggit.dev/t/what-makes-ban-returning-pointer-to-sta...
indicates that core zig devs aren’t interested in diagnosing such usage.
- > It is undoubtedly hard work to fix these remaining problems, as they typically require both rust and C knowledge in addition to deep HTTP familiarity. There does not seem to be that many persons interested or available for this challenge. Meanwhile, there is little if any demand for hyper from existing (lib)curl users.
You might as well replace HTTP with OS, hyper with rust and curl with linux, and you get the current situation with Rust adoption on Linux.
- RustyBuzz is quite limited when compared with HarfBuzz. The Rust fonts scene also seems to lack the necessary momentum to drive things through. I’m not sure whether it’s because the Rust community is mostly interested in webtech or whether Rust itself makes it hard to solve such complex problems. But I don’t see the sands shifting in less than 10 years to come.
- Memory allocation is slow and undeterministic in perf. Some allocations also require a global lock on the system level. It’s also a point of failure if the allocation doesn’t succeed, so there’s an extra check somewhere. Furthermore if every object is a pointer you get indirection overhead (even though small but existent). Deallocation as well incurs an overhead. Without a compacting gc you run into memory fragmentation which further aggravate the issue. All of this overhead can be felt in tight loops.
- It’s something Zig touts when compared to other languages(1). The idea is that in the end it’s a convention that an allocator needs to be passed to indicate that the function allocates, which not even the stdlib adheres religiously to. I’m fine with it since I do believe a library writer should know best what works with their library.
1. https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-allo...
- Just a correction: most std C functions don’t allocate. strdup does but it was only recently adopted into the standard, it was previously an extension.
Similarly zig’s stdlib shouldn’t allocate behind your back, except for thread spawn where it does: https://github.com/ziglang/zig/blob/5cd7fef17faa2a40c8da23f0...
Generally speaking, it’s as mentioned just a convention. A zig library might not allow its users to pass allocators for example.
In C++, stl containers can take an allocator as a template parameter. Recent C++ versions also provide several polymorphic allocators in the stdlib. You can also override the global allocator or a specific class’ allocator (override placement new).
- So rewrite the browser in Rust!
Rust is 10 years old this year, yet there are no production level browsers or operating systems written in it!
I’m talking about Google. They come up with article after article about the failings of C++, yet would prefer starting their own programming language Carbon, continue using C/C++ for chrome, zircon and android.
- C++ is the most important source inspiring Rust throughout its development. Rust devs just like to downplay that role.
- Rust has interface inheritance with pretty much the same syntax
- Rust’s generics are monomorphized, exactly like C++ templates. They also have the same syntax. The only difference is that Rust generics are trait bound.
- Rust RAII is used exactly as it’s used in C++. Moves in Rust are destructive, while in C++ they are not. At the time where move semantics were proposed for C++ in the C++03 era, both types were proposed and the committee decided to go with non-destructive moves.
- Scope resolution syntax is also a carryover from C++.
When the words superset and subset are used in regards to C, C++ and Objective-C, it is quite a misunderstanding to describe C as a subset of Rust.
- Zig is plenty fast for a compiled language with optimizations. The Go compiler has no debug/release profiles and the generated machine code isn’t as optimized as say a language using llvm. If you compare it to C++ or Rust, Zig actually has better compile times, and it keeps improving.