Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

Post reply on HN
Print view View original

291–300 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#291

Post by martinhath »

mwcampbell wrote: post #125
martinhath wrote: post #103

Earlier quoted context omitted.

> doing compile-time execution in a sound, safe way is not simple. For example, cross compilation becomes more of a thing. It is easy to accidentally break the type system. Why? I don't think I've ever seen a concrete example of why this isn't simple (but I'm not really a compiler person, so there might be!). I can imagine plenty of ways of doing Bad Things, like adding compiler flags based on what day it is, but I c…

> It sound like people writing books without the rules on verb conjugation being really set. I'm sure this happened earlier in the history of English. Of course, humans are much more forgiving than compilers.

Hehe yeah, it's not a great analogy :)

Re: Assorted Thoughts on Zig and Rust

#292

Post by aszen »

dom96 wrote: post #225
steveklabnik wrote: post #169

Earlier 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…

Nice to hear that there has been some progress here. I recall trying Rust 4+ years ago and my experience with the module system really left a lot to be desired from someone most experienced with Python's module system.

I was confused by rusts module system too, after having used es6 modules in js and python but then I realised the module systems couldn't be compared. In dynamic langauges like python or js u can individually use modules but in rust everything has to link back to either main or lib if I'm not mistaken. This was what enabled me to get rid of preconceived notions of how a module system should work.

Re: Assorted Thoughts on Zig and Rust

#293

Post by steveklabnik »

kbenson wrote: post #280
steveklabnik wrote: post #181

Earlier quoted context omitted.

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 abl…

Honestly, that idea makes a lot of sense to me, and personally, I find the module system pretty normal seeming for a modern language. I'm used to Perl and CPAN, and it's pretty similar to that, except for the option to use dir/mod.rs, which honestly seems like it's kinda nice for keeping a module contained nicely for those that want to do it that way. Now I'm more interested in what the complaints about it are, and s…

It just really depends. I should have been writing these down over the years. A few common points of confusion off the top of my head:

People expecting to put "mod foo;" at the top of foo.rs, to declare that foo.rs is a module.

People expecting to put "mod foo { }" with the contents of the file inside the {}s to declare that foo.rs is a module.

People expecting that "use" declares a module, not "mod."

People expecting every file inside a directory "foo" to be the contents of the "foo" module, regardless of filename, all concatenated together.

People expecting that mod statements never need to exist because it should be inferred from the filesystem.

General confusion about the privacy rules; that "pub" may not mean that your thing is globally public.

General confusion about crates vs modules; main.rs and lib.rs being in the same directory, but declaring different crates. Not understanding how to import stuff from lib.rs into main.rs, because it feels a bit different than other modules.

People used to also struggle a lot with "use" and paths pre-Rust 2018, but that's been mostly cleaned up at this point.

Re: Assorted Thoughts on Zig and Rust

#294

Post by steveklabnik »

martinhath wrote: post #290
steveklabnik wrote: post #107

Earlier quoted context omitted.

> Accidentally getting non-typechecked code in the compiler, or running into problems with the compiler thinking two equal types are distinct? Yes, this sort of thing. Basically, you have to have this be deterministic , or you end up with very strange possibilities, possible miscompilations, and in the best case, confusing errors. One option is to simply accept that these things can happen. Another is to restrict wha…

> An extremely simple example is cross compiling. In Rust, usize is dependent on the architecture you're compiling for. A very simple "just compile and run the program, get the answer, and use it" implementation of compile-time execution will produce a usize of the size of the host, not the target. I get that there are non-obvious problems here, and as you say, this problem specifically has an easy fix, but I'd just…

> I'd just like to note how Zig does this:

Right, what I'm talking about is the implementation of "comptime @sizeOf(*usize)".

That it does the right thing is good! It's easy to accidentally implement it in a way that does not.

> And for what it's worth, I would greatly prefer Rust having a proper spec

We all would :)

Re: Assorted Thoughts on Zig and Rust

#295

Post by nine_k »

lambda_dn wrote: post #11

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

The whole comptime stuff is very un-C.

Re: Assorted Thoughts on Zig and Rust

#296

Post by Rusky »

jcelerier wrote: post #286
Rusky wrote: post #259

Earlier quoted context omitted.

Right, I've been telling you it's not relevant for the past three comments now. You seem to be under the impression that dlopen somehow interacts with language undefined behavior; it does not in either Rust or C++.

> Right, I've been telling you it's not relevant for the past three comments now. but it is ! the only reason why ODR is UB in C++ is because the C++ language authors can't force the system linkers (again, whether at link time, load time or runtime, I'm not only referring to dlopen) to perform LTO which trivially makes ODR violations a diagnosticable error. But as far as I know, neither can the Rust language authors…

Going back to my original answer, the difference lies in what the two languages ask of the linker under normal circumstances.

Normal, non-FFI-using C++ can hit ODR violations in response to things like typos or subtle mis-uses of `inline` and templates.

Normal, non-FFI-using Rust is designed such that these situations never come up.

My original comment was never talking about FFI in the first place, where yes, both languages are much more at the mercy of what the platform provides. However, in that case the spooky UB ODR violations I was referring to are also not relevant, because you just get normal, fully-defined platform behavior- the expectations of the compiler (and thus the chances for them to be violated, resulting in UB), are different.

Re: Assorted Thoughts on Zig and Rust

#297

Post by infogulch »

JoshTriplett wrote: post #236
nicoburns wrote: post #222

Earlier quoted context omitted.

I actually the module system is one of the few exceptions where it's actually poorly designed. It could very easily have a 1:1 mapping to the filesystem with no need to declare modules to use them. Lot's of people apparently don't like that idea, but most other module systems do it that way, and IMO it would be a lot more intuitive.

> It could very easily have a 1:1 mapping to the filesystem with no need to declare modules to use them. I would love to see this. The issue isn't that people hate the idea. The issue is not breaking existing projects and workflows when making such a change. If we could find a way to make this work without breaking existing projects and workflows, I think there's support for doing so.

What if we could provide this with tooling? Like, everyone that uses Go for an extended period eventually complains about how it's an error to import a module and not use it... until they enable goimports-on-save and then the problem vanishes (mostly). (My point is not to compare go/rust module systems but to illuminate how a pain point introduced by the language's guarantees can be eliminated by tooling.)

If there is such an easy to define 1:1 mapping, then could there be a rustmods-on-save tool that automatically adds mod statements according to a fixed scheme whenever any *.rs file is created in the current directory or a child directory?

Re: Assorted Thoughts on Zig and Rust

#298

Post by JoshTriplett »

infogulch wrote: post #297
JoshTriplett wrote: post #236

Earlier quoted context omitted.

> It could very easily have a 1:1 mapping to the filesystem with no need to declare modules to use them. I would love to see this. The issue isn't that people hate the idea. The issue is not breaking existing projects and workflows when making such a change. If we could find a way to make this work without breaking existing projects and workflows, I think there's support for doing so.

What if we could provide this with tooling? Like, everyone that uses Go for an extended period eventually complains about how it's an error to import a module and not use it... until they enable goimports-on-save and then the problem vanishes (mostly). (My point is not to compare go/rust module systems but to illuminate how a pain point introduced by the language's guarantees can be eliminated by tooling.) If there i…

At the very least, we could have a warning if you have any .rs file that isn't being brought in by a `mod` statement, which would help people understand why their code isn't working.

That'd also get us halfway towards just making it automatically work without `mod` statements.

Re: Assorted Thoughts on Zig and Rust

#299

Post by higerordermap »

lifthrasiir wrote: post #171
higerordermap wrote: post #159

Earlier quoted context omitted.

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

You are absolutely true for the release build (sharing the same backend, Zig is also significantly slower in the release build). For the debug build however there may be multiple answers: typing, borrow checking (broadly this is a sort of typing), codegen and LLVM all can contribute significantly to the compilation time [1]. The situation may have been improved since the last time I've checked though. [1] https://wik…

Didn't know this. Thanks.

Re: Assorted Thoughts on Zig and Rust

#300

Post by higerordermap »

NationalPark wrote: post #187
higerordermap wrote: post #157

Earlier quoted context omitted.

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.

I have heard this statement ~~repeated~~ monomorphized so many times here without mentioning reasons that I don't believe it anymore.
Post reply on HN