> You've got it backwards. You need libraries for the benefits of something like crates. (Centralised artefact control, version/dependency management, etc etc).
You do not need to invent yet another thing like crates to provide that functionality - it already exists elsewhere and has done for a long time. All you are doing with crates is re-inventing the wheel and needlessly tying it into one specific programming language.
> You're suggesting a language designed in the 21st century shouldn't learn any lessons from what went before?
I'm suggesting that those features you list are NOTHING WHATSOEVER TO DO WITH *A* PROGRAMMING LANGUAGE and should not be tied into one.
In the 21st Centrury you should be using an entire environment, which caters for multiple programming languages, to gain all those features.
An actual language, in the 21st Century, should have realised that it is *NOT* the centre of the entire universe and there are many projects that use multiple languages (making a suitable choice for each portion of the project). If the new language really, really tries to push its own version of "crates" then it is either totally unaware of what has gone before (it has itself failed to learn) *or* it is deliberately making it difficult to introduce itself into a non-trivial project.
> They don't cope admirably. Dependency resolution can be a right PITA. (We have a folder full of all the delphi libraries we use, and a very long include directive developers just end up pasting into their IDE settings.)
It is not the job of the language to deal with those things. You have pointed out that all those good, well-tried-and-tested were, to you, a PITA. That is because you had not bothered to look for any tooling to help you - which is why you so like crates, as it has been dropped into your lap without your bothering to do any work.
I work with multiple languages across multiple platforms (host and target) and yet find dependencies really quite easy to handle. How? I have a Build Environment (currently, built upon Gnu Make with a couple of extra little tools) - I list the libraries that I want to *explicitly* use and the Build sorts out all the dependencies, complains if it can't be done, and pulls it all neatly together. Similarly, I have a working version control setup. So on and so forth. None of this setup favours anything over anything else.
 I keep thinking I ought to write this up and publish it, that would make it so much easier to point to real examples, but so many more fun thingss to do.
>> Java has less control, but not so much at the build end
> Java has the (old) maven and gradle,
I explicitly say *not* at the build end - and all you can do is talk about the build end? BTW, mentioning yet more tools that are targeting one language (Java) over anything else, making realistic non-trivial projects a PITA.
> Exactly, that's the problem, people use the tooling badly, because they're either lazy, uneducated, rushed or simply don't care.
Yes, yes, absolutely. Which is why I am surprised at you supporting the tight connection (that people are pushing) between Rust and crates, when, after all your education and time spent on looking at the tools already available and working.
> Don't confuse people using tools badly with bad tools.
Huh? I thought I'd been yapping on (and on and on) about the fact that there are perfectly good tools out there! And bemoaning that people don't want to use them (harping back to an earlier comment of mine: people - put non-trivial configuration files under version control, please!).