Earlier quoted context omitted.
>> Zig manages to provide many of the same features with a single mechanism - compile-time execution of regular zig code. > This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier. I believe this outcome was mostly defined by the history. Here is my reasoning: Rust, at least since 0.5, was undoubtly designed as a replacement for C++ (of course that doesn't necessarily mean that i…
> Much simpler type system, which compiles fast and makes the incremental compilation less concern for them. Where is this "complex type system -> long compilation times" meme comes from? Most of rustc's time is spent in llvm. And bottlenecks are identified as monomorphization, producing large amount of LLVM IR and lack of binary dependencies. Type checking is a small portion of time, and not a bottleneck, IIRC.
Assorted Thoughts on Zig and Rust
171–180 of 307 posts
Re: Assorted Thoughts on Zig and Rust
#172> Zig is dramatically simpler than rust... Most of this difference is not related to lifetimes. I've been thinking about this recently: the borrow checker gets a lot of attention, but I think the majority of the learning curve of rust is actually due to "unforced errors" in the language UX which have nothing to do with the language's core USP's. For instance, the module system just seems needlessly complex. Like you…
mod.rs isn't needed anymore; back in 2018 we fixed that: https://doc.rust-lang.org/edition-guide/rust-2018/module-sys... > why there can't be sensible defaults to define modules based on the file system structure alone. There could be, and in fact, I personally advocated for them. But there was significant community pushback; it turns out many people like to "comment out" entire modules when doing big refactorings. T…
So I'm not sure I'm a fan of this either. So now for a module with sub-modules, part of it is defined in the top-level directory, and part of it is defined in a sub-directory. Now if I want to move a module from one directory to another, I have to move two items in the file system.
> it turns out many people like to "comment out" entire modules when doing big refactorings.
It seems to me it would be much better to have an "exclude.rs" file or something to opt out of a sensible default rather than forcing extra work in the common case just to support the common case. Or else you could still allow a mod.rs if you want to be explicit about your module contents, and just assume it includes everything in the directory if it's missing
> There are also some interesting edge cases, for example, you can use a #[path] attribute on a module to change what the path to the file is; without a mod statement, it's not clear where that would go.
Again, I don't think a design should be optimized to support interesting edge cases. It should make the common case as simple as possible. If edge cases need to be supported, I'm sure a solution can be found
Re: Assorted Thoughts on Zig and Rust
#173Earlier quoted context omitted.
mod.rs isn't needed anymore; back in 2018 we fixed that: https://doc.rust-lang.org/edition-guide/rust-2018/module-sys... > why there can't be sensible defaults to define modules based on the file system structure alone. There could be, and in fact, I personally advocated for them. But there was significant community pushback; it turns out many people like to "comment out" entire modules when doing big refactorings. T…
> mod.rs isn't needed anymore; So I'm not sure I'm a fan of this either. So now for a module with sub-modules, part of it is defined in the top-level directory, and part of it is defined in a sub-directory. Now if I want to move a module from one directory to another, I have to move two items in the file system. > it turns out many people like to "comment out" entire modules when doing big refactorings. It seems to m…
(Everyone seems to love and/or hate the module system for various, opposing reasons. It is a great mystery to me. Explaining the module system is like, kind of my white whale.)
Re: Assorted Thoughts on Zig and Rust
#174Earlier quoted context omitted.
I've been enjoying D as "C done right". I find it a pleasure to use.
D competes more with GC languages like Go and Modula 3, rather than the C / C++ / Rust GCless niche.
Re: Assorted Thoughts on Zig and Rust
#175Earlier quoted context omitted.
> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. Put everything you don't want to manage into Rcs, RefCells, Boxes and the like, and you'll more or less feel like you're using a (verbose) GCed language (with a loss of performance and safety as a natural consequence). > I enjoy Rust and have been writ…
RefCells and Boxes just throw the same errors at runtime instead of compile time.
Box, on the other hand, doesn't have any runtime cost. In fact, it's runtime cost is the same as a borrow: both & and Box are just plain pointers, with the extra benefit of having compile time lifetime checking.
[1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
Re: Assorted Thoughts on Zig and Rust
#176> Zig is dramatically simpler than rust... Most of this difference is not related to lifetimes. I've been thinking about this recently: the borrow checker gets a lot of attention, but I think the majority of the learning curve of rust is actually due to "unforced errors" in the language UX which have nothing to do with the language's core USP's. For instance, the module system just seems needlessly complex. Like you…
mod.rs isn't needed anymore; back in 2018 we fixed that: https://doc.rust-lang.org/edition-guide/rust-2018/module-sys... > why there can't be sensible defaults to define modules based on the file system structure alone. There could be, and in fact, I personally advocated for them. But there was significant community pushback; it turns out many people like to "comment out" entire modules when doing big refactorings. T…
With the mod.rs in place I can do this in my main.rs:
pub mod foo
and then in a different file do: use crate::foo::bar::*
But without the mod.rs it doesn't work and I don't know what the correct incantation is...Edit:
Nevermind, I thought this update meant you could remove the mod.rs completely but this is about declaring foo.rs as a file outside of the foo folder.
So you can't just do this like I was hoping:
.
├── lib.rs
└── foo/
└── bar.rsRe: Assorted Thoughts on Zig and Rust
#177I quite honestly wonder sometimes why Rust excited me so much when I first started using it, but I do not get such excitement from Zig. Nowadays it's very easy to be excited about Rust because it demonstrated that ownership works but when I started using it, there was still garbage collection etc. Zig looks really cool but it feels like it has a high chance of being a niche language. Rust never felt like that.
My impression was completely the opposite. I was very excited about Rust at first, especially the ownership system, but after a while I saw that it was a cleaned-up C++ with most of C++'s problems (one of the most complex programming languages in software history; very slow feedback loop). Zig, on the other hand, seems revolutionary and a complete rethinking, from the ground-up, of what low-level programming should b…
C++ has approximately eighteen different partially-overlapping categories of variable initialization, many of which are legacy-but-still-used! [0] And some of those categories have changed their boundaries every language version since C++11 (based on the definition of "aggregate").
C++ has three to five partially-overlapping kinds of type inference all in active use (auto, decltype(id), decltype((expr)), decltype(auto), template argument deduction)! This is interleaved with name lookup and overload resolution (below), so if some subexpression isn't compiling how you expect, you have a vast space of language features potentially to blame.
C++ has so many kinds of name lookup and namespacing that I'm not even sure how to count them. There's unqualified lookup, argument-dependent lookup, qualified lookup, class member access, etc. Sometimes you can't refer to things defined later (outside a class) and sometimes you can (inside a class). There is even undefined behavior if you mess up namespacing! (Undiagnosed ODR violations are every experienced C++ programmer's nightmare.)
C++ has ad-hoc overload resolution based on un-scoped identifiers, which even crosses namespace boundaries using one of the above name lookup modes. It has two kinds of user-defined implicit conversions ("explicit" and implicit) that also affect this selection process, on top of the zoo of "type promotions" inherited from C.
C++ classes have five to six kinds of "special member functions," some of which may be defined automatically by the compiler, each with its own rules for when and how, based on what else is defined in the class. These also contribute to overload resolution, of course.
[0]: https://blog.tartanllama.xyz/initialization-is-bonkers/
Rust has a complexity of its own, but it's quite different in scale and quality. There is exactly one way to initialize a variable, exactly one kind of type inference, only two ways for names to be resolved (directly or via an imported trait). Overloading, implicit conversions (of which there is only one kind, Deref), and the replacement for "special member functions" (Copy, Clone, Drop) are all based on exactly one mechanism (again, traits).
The article has a pretty accurate description of how people experience Rust's remaining C++-like complexity, IMO: "I don't remember the order in which methods are resolved during autoderefencing, or how module visibility works, or how the type system determines if one impl might overlap another or be an orphan."
But one important aspect it leaves out (not being a C++ article) is that if you mess up any of these, you just get a compiler error- and Rust is well-known for having extremely helpful error messages. In C++ you may get a compiler error (known for being extremely unhelpful) or you may get undefined behavior.
Zig is certainly a smaller language than either C++ or Rust, but that comes at a cost. I would much rather hear discussion of those actual trade-offs than yet another "Rust is just as complicated as C++" non-claim.
Re: Assorted Thoughts on Zig and Rust
#178Earlier quoted context omitted.
> mod.rs isn't needed anymore; So I'm not sure I'm a fan of this either. So now for a module with sub-modules, part of it is defined in the top-level directory, and part of it is defined in a sub-directory. Now if I want to move a module from one directory to another, I have to move two items in the file system. > it turns out many people like to "comment out" entire modules when doing big refactorings. It seems to m…
I am not saying you should love the module system, just trying to provide some context. (Everyone seems to love and/or hate the module system for various, opposing reasons. It is a great mystery to me. Explaining the module system is like, kind of my white whale.)
I just wonder how much of that is as-hoc reasoning, and it doesn’t seem like it’s a particularly good sign.
Re: Assorted Thoughts on Zig and Rust
#179I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.
"Rust is a competitor to C++, not C" is a meme, and there's some truth there, but I don't think it's all that accurate. I know lots of folks who prefer C to C++, but still like Rust. I do think that these sorts of language comparisons are useful, but they don't always generalize. Partially this is because what a language means to each person can vary. As long as they're understood in a very coarse grained way, I thin…
I did fairly large and complex program in Rust for bicycle computer, and, while I like developer ergonomic, speed, and memory usage, I'm disappointed by the total size of the binary, number of dependencies used, and compilation time.
Re: Assorted Thoughts on Zig and Rust
#180Earlier quoted context omitted.
mod.rs isn't needed anymore; back in 2018 we fixed that: https://doc.rust-lang.org/edition-guide/rust-2018/module-sys... > why there can't be sensible defaults to define modules based on the file system structure alone. There could be, and in fact, I personally advocated for them. But there was significant community pushback; it turns out many people like to "comment out" entire modules when doing big refactorings. T…
Proof that it is still quite confusing, I tried to remove the mod.rs in my project similarly to that example but now I don't understand how to access these modules. With the mod.rs in place I can do this in my main.rs: pub mod foo and then in a different file do: use crate::foo::bar::* But without the mod.rs it doesn't work and I don't know what the correct incantation is... Edit: Nevermind, I thought this update mea…
foo/mod.rs
you can now use foo.rs
that's it. Contents of the file are exactly the same.Nothing to do with changing the mod line, or the use line. Those all stay the same. It's about files in the filesystem.