Comment by steveklabnik | Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Parent Full thread

> I guess I expect rustdoc and rustc to be much less tightly coupled

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

  > Yes, but that doesn't change with rustc vs cargo
  > though; it's still a single rustc invocation to
  > compile all those files.

When using Bazel instead of Cargo the developer can split the build graph into much smaller crates (down to one per module if desired), and still treat the entire assembly as one package.

I should emphasize that this is a limitation of Cargo, not rustc. rustc does just fine with big libraries, it's only Cargo that makes it difficult to write hundred-crate packages.

Ah, so you're not saying that you take the same project and port it from Cargo to Bazel and it somehow does less work, you're saying that it's easier to make projects with a larger number of smaller crates with Bazel than Cargo? That would be the bit I'm missing, Bazel and Cargo should invoke rustc the same amount of times per crate: once. Cargo doesn't change the compilation model of the language.

(Sorry, I feel a bit dense here, but I am very curious to understand exactly. I haven't used Bazel a ton yet, but am very interested in it.)

Yep, exactly. If I were building rust-fuse with Bazel I would probably split it into about 4 crates (fuse_kernel, fuse_io, protocol, server). This is what I tried to do in Cargo and gave up because of the crates.io packaging requirement.

Gotcha. You can use path as a dependency if you also use the version as a dependency, and it’ll use the path locally but the version when you publish. Maybe that needs to be better documented and would have just fixed your issue. (This is described at https://doc.rust-lang.org/stable/cargo/reference/specifying-... )

That requires publishing the internal crates as separate entries in crates.io, if I understand correctly, which I don't want to do (see the final section on crates.io's packaging model).

Ideally I could have a single crates.io package, with a single tarball, containing multiple crates. The internal crates would not be exposed to users, wouldn't have versions, wouldn't be on docs.rs, and so on.

Yeah, that is true, it does.

I do think that's an interesting idea. I'll have to mull on it. Thanks again. I've been thinking of a few things here, very interesting :)

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

Maven is from 2004 and has namespaces. Maven has it's problems, but the Java package management ecosystem gets many things right that later systems have not.

Sure, but that’s not really what I was talking about. Citing maven would have made the point stronger for exactly that reason!

(And the lesson isn’t that either, the claim was never “this feature is terrible and ruins the language”, there very much are successful examples. The claim is that the lack of the feature does not mean failure.)

You are correct that Maven is one of the first package registries to use a principled approach toward namespacing.

I didn't mention it because -- and this may be rude to Maven -- I consider Maven's coordinates syntax to be closer to "primitive Go" than it's own distinct thing. If software hosted on `example.com/foo/bar` has the package name `com.example.foo/bar` then it's introducing ambiguity without much benefit.

It's not just the hosting, it's decoupled from where the project is hosted. Some packages do just use an arbitrary groupId. The reversed-domain-name convention makes sure you'll never get two different groups claiming the same name, and aligns with the convention for how code is namespaced in Java, but it is ultimately only a convention.

>The reversed-domain-name convention makes sure you'll never get two different groups claiming the same name

Surely that's only true at any one instant? Domain names change hands all the time.

For example: All non-EU citizens in the UK that have .eu domain will have them forcibly de-registered at the end of the year. What happens to a eu.example.foo package then?

True, but it's hard to imagine a developer accidentally buying a domain that had previously been used by an unrelated developer and wanting to release packages under the same namespace.

Reply on news.ycombinator.com