11–20 of 191 posts
Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.
Hey hey, this post is great! A few small comments: > It's not obvious to me why they do this – it's a documentation generator, why does it care what version of the Rust compiler I'm using? rustdoc, being a part of the Rust distribution, has the same stability guarantees that Rust does: once it gains a feature, it will never go away. We (well, not me I don't really work on rustdoc, to be clear) need the capacity to tr…
> rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for e…
Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works:
https://rust-lang.github.io/api-guidelines/future-proofing.h...
Earlier quoted context omitted.
I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic kn…
"we know you are using [nightly] for your project because we gated all the features behind it" yes, that kinda sucks.
Earlier quoted context omitted.
> rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for e…
Would you be willing to expand on why using strings for file paths turns out to be unworkable? Very curious what the obscure reasons are!
Hey hey, this post is great! A few small comments: > It's not obvious to me why they do this – it's a documentation generator, why does it care what version of the Rust compiler I'm using? rustdoc, being a part of the Rust distribution, has the same stability guarantees that Rust does: once it gains a feature, it will never go away. We (well, not me I don't really work on rustdoc, to be clear) need the capacity to tr…
> rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for e…
Yeah, and that could work in theory. The thing is, rustdoc uses the compiler as a library, so they actually are pretty tightly coupled. This causes a lot of pain but also has a bunch of upsides. I really want to see a rustdoc that is not, but it's gonna take a long time.
> That's correct.
Cool, I thought so, I just wasn't 100% sure! I think it's interesting how different people take away different things here, to me, this demonstrates that you don't have to have namespaces; many of the largest ecosystems do not and have not had them. We did learn a lesson there, just didn't come to the same conclusion that you did. This one is more controversial within the community though, many people do agree with you.
> Given a crate with a hundred files
Yes, but that doesn't change with rustc vs cargo though; it's still a single rustc invocation to compile all those files. (And, it doesn't quite do so, there is some degree of incremental compilation going on, but it's not as fine-grained as it can be. Working on it!)
Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality. Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.
Earlier quoted context omitted.
> rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for e…
Would you be willing to expand on why using strings for file paths turns out to be unworkable? Very curious what the obscure reasons are!
Earlier quoted context omitted.
I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic kn…
"we know you are using [nightly] for your project because we gated all the features behind it" yes, that kinda sucks.
(I'm a big user of asm! myself, but other than that, stick to stable.)
Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality. Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.
Sorta kinda. Crates are a Rust language concept, and they do not support namespacing. You'd have to hack around that to get it to work.