Assorted Thoughts on Zig and Rust • Hacker News Board

Re: Assorted Thoughts on Zig and Rust

#181

Post by steveklabnik » Tue, Oct 20, 2020, 5:05 PM UTC

skohan wrote: post #178

steveklabnik wrote: post #173

Earlier quoted context omitted.

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.)

Yeah I just think it’s a trend with rust where when a new user complains about a beginner-unfriendly feature, often they are met with an explanation of some esoteric benefit. I just wonder how much of that is as-hoc reasoning, and it doesn’t seem like it’s a particularly good sign.

I thought this way too until I saw a bunch of people praising how easy the module system was because they felt it was very similar to Python's. I don't know Python well so I can't speak to it.

My working theory: each language does modules in a different way. People think "Oh, a module system, I know this" and then run into issues when it works differently than their language. Just a theory though, I have not been able to validate it, or to figure out an explanation that works for all people.

And yes, more generally: as Rust continues to grow, more and more people will hit more and more edge cases, and they cannot always be fixed, thanks to being backwards compatible. That's just how things are as they grow up. More and more users also brings more and more use cases. It's a feedback loop.

Re: Assorted Thoughts on Zig and Rust

#182

Post by dnautics » Tue, Oct 20, 2020, 5:06 PM UTC

wk_end wrote: post #132

optymizer wrote: post #80

Earlier quoted context omitted.

I've been enjoying D as "C done right". I find it a pleasure to use.

D is much more "C++ done right" (and then some). C and Zig are very barebones, close-to-the-metal language. D has garbage collection, classes, templates, exceptions, built-in dynamic arrays and hash tables, and on and on and on. The "Features Overview" page makes me go cross-eyed [1]. Yes, you can turn many of these things off or ignore them and just use D as a better C, but the same could be said of C++ (for some de…

I almost feel like D is "go done right" (I am aware that D precedes go).

Re: Assorted Thoughts on Zig and Rust

#183

Post by fanf2 » Tue, Oct 20, 2020, 5:06 PM UTC

optymizer wrote: post #174

fanf2 wrote: post #167

Earlier quoted context omitted.

D competes more with GC languages like Go and Modula 3, rather than the C / C++ / Rust GCless niche.

I invite you to use D's -betterC compiler option and evaluate it in the context of C/C++/Rust.

As I understand it, that means you can't benefit from most of the D standard library and ecosystem

Re: Assorted Thoughts on Zig and Rust

#184

Post by tym0 » Tue, Oct 20, 2020, 5:07 PM UTC

steveklabnik wrote: post #180

tym0 wrote: post #176

Earlier quoted context omitted.

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…

If you have 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.

It's my bad I thought I could remove the mod.rs that just redeclares the submodules in my case.

Re: Assorted Thoughts on Zig and Rust

#185

Post by estebank » Tue, Oct 20, 2020, 5:08 PM UTC

rhodysurf wrote: post #150

martinhath wrote: post #65

Earlier quoted context omitted.

> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. Macros in Rust aren't only confusing for beginners, because it has a completely different syntax (well, at least macro_rules! does; idk about proc macros) than the one you use fo…

On top of that... you have to use proc macros to do any kind of annoying repetitive implementation of traits. But to do that, you have to add another crate, then you have to possibly make another crate if you want to share any code with the proc macro implementations and the actual library. I understand why it is this way but it is very much not ergonomic

I think that what is lost in the conversation when this topic comes up is that the current macro alternatives, macros by example and procedural macros, are stop-gap features: the first is what was available in 1.0 that got stabilized with the explicit intent to deprecate in eventually (its replacement is an ongoing effort[1]) and the later is a minimal stabilization of compiler internals that had proven to be useful both internally and in nightly crates, where an API surface that we didn't mind maintaining into the future was stabilized.

The entire macro space in Rust (just like async/await) is in MVP status: they are available and useful already, but their current feature set and approachability isn't the end-state.

I know some will read that and think to themselves "Great! More changes to the language! See, they can't help themselves.", but these changes are about removing restrictions and tapering edges.

[1]: https://rust-lang.github.io/rfcs/1584-macros.html

Re: Assorted Thoughts on Zig and Rust

#186

Post by chmod600 » Tue, Oct 20, 2020, 5:11 PM UTC

skohan wrote: post #178

steveklabnik wrote: post #173

Earlier quoted context omitted.

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.)

Yeah I just think it’s a trend with rust where when a new user complains about a beginner-unfriendly feature, often they are met with an explanation of some esoteric benefit. I just wonder how much of that is as-hoc reasoning, and it doesn’t seem like it’s a particularly good sign.

Rust has an RFC process, which is great in many ways. But for something like a module system where everyone has an opinion, it can result in an over-engineered solution that tries to satisfy everyone.

Re: Assorted Thoughts on Zig and Rust

#187

Post by NationalPark » Tue, Oct 20, 2020, 5:15 PM UTC

higerordermap wrote: post #157

mwcampbell wrote: post #138

Earlier quoted context omitted.

> (in safe-mode only, of course) Then it seems to me that Rust still has an advantage, in that it offers full protection of UAF with zero runtime overhead.

If takes twice time to write? Of course, I too believe statically verifying is important for mission critical software. But it comes with a cognitive overhead.

It takes some time to get up to speed with Rust, but I don't think it takes particularly longer to write a correct program in Rust than it does in other languages. I often find myself reaching for Rust rather than Python now, even for small things.

Re: Assorted Thoughts on Zig and Rust

#188

Post by estebank » Tue, Oct 20, 2020, 5:16 PM UTC

judofyr wrote: post #75

kzrdude wrote: post #52

Earlier quoted context omitted.

Once understood, even taken together, none of those have as many rules baked into one concept as "class" does; each is simple.

I quite like the trait system in Rust, but I'm not sure if I would argue that it's simpler than a class-based language. Just looking at `foo.bar()` there are similar types of complexities. In a class-based language you need to be aware of the class hierarchy, and in Rust you need to be aware of imported traits and auto dereferencing.

I honestly think this is a factor of prior experience. When I started using Rust my background was in OOP languages, so I also went through the exercise of fitting trait pegs into a class shaped holes and it was painful. But this doesn't mean that traits and ADTs and how they interact is harder to learn or understand than Objects with its inheritance, polymorphism, encapsulation and abstraction concepts, it just means that if you already know those, you will have to learn new concepts to learn Rust, which can be surprising if you aren't told about it ahead of time, particularly when you already know several languages that don't use traits.

Re: Assorted Thoughts on Zig and Rust

#189

Post by k__ » Tue, Oct 20, 2020, 5:22 PM UTC

estebank wrote: post #188

judofyr wrote: post #75

Earlier quoted context omitted.

I quite like the trait system in Rust, but I'm not sure if I would argue that it's simpler than a class-based language. Just looking at `foo.bar()` there are similar types of complexities. In a class-based language you need to be aware of the class hierarchy, and in Rust you need to be aware of imported traits and auto dereferencing.

I honestly think this is a factor of prior experience. When I started using Rust my background was in OOP languages, so I also went through the exercise of fitting trait pegs into a class shaped holes and it was painful. But this doesn't mean that traits and ADTs and how they interact is harder to learn or understand than Objects with its inheritance, polymorphism, encapsulation and abstraction concepts, it just mean…

I did learn much about classes and interfaces in university, independent of language.

But not much on traits and ADTs(?).

Can you recommend some general learning resources on that?

Re: Assorted Thoughts on Zig and Rust

#190

Post by estebank » Tue, Oct 20, 2020, 5:28 PM UTC

drran wrote: post #179

steveklabnik wrote: post #71

Earlier quoted context omitted.

"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'm one of those, but, any way, Rust is mainly competitor for C++, while no-std Rust (or Core Rust) is direct competitor for C. 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.

> total size of the binary

Have you researched this space already[1]? By default Rust doesn't optimize for the resulting binary size, but there are lots of things that can be done to bring size down where you'd expect.

> number of dependencies used

When this comes up it becomes as much a technical discussion as a philosophical one :)

> and compilation time.

No arguments there. There are some things that can be done in your project to avoid spending too much time (simplify bounds to minimize recalculation in the type system, avoid proc macros, leverage cfg conditional compilation), but they are work arounds.

[1]: https://github.com/johnthagen/min-sized-rust