Common Lisp has https://github.com/sharplispers for exactly this reason.
What Julia has that Rust desperately needs
11–20 of 23 posts
Re: What Julia has that Rust desperately needs
#12The real issue here is Rust's flat namespace. In Go, for example, there's no ffmpeg crate, there's github.com/someone/ffmpeg and gitlab.com/someone-else/ffmpeg, and so on. There's no blessed, unique 'ffmpeg' package, you can't squat names, and if the first package gets abandoned, you can fork it under a new path while keeping the 'ffmpeg' name. Only the import path changes.
How does having more namespaces address the other half of the issue, of having multiple incomplete ffmpeg crates and having to decide which one to use and to support?
Re: What Julia has that Rust desperately needs
#13[deleted]
Re: What Julia has that Rust desperately needs
#14If only newer languages had followed the old-fashioned Java Maven way of having the triple: groupId, artifactId and classifier's for libraries. https://maven.apache.org/guides/mini/guide-naming-convention... These problems simply wouldn't exist.
Java's package identifiers doesn't work at all, since organizations are far more transient than code (Like, even Sun doesn't exist anymore). And even if my organization still exists, one would think I should be able to hand over code to someone else, without them having to claim that they're me.
For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree, just because you went through a rebranding or a merger.
Re: What Julia has that Rust desperately needs
#15The real issue here is Rust's flat namespace. In Go, for example, there's no ffmpeg crate, there's github.com/someone/ffmpeg and gitlab.com/someone-else/ffmpeg, and so on. There's no blessed, unique 'ffmpeg' package, you can't squat names, and if the first package gets abandoned, you can fork it under a new path while keeping the 'ffmpeg' name. Only the import path changes.
Now instead of having the 2nd and 3rd packages have ugly names all of them have ugly names!
There are advantages to systems like this such as trust (I can tell that you.example/pkg1 and you.example/pkg2 are owned by the same person) and decentralization. But I don't think it helps with the later packages having ugly names.
Re: What Julia has that Rust desperately needs
#16> But it’s sad that one person gets to gatekeep everyone else and say, “This is abandoned, I’ll keep the crate name so now you have to make a worse one or be creative.”
Wouldn't reusing the name of a package that is no longer maintained create chaos for programs that use the discontinued package.
Maybe it's not simply one-sided gatekeeping from the former managers of the package?
Re: What Julia has that Rust desperately needs
#17The real issue here is Rust's flat namespace. In Go, for example, there's no ffmpeg crate, there's github.com/someone/ffmpeg and gitlab.com/someone-else/ffmpeg, and so on. There's no blessed, unique 'ffmpeg' package, you can't squat names, and if the first package gets abandoned, you can fork it under a new path while keeping the 'ffmpeg' name. Only the import path changes.
In a hierarchical namespace, two different flavors of ffmpeg would fall into the same branch of the hierarchy.
It would be confusing and counterproductive to introduce, say multimedia_libs/ffmpeg because codec_libs/ffmpeg was discontinued.
A level of hierarchy does when projects in genuinely unrelated categories share a package name.
Re: What Julia has that Rust desperately needs
#18Microsoft solved this in COM. Your component gets a 128 bit class ID, and its interfaces also get 128 bit IDs. It's registered under that ID, and queried by that ID.
It doesn't matter what you call it, and what the files are called; two COM objects could both be FFMPEG.DLL or whatever (obviously not installed in the same directory).
When it comes to packages, users interact with the names and are used to writing names into their code when they specify dependencies, so it's not a complete no-brainer solution; but maybe some idea from that solution space could be worked into a package management system.
Re: What Julia has that Rust desperately needs
#19If only newer languages had followed the old-fashioned Java Maven way of having the triple: groupId, artifactId and classifier's for libraries. https://maven.apache.org/guides/mini/guide-naming-convention... These problems simply wouldn't exist.
Java's package identifiers doesn't work at all, since organizations are far more transient than code (Like, even Sun doesn't exist anymore). And even if my organization still exists, one would think I should be able to hand over code to someone else, without them having to claim that they're me. For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in…
> Java's package identifiers doesn't work at all, since organizations are far more transient than code (Like, even Sun doesn't exist anymore).
Seems to be working for multiple decades without issues ?. If an organization is acquired (like Sun), they still have access to their namespace. It doesn't magically go away.
> For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree..
This is just your opinion. Many people like this systematic nature of directory hierarchy for segregation. Also, you do not require to follow this source language convention in case you don't like it. It is only required that the compiled class be in a nested directory structure for class-loader pickup
Ie You can still you put custom_src/foo/MyClass.java with package com.bingo.tringo;, it’ll still compile, and Maven will output: target/classes/com/bingo/tringo/MyClass.class
Re: What Julia has that Rust desperately needs
#20Earlier quoted context omitted.
Java's package identifiers doesn't work at all, since organizations are far more transient than code (Like, even Sun doesn't exist anymore). And even if my organization still exists, one would think I should be able to hand over code to someone else, without them having to claim that they're me. For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in…
> Java's package identifiers doesn't work at all, since organizations are far more transient than code (Like, even Sun doesn't exist anymore). Seems to be working for multiple decades without issues ?. If an organization is acquired (like Sun), they still have access to their namespace. It doesn't magically go away. > For extra bonus points, the Java directory structure being built around it is just silly, related co…
> Seems to be working for multiple decades without issues?
I noted a pretty damn big issue that invalidates the whole idea that the domain is a stable identifier. It's a big problem in practice, even if you're happy with keeping the old domains you may want to transfer code to someone else without giving them your domain. The solution is apparently to pretend that the problem doesn't exist. Which may be fine for Java but shouldn't be a trap that other languages need to repeat.