Comment by andrewzah | Hacker News Reader

Comment by andrewzah | Hacker News Reader

Parent Full thread

Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine.

The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result.

But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point. For what gains? Less forks, less fracturing -in theory-?

I feel like a lot of the arguments for no namespaces are strawmans or make big stretches. For example, figuring out which fork of a project to use is really not a problem. And a lack of namespaces does not fix that anyways, because it's not a code problem... Importing two crates with the same name would be fairly rare, and rust easily solves that with `use crate::... as ...`. Etc.

Anyway, this discussion has been trod to death. There's no point having it, as I'll just be told why I'm wrong and why namespaces are just -impossible-.

> why namespaces are just -impossible-

As mentioned elsewhere in here, this is a misrepresentation of the issue. The problem is that crates.io is a free, volunteer-run project with zero full-time employees who could be tasked with the drudgery of intervening in naming disputes or managing an identity layer. This is unlike GitHub and unlike "Java" (by which you probably mean Maven Central, which is operated by Sonatype). Solve the funding issue first, and then you can start solving the rest.

"could be tasked with the drudgery of intervening in naming disputes or managing an identity layer"

What do these have to do with the issue of namespaces?

Having namespaces would lessen naming disputes since users would be able to name their crate whatever. Any system will have disputes, so I'm not sure what the argument is here.

I understand why crates uses github for identity management, but it's not ideal that people are locked into using one specific git platform. Github is already an unavoidable entity, much like facebook, but this is a bit of a harder issue to solve without a lot more resources.

Once you introduce namespaces, now you have naming disputes about the namespaces themselves.

So? It's still less disputes. Nobody should be taking namespaces such as "http" for example. The namespaces represent who people are, not what the package does.

> could be tasked with the drudgery of intervening in naming disputes or managing an identity layer

That's why there are proposals that delegate the naming to outside systems with their own established dispute resolution rules.

This is due to the crates team requirement of "namespaces are not allowed to create additional work for the team".

So any proposal that makes them the naming authority is out from the get-go.

> Solve the funding issue first, and then you can start solving the rest.

Sell namespaces? Or verified namespaces I guess? Checkmark and all.

What's right with package namespaces? How do they help at all? Where's the benifit? The cost is that package paths are longer and hard to remember. Also confusing because multiple packages can have the same name

> I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point

Squatting is not a major problem just name your package yourname-xml or randomname instead of yourname.xml

"How do they help at all? Where's the benifit? [sic]"

The obvious one is people can put packages under their own namespace and not worry about naming collisions. If this were really such an issue, things like github,maven, or just about any other library manager would be impossible to work with. But that isn't the case.

"The cost is that package paths are longer and hard to remember. Also confusing because multiple packages can have the same name"

In 5+ years of programming I have not once had an issue due to namespaces. In both systems you still need to remember the author + repo name. Both systems would have multiple competing projects for a problem space. Etc. It's up to you (the engineer) to do your research before adding a library to your project. Namespaces or the lack of them will never fix that.

Name length? Really? Is ~5-15 chars vs ~20-25 so important? It's not like we're memorizing these things. This is not worth removing namespaces for.

Both systems have issues due to things being named the same. One example in rust is `http` and its related types, which get referred to by multiple crates. I ran into that recently when I pulled in various networking crates into the same project. Removing namespaces doesn't fix this.

"Squatting is not a major problem just name your package yourname-xml or randomname instead of yourname.xml"

I'm sorry but I cannot agree with this. Naming should not be a compromise. There's a reason we don't use random names or just random numbers.

Reply on news.ycombinator.com