Why Rust, or a Trip Report from My Satori with Rust and Functional Programming

You should consider plain Java tbh. Java 15+ is basically Kotlin anyway at this point. It's much easier to hire or outsource Java developers.

Java, C# and C++ control it via compiler flags, and also have the ABI issue across language versions.

I like rust's syntax. It has very elegant macro syntax, expressions are values, and all that other good stuff.

There are some small parts of it that are ugly, but honestly Java and C++ are far uglier. Templates in c++ are awful. Java's wildcard syntax and lack of macros is ugly.

I find rust much prettier syntax-wise than most statically compiled languages. Prettier than Go or Java or c++.

> In terms of ease of getting started and using tooling, it really can't ever compete with the corporate languages like Go, Swift, Kotlin

Why not? I don't see any reason why it can't compete. Heck, it's a pretty corporate language too in terms of its mozilla backing.

That being said, people constantly talk about how easy it is to get started with python, and python has even less corporate backing than rust. That point makes no sense to me.

> C++ had the same safety characteristics for at least a decade with dozens of linters and sanitizers on the market

C++ does not, and did not, have safety features like rust's. C++ cannot guarantee ownership semantics are correct. It cannot identify data-races at compile-time. Leaving dangling references in C++ is trivial.

For example:

    std::vector<int> v = {1};
    auto ref = &v[0];
    v.push_back(10);
    std::cout << *ref;

In short, I don't think you have a complete understanding of what rust's benefits are nor why it's innovative.

The borrow checker in rust has no runtime overhead (whereas go's race flag is runtime only, and has so much overhead you can't turn it on in prod). In addition, the borrow checker catches data races, but it also catches more subtle ownership issues too!

For one example of an ownership issue which isn't also a concurrent data-race, let's look at something in go that the -race flag doesn't catch, but that the borrowchecker in rust does:

    // go
    b := []byte("foo bar")
    foo := b[0:3]
    fmt.Println(string(foo))
    b = b[:0]
    b = append(b, []byte("not foo")...)
    fmt.Println(string(foo))
    // prints "not"
    // This is because 'foo' is actually "borrowing"
    // bytes from b, but go doesn't have any way to indicate
    // that said "borrow" is active, so writing to it might be a bug.

Now let's try to write code that has that same bug in rust:

    let mut b = "foo bar".as_bytes().to_vec();
    let foo = &b[0..3];
    println!("{}", String::from_utf8_lossy(foo));
    b.truncate(0);
    b.append(&mut "not foo".as_bytes().to_vec());
    println!("{}", String::from_utf8_lossy(foo));

If you try to compile it, you'll see that it doesn't compile with the following error: "error[E0502]: cannot borrow `b` as mutable because it is also borrowed as immutable"

In the rust code, the borrow checker keeps track of the fact that "foo" is currently a reference into "b", and because of that, it knows that it shouldn't let the programmer modify the memory out from under "foo".

This is just one of many examples I could give, but hopefully it provides some explanation of how the borrow checker is more flexible than just race detection.

Basically, there's a lot of cases in programming when it's useful to have a function which takes ownership of an object and turns it into something else, or borrows an object temporarily but then gives back ownership. In languages like go, the fact that "close(channel)" means that the channel can't be written to again is a runtime guarantee. In rust, it can be expressed to the compiler that 'channel.close()' means that channel is gone and using it again is a compile time error. Ownership ends up being a really common concern, and the borrow checker handles it nicely.