I take that as a challenge. :)

But yes, that compiler checks and awesome linter is one of the main reasons I use Rust. I like working with concurrent and parallel code, and Rust makes that really safe.

my python doesn't need to parse to pass cI, at least to long as I don't write tests that run that code section. Checkmate all languages that have to compile. /s

I am the user base and, despite my best effort, have not yet turned into a liquid. If I kill my project, does it count? Can I be Alphabet now?

I think your quantifier of “any other language” is the issue. There are certainly languages with far more powerful type systems than Rust, such as Coq or Lean.

You can leak memory in Rust if you want to (and it’s occasionally desirable). What the type system prevents is mainly accessing memory that has been deallocated. The prevention of memory leaks uses RAII just like C++. The main difference related to allocation is that there’s no “new” operator; you can pretty much only allocate memory through the initialization of a smart pointer type.

Dependency management has to deal with the real world where what we didn't know in 1970 hurts us.

If you know a better one I’d love to hear about it

OCaml’s OPAM. They actually took into account that it could be desirable to use software written in other languages in your OCaml project. It even has a bunch of stuff packaged that’s written in Rust. Imagine that the other way around. It only has stub packages for compilers like gcc but I assume that’s likely because they don’t want to have people spend hours building the whole thing themselves when there’s a perfectly good one on their system, rather than it not being possible to do.

I love Rust but I will die on this hill that combining package manager and build system like Cargo does and then only making it work for a single language is a lot worse than what C++ does, because if it doesn’t work for your project you’re screwed. Everything expects you to use Cargo, especially if you intend to publish a library, with C++ you can at least pretty much always get the build setup to do what you need, and you can import whatever as long as it comes with a pkg-config file.

Added on top of that is a modern dependency management system that is severely needed in languages like C and C++

You’re looking for Nix (unless you’re a Windows developer, work on getting that to work is ongoing). There’s very likely other good ones too, but this is the one I like and am familiar with. The difference is that it’s not a package manager for C++, but a package manager that also packages C++ packages. Which makes it so much more versatile than something like Cargo, because you can accurately represent dependency chains regardless of what language each package is written in. My Nix + CMake projects will build consistently on every Linux or Mac computer (you can’t say the same for Rust crates because they will look for stuff in system directories because Cargo can’t package anything that isn’t Rust), and you can depend on them similarly to how you would a Rust crate, with the difference that you can depend on them not only in another C++ project, but also in a Python package, a Go package, or whatever else that can be packaged with Nix. And if you can’t use Nix, then you can always build the CMake project directly, package it somewhere else maybe, because the two parts are not coupled together at all.

It is fair to compare speeds, I just think it’s probably the wrong argument to focus on if you’re trying to convince people of the value of a language. It’s definitely a supporting point, but at the end of the day, most programs don’t actually need to be blazingly fast, they just need to not be dog slow. Ease of writing (correct) code and even more importantly maintaining and debugging code are generally far more important factors in a languages success, and those are all areas that Rust excels in.

The problem with a purely speed focused argument is that it’s always possible to cherry pick examples in both directions. You can find some piece of idiomatic Go code that just happens to be faster than the equivalent idiomatic Rust code and vice versa. The fact that it’s undoubtedly much easier to find idiomatic Rust code that out performs most Go code (idiomatic or not) is a much harder argument to use to convince people. The Go proponents will just argue that the ease of understanding the Go code outweighs whatever speed gains Rust has. That’s why I think it’s important to also point out that Go might be easier to write small snippets of, but for any realistic program it’s going to be harder to write and maintain, and it will be more prone to bugs.

My point is that with C++, the programmer must often play a puzzle of avoiding common pitfalls with e.g. memory allocation - on top of the actual problem the programmer is intending to solve.

Both Rust and Go are more free from this kind of extra mental overhead.

This isn’t entirely correct. Rust you do still need to worry about those same problems, it just gives you much better abstractions for modeling and thinking about them, and the tooling of the language “checks your homework” so to speak to make sure you didn’t make any mistakes in how you were thinking about it. The upside is that you can be very specific about how you handle certain tasks allowing you to be super efficient with resources. The downside is that you do still need to worry about those resources at least a little bit. If you wanted to you could write Rust like Go by just making every variable a Box<Arc<…>> and using .clone() like mad, but your performance is going to take a hit.

Go (and other GCed) languages on the other hand, do entirely free you from having to worry about memory utilization in a general sense as the language runtime takes care of that for you. The downside is that it often does a poor job of doing so, and if you do run into one of the edge cases it’s not so great at your tools for dealing with that are severely limited. Further it’s very easy to accidentally screw up your memory usage and use far more than is necessary leading to excessive heap churn and serious performance degradation. Because the language makes it easy, even if what you’re doing is wrong, and it lacks the tools to alert you to that problem before you trip over it at runtime.

Having a simple and verbose language is not necessarily a downside.

As programmers, our bread and butter is abstractions. We use abstractions because in a very real sense what we do day to day if we removed all the abstractions would be a herculean effort that not even the best of us could manage for any period of time. Go’s idea of “simple” is limiting the number of abstractions that the language provides, and so it’s up to the programmer to use that small handful to construct more powerful ones. Every code base becomes a snowflake where each team rolled their own solution, or everyone just uses the same sets of libraries that provide the solution. You haven’t removed the complexity, you’ve just shifted it out of the language and onto a 3rd party. It’s better to have a consistent set of abstractions provided and maintained by the language and centrally developed by everyone, rather than a hodge-podge of abstractions by random 3rd parties.

Can confirm, I was super excited about D about 10-15 years ago when all of that had recently been resolved. It’s a really cool language, but it didn’t really get much traction and Rust solves a lot of the problems I have with it, so I use that now.

That said, here are some features I really miss from D:

• compile-time function execution - basically write macros in D; I saw some madlads writing a complete shader render loop at compile-time
• opt-out garbage collection - you get GC by default, but it’s pretty easy to make portions or all of your code safe w/o it
• explicit scopes for finalizers - destructors can be run deterministically instead of “eventually” like in many GC languages
• safeD - things like tagged pure and safe functions; basically, you can write in a checked subset, but it’s opt-in, unlike Rust’s opt-out
• nice functional syntax
• reentrant coroutines
• really fast compiler

But at the end of the day, Rust provides more guarantees, enough features, and a fantastic ecosystem. But if both had the same ecosystem today, I would give D a serious consideration.

static if (condition) {
    ...
}

int fun(ref int a, int b)
in
{
    assert(a > 0);
    assert(b >= 0, "b cannot be negative!");
}
out (r)
{
    assert(r > 0, "return must be positive");
    assert(a != 0);
}
do
{
    // function body
}

fn do_stuff() -> Result<...> {
    if condition {
        return Error(...)
    }

    return Ok(...)
} out (r) {
    if r.is_err() {
        // special cleanup (maybe has access to fn scope vars)
    }
}

fn do_stuff() -> Result<...> {
    let ret = if condition { Error(...) } else { Ok(eee) };

    if ret.is_err() {
        ...
    }

fn do_stuff() -> Result<...> {
    if condition {
        return Error(...)
    }

    return Ok(...)
} out (r) {
    if r.is_err() {
        // special cleanup (maybe has access to fn scope vars)
    }
}

fn do_stuff() -> Result<...> {
    if condition {
        // special cleanup (maybe has access to fn scope vars)
        return Error(...)
    }

    return Ok(...)
}

This happened to Scala with cats vs zio. I’m sad it wasn’t more successful, it’s a really, really good language

Rust had the same issue with tokio vs. async-std. I don’t think this was ever resolved explicitly, async-std just silently died over time.

Without static type annotations you can only make best effort guesses that are sometimes right. Better than nothing but not remotely the same as actual static types. The LSP you linked works best when you use static type annotations.

Also I would really recommend Pylance over that if you can - it’s much better but is also closed source unfortunately.

if random() > 0.5:
    x = 2
else:
    x = "hello"

class Foo:
  bar: int

class Baz:
  bar: str

def a(f: Foo) -> int:
  return f.bar + 1

def b(f: Baz) -> str:
  return f.bar + "1"

def get_price(x):
   return x.prize

Yeah I agree. The borrow checker definitely pushes you to write less buggy code.

True, but ownership does eliminate a lot of the possible sources of them.

My company is just doing a kanban board with weekly meetings to discuss the progress and what tickets will be worked on next. The major problem we ran into was when management asked “So, when is the release going to be? When are you done with that project?” about one month before we actually released. I simply had no answer at that point, because that’s not something these tickets with no estimates and no velocity tracking can provide.

IMO if it is so hard to do right that somehow no company can figure it out, then the whole system must be garbage. The best we can get to is the direct time estimates so that the “velocity” calculations we’re graded on make sense. Still going to be bogged down in ceremony no matter what we do tho.

Oh I agree. But my god the embedded industry is slow to update toolchains.

I would love to have Rust as an option for my ARM development, but that’s years off. ARM is only now about to come out with a visual studio based toolchain for their Keil C compiler instead of the proprietary IDE.