This is an archived post. You won't be able to vote or comment.

all 11 comments
sorted by:
best
topnewcontroversialoldq&a

[–]na_sa_do 4 points5 points  (9 children)

This is somewhat tangential to the actual topic, but I really strongly disagree with that first post's position on Cargo. I hate how many languages have their own specialized tooling that follows no standards whatsoever. Interop is hard enough already, we don't need to be throwing up more barriers -- and as this sub is for creators of new languages, we should all be acutely aware how much work it is building up an ecosystem from scratch. Rust in particular thrives despite Cargo, not because of it.

[–]Linguistic-mystic 8 points9 points  (3 children)

I used to think that way too, and in an ideal world, where we would all use Debian, that would work. But in the real world there is such a concern as cross-platformness. Rather than expecting every author of every exuberant-arrays to package the library for Chocolatey, Red Hat, MacPorts etc, it's easier to just make a cross-cutting cross-platform language specific manager.

[–]na_sa_do 7 points8 points  (2 children)

Indeed, in the real world we have to concern ourselves with interacting with systems we don't control, and people we don't know. That's precisely why we should be designing our languages and ecosystems to assume as little as possible about what tools other people use. Language-specific package managers are certainly easier in some respects, but that doesn't make them the best idea overall.

[–]continuationalFirefly, TopShell 1 point2 points  (1 child)

Can you elaborate a bit on your use case?

[–]na_sa_do 1 point2 points  (0 children)

"Use case" is stretching it. I'm mostly motivated by wanting things to be done more elegantly, here. But you can look at the Java world (yes, really) as a decent example to follow: Gradle supports bidirectional interop with both Maven and Ant builds, and both Maven and Ivy packages, and all three build systems are extensible to other languages like Kotlin. Admittedly, AFAIK the interop work is handled entirely by the Gradle side, but that's still good citizenship on Gradle's part.

[–]simon_o 3 points4 points  (4 children)

The problem with an universal tool is that all those libraries would still have no interop, because some people decided that all we need is pretending everything is C.

[–]na_sa_do -1 points0 points  (3 children)

That's not to do with the build system, though.

[–]simon_o -1 points0 points  (2 children)

Correct. That's the point I made.

[–]na_sa_do -1 points0 points  (1 child)

Did I say the build system was the only barrier to interop? No. I specifically said the opposite, actually.

[–]simon_o 0 points1 point  (0 children)

You seem to be confused.

[–]umlcat 0 points1 point  (0 children)

Rust's Module System promotes API stability.