Isn’t var ptr: [*]u8 = @ptrCast([*]u8, &slice[0]); the same as var ptr = slice.ptr; ? Or am I missing something
yes it would be the same
Zig as an alternative to writing unsafe Rust
61–70 of 230 posts
Re: Zig as an alternative to writing unsafe Rust
#62Earlier quoted context omitted.
People keep saying this and I just do not get it . It's just… not that bad?
It's not about actual ugliness, it's just something that is hard to articulate as something other than ugliness. https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
It's amusing to me that many of the people who complain about the aesthetics of Rust's syntax are quick to also say bad things about, like, Haskell, or Lisps, or other languages with comparatively low syntactic overhead.
I think the thing people don't like about Rust is that it looks vaguely C-like but is clearly not C. People might like it better if it was further removed (aesthetically) from C's syntax. But then they would also complain.
I think there was no way for Rust to meet all its semantic goals and also make people happy about the syntax.
Re: Zig as an alternative to writing unsafe Rust
#63Earlier quoted context omitted.
The core language is fine, but when you actually start building things you need to introduce lifetimes, all the traits that you polluted your interface with and then add on async, it gets out-of-hand quickly.
The top comment gave a perfect example: #![feature(strict_provenance)] These feature enablement blocks drive me crazy. You could go from codebase to codebase and it's almost like you are working in a different language depending on how many of these are enabled or not. I've been trying rust on and off since it's release, and I still have yet to feel like I have a grasp on some "core" subset of the language I can fall…
Those feature blocks exist only for nightly/unstable Rust. You don't have those on stable Rust. The most you might have are derive blocks but those just automate what you'd write by hand anyway.
Re: Zig as an alternative to writing unsafe Rust
#64Earlier quoted context omitted.
Agreed, using Rust is like switching a monster (C++) for another even worse. And notice that Rust is not even a mature language, it will get much worse. I will stay with C, thank you.
At least C++ is enormous and you can find a sane subset that you enjoy using. And C++ can be pretty safe with smart pointers.
This almost works until you have to integrate with other people's C++ code and find out they picked a different subset to you.
Re: Zig as an alternative to writing unsafe Rust
#65Earlier quoted context omitted.
'constexpr' and 'auto' in modern C++ can eliminate a large portion of the ugliness. In some cases it can be much more ergonomic than the equivalent Rust.
Indeed, one gets to write macro like code on the same language.
You can write Rust macros in Rust too, if you wish, but it's a bit more involved (https://doc.rust-lang.org/reference/procedural-macros.html). I realise this isn't the same as constexpr, but I'd argue it's nicer.
Rust also has const generics (but they are still a bit shabby in places last time I used them).
I for one never liked the constexpr semantic and syntax. Always felt like a... Little pebble in my shoe. Didn't quite annoy me enough not to use it since it was useful, but it was never a comfortable experience.
Re: Zig as an alternative to writing unsafe Rust
#66Earlier quoted context omitted.
People keep saying this and I just do not get it . It's just… not that bad?
It's not about actual ugliness, it's just something that is hard to articulate as something other than ugliness. https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
One random thing that bugs me about Rust's syntax is array initialization. In Go I can initialize an array (or strictly speaking a slice) of structs like this:
var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...}
let foo = [MyStruct{a: "foo", b: 1, c: "amp"}, MyStruct{a: "bar", b: 1, c: "fff"}, MyStruct{a: "amp", b: 1, c: "aaa"} ];
Re: Zig as an alternative to writing unsafe Rust
#67I get that Zig is better than unsafe Rust. But what about the general use? Is Zig simplicity and speed of writing code worth the trade-off in safety?
Re: Zig as an alternative to writing unsafe Rust
#68The way I would frame this is that Rust has static (compile-time) memory management, and that conflicts with dynamic memory management (garbage collection).
The boundary is awkward and creates complexity.
I wrote a post about problems writing a garbage collector in C++, e.g. annotating the root set, and having precise metadata for tracing.
http://www.oilshell.org/blog/2023/01/garbage-collector.html
https://news.ycombinator.com/item?id=34350260
I linked to this 2016 post about Rust, which makes me think the problem could be worse in Rust, although I haven't tried it:
http://blog.pnkfx.org/blog/2016/01/01/gc-and-rust-part-2-roo...
I didn't write as much about bindings to native C++ code, but that's also an issue that you have to think about carefully. CPython has kind of been "stuck" with their API for decades, which exposes reference counting. So it's extraordinarily difficult to move to tracing GC, let alone moving GC, etc.
---
On the other hand, there was also a paper that said Rust can be good for writing GCs.
Rust as a Language for High Performance GC Implementation
https://dl.acm.org/doi/pdf/10.1145/2926697.2926707
However, I'm not sure it addresses the interface issue. One lesson I learned is that GCs are NOT modular pieces of code -- they have "tentacles" that touch the entire program!
That said, C++ is pretty good at "typed memory" as well, and I think it's more pleasant than C. That is, you get more than void* and macros. So I can believe that Rust has benefits for writing GC.
Not sure about Zig -- I can believe it's a nice middle ground.
Re: Zig as an alternative to writing unsafe Rust
#69> Unsafe Rust is hard. A lot harder than C, this is because unsafe Rust has a lot of nuanced rules about undefined behaviour (UB) — thanks to the borrow checker — that make it easy to perniciously break things and introduce bugs. I don't think this is correct: Rust makes writing unsafe Rust correctly more onerous than writing C, but the actual rules for undefined behavior are the virtually same as in C: if you alias…
The rust undefined behaviour rules are stricter than C: mutating a non mutable reference is UB, for example. Non mutable references don't exist in C.
Re: Zig as an alternative to writing unsafe Rust
#70This pretty much mirrors my experience. Rust is the inverse of Perl: It makes the easy stuff hard. Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)? Is it implemented making gratuitous copies of data everywhere? Does it have a hideous interface which will then pollu…
> It seems to consist solely of extremely online people who get a dopamine hit from both telling people they're doing things wrong and creating the most complex solutions possible.
I've observed that certain programming languages have a culture of complexity. I'm not sure why this is. I can only speculate its because these programmers are working on "boring" problems so they make busy work for themselves OR their beginners who think this is how "real programmers" work.
While I think calling them "idiots" is a bit strong, I think this quote from the late Terry A. Davis is worth remembering: “An idiot admires complexity, a genius admires simplicity [...] for an idiot anything the more complicated it is the more he will admire it, if you make something so clusterfucked he can't understand it he's gonna think you're a god cause you made it so complicated nobody can understand it.”