Technology

That sounds a lot like how checked exceptions work, though with some terser handling syntax.

But they are not the default option. And your new job may not use them.

Who cares if it's the default? If it's the best tool, use it.

It's silly to have a reason for "going Rust" be the build system, especially in the context of something as new as a WASM context where basically any project is going to be green field or green field adjacent.

Exceptions is a non standard exit point. And by "non standard" I'm not talking about the language but about its surprise appearance not specified in the prototype. Calling double foo(); you don't know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?

And that's a feature not a bug; it gets incredibly tedious to unwrap or forward manually at every level.

By contrast fn foo() -> Result<f64, Error> in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it's good:

You can do this in C++ https://en.cppreference.com/w/cpp/utility/expected (and as I said, if you feel so inclined, turn off exceptions entirely); it's just not the "usual" way of doing things.

Hell yes! That was the point of my rambling though I never quite got there. I was wondering if curriculums had caught up yet, to at least look at the modern system languages. Sounds like you’re at a good program.

Thanks, Rust by Example looks ok, and I'm acquainted with one of Programming Rust's authors, which is cool. I'm currently looking at "Comprehensive Rust". All these though seem to be about the Rust software ecosystem (compilers, package tools, libraries) as much as they are about the language. I had hoped to start by just reading about the language, if something like that exists. I don't particularly want to write any Rust programs until I've finished reading some kind of language overview, which means that all the stuff about build tools are just a distraction during that stage. As another commenter in this thread said though, ecosystems and languages have become pretty much inseparable, so maybe that's why the books are that way.

This also looks interesting:

https://dr-knz.net/rust-for-functional-programmers.html

This says nothing about Rust, but it's a humorous classic. I'd be interested to know how to describe Rust in these terms.

https://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html

I know that the "project" approach to learning a language works for some people, but I've found l greatly prefer to read a book from beginning to end before undertaking any projects. It helps me start out with a clear picture. I'm finding "Comprehensive Rust" to be fairly good so far. Thanks for all the help, everyone.

Thanks, I was looking for a more straightforward academic-style textbook for non-beginning programmers, but I'll make do with what is out there.

Front end

I assume you're talking about runtime. AddCleanup()? That's certainly nice, but it's not the same as a destructor since it only runs at GC time. It's useful for cleaning up data used by a shared library or something (e.g. something malloc'd by a C lib), but it only solves part of the problem.

I'm talking about scope guards. In Rust, here's how you deal with mutexes:

{
    let value = mutex.Lock();
    ... use value ...
    // mutex.Unlock() automatically called
} 

The closest thing in Go is defer():

mutex.Lock()
defer mutex.Unlock()

That works most of the time, but it doesn't handle more complex use cases, like selectively unlocking a mutex early while still guaranteeing it eventually gets unlocked.

Rust fixes this with the Drop trait, so basically I can drop something early conditionally, but it'll get dropped automatically when going out of scope. For example:

struct A(String);

impl Drop for A {
    fn drop(&mut self) {
        println!("dropping {}", self.0)
    }
}

fn main() {
    let a = A("a".into());
    let b = A("b".into());
    let c = A("c".into());
    drop(b);
}

Without the last line, this prints c, b, a, i.e. stack order. With the last line, it instead prints b, c, a, because I drop b early.

This is incredibly useful when dealing with complex logic, especially with mutexes, because it allows you to cleanly and correctly handle edge cases. Things are dropped at block scope too, giving even more control of semantically releasing things like locks.

That said, 1.24 added WASM, which is really cool, so thanks for encouraging me to look at the release notes.