What Julia has that Rust desperately needs
jdiaz97.github.io
What Julia has that Rust desperately needs
1–10 of 23 posts
Re: What Julia has that Rust desperately needs
#2This is a short and well-articulated proposal about improving Rust crates (library) management, not what one would expect from the title. While the exact mechanism may not be the right one, I think this is a worthwhile discussion that ultimately adds more hierarchy to avoid multiple versions of half-baked crates and forks.
Re: What Julia has that Rust desperately needs
#3If 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.
Re: What Julia has that Rust desperately needs
#4Totally random, but your blog theme has similar vibes to mine https://jason.today + serif font
Re: What Julia has that Rust desperately needs
#5The 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.
Re: What Julia has that Rust desperately needs
#6If 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.
Go did exactly that, where Maven's 'Project group identifier' is an URL you control, e.g. github.com/ but also /go-pkg or whatever you want. Other languages did this too. Flat namespaces are more of a Rust issue (among newer languages).
Re: What Julia has that Rust desperately needs
#7If 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.
Yeah, on the spot.
Java and .NET have a couple of good ideas even if they aren't fashionable any longer.
Re: What Julia has that Rust desperately needs
#8One reason in Julia for having an organization with multiple repositories is how unnecessary is in Julia to have big packages. It is better to have smaller more focused packages and combine them as necessary. Julia needs to improve some things but I don't think I have found a more modular language.
Re: What Julia has that Rust desperately needs
#9Standardizing on one external code hosting solution (GitHub) instead of a community managed one is not a solution.
Re: What Julia has that Rust desperately needs
#10The 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.
Not entirely true. Rust (cargo) supports git-based crates and more crate sources than just crates.io (registry = "crates-io"), however crates on crates.io doesn't currently support dependencies with crates in other registries.
somecrate = { git = "https://...." }
other-crate = { version = "1.0", registry = "my-registry" }
https://doc.rust-lang.org/cargo/reference/source-replacement...
crates.io could be updated to support alternative registries.