What does Cargo the rust package management tool have to do with make, the declarative build system? It would seem they are unrelated to an outsider such as myself.
Work goes on, and how I want to use, say, a library for a hashmap of some kind. In my C project, I would probably be adding a git submoule, and then modifying my make files to build the dependency, and configure how to link it in with my code. With Cargo, I add a line to my Cargo.toml, and "extern crate bar" to my source file, and upon the next "cargo build", Cargo will handle the downloading, compiling, and linking of that library, as well as any sub-dependencies it has.
Now, it's also true that make is broadly more general than Cargo, and so in some circumstances, you'll use them together. I have a hobby OS project, for example, and so I have a Makefile which calls nasm to compile the assembly, cargo to compile the Rust, and ld to link the two together. Eventually, I would hope that Cargo can do it all, and I could probably make it work, but it's not inherently bad to use make either. Stuff like operating systems are the only case where I've felt that need; Rust itself is currently built with Make, because it pre-dates Cargo, but we're in the process of cargo-ifying our build as well.
Does that make sense?
I am pleased to hear that Cargo, rather than attempting to be a rust-specific make replacement, is a tool that obviates the need for using make or make-like tools by automating the things you would have used it for, only.
Make and Cargo together sounds like just what I wanted to hear, and your hobby OS project sounds like fun.
Finally, I think it's great that Rust will be using Cargo itself soon, but I am curious if the reverse is possible -- if I want to put in the extra effort, can I build my own rust software in make alone WITHOUT Cargo?
Thanks again.
I disagree. For the most part, you don't have to worry much about lifetimes in Rust once you have programmed in the language for a bit. It's a learning curve, like any other (functional languages have their own learning curve). There are cases now and then when you do have to think about it, but mostly it's either quickly fixing mistakes caught by the compiler (like any other type error, and this reduces as time goes by), or writing the correct code from the get-go.
That doesn't make Rust a better choice than the functional languages, but it certainly doesn't make it worse.
(of course, there are other reasons as to why Haskell/etc might be a better option for these people)
Sean Griffin, the current maintainer of ActiveRecord, has been writing an ORM in Rust. He specifically has been saying quite a bit that the safety aspect is almost irrelevant to him, he sees Rust as a "practical Haskell".
It's also true that there's a lot of stuff we have that's _because_ of safety but isn't interesting because of safety. For example, memory safety is at the core of our concurrency story, but the end result is "compile-time errors for concurrency bugs", which is much more interesting than "safety".
TL;DR: marketing is difficult. Messaging is tough.
On the other hand, GC allows for faster and easier programming without the need to reason about lifetimes, like you would have to do in non-GC-languages like C and Rust. Java, Go and C# are fast enough to do a lot better than scripting languages, plus they are statically typed and safe.
I think that what Rust provides for user of those languages, has more limited scope: mainly squeezing the last drops of perf, and especially doing some realtime programming.
Edit: One additional pro of Rust is that it managed resources like files and sockets very robustly with its type system, which may help prevent bugs. That's a thing CG won't do for you.
Rust is a programming language. It's a general programming language, so it's good for a large variety of things. Different people have different reasons for using Rust. There are three large constituencies, as I see them: systems programmers, functional programmers, and scripting language programmers.
Before I get into details: all generalizations are false ;)
Systems programmers come to Rust because it's able to do the lowest levels of software: operating systems, device drivers, stuff like that. Where it improves on existing systems languages is "safety." The Rust compiler does a lot of compile-time checking to make sure you don't do things wrong. Existing languages force you, as the programmer, to double check your work. We have the compiler double-check your work, and force you to get it right.
Functional programmers see all that static checking, and it feels like home. But a home where they have significant speed gained. Functional languages can be fast, but not always C level fast. Rust is. It's easier to get that level of performance out of Rust.
Scripting language programmers come to Rust for two reasons: the first of which is to write extensions to their language for speed. You can write a Ruby gem in Rust, rather than in C. This is useful because this low-level stuff is not their expertise, and so the extra checks are really nice. Related: we have a lot of the nice tooling that scripting language folks have come to expect from their language. No need to write makefiles, we have Cargo. The second is sort of related, but these checks also mean it's easier to learn low-level stuff, so if they want to expand their universe, Rust is a nice way to do so. We're seeing a lot of people for whom Rust is their first systems language.
I didn't know where to put this one, but Rust focuses on a concept called "zero-cost abstractions." This means that a lot of our features that feel very high level are extremely efficient. You don't write manual for loops, you se iterators. You don't deal with pointers directly, but with references. Structures like Box and Vec do memory management, but you don't need a garbage collector, and you don't need to manually manage it, but you also don't need to explicitly call free().
These are very broad strokes. Lots of other people have other reasons too. But that's some of them.