Why is Rust being used to replace parts of the JavaScript web ecosystem like minification (Terser), transpilation (Babel), formatting (Prettier), bundling (webpack), linting (ESLint), and more?
Is a modern language with a good build system (It’s like night and day compared to CMake)
Meson exists … as do others.
But they are not the default option. And your new job may not use them.
And I just like how the language works (errors as values etc.)
Fair enough; though why? What’s wrong with exceptions?
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 doublefoo(); you don’t know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?
By contrast fnfoo() ->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:
foo().unwrap() panic in case of error (see also expect)
foo().unwrap_or_default() to ignore the error and continue the happy path with 0.0
foo().unwrap_or(13.37) to use your default
foo()? to return with the error and let the parent handle it, maybe
Checked exceptions require a function to declare the exceptions it can throw. The caller function must then catch and handle the exception, or the exception would bubble up a level, in which case the caller must also include that exception among the exceptions it declares that it can throw. I don’t know if C++ does this, but Java/C# do. It sounds exactly like Rust’s system except with different 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:
But they are not the default option. And your new job may not use them.
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 ?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:foo().unwrap()
panic in case of error (see alsoexpect
)foo().unwrap_or_default()
to ignore the error and continue the happy path with 0.0foo().unwrap_or(13.37)
to use your defaultfoo()?
to return with the error and let the parent handle it, maybeThat sounds a lot like how checked exceptions work, though with some terser handling syntax.
First time I hear about checked exceptions. How do you use them ? Are you forced to handle them explicitly ? Is the handling checked at compile time ?
Checked exceptions require a function to declare the exceptions it can throw. The caller function must then catch and handle the exception, or the exception would bubble up a level, in which case the caller must also include that exception among the exceptions it declares that it can throw. I don’t know if C++ does this, but Java/C# do. It sounds exactly like Rust’s system except with different syntax.
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.
And that’s a feature not a bug; it gets incredibly tedious to unwrap or forward manually at every level.
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.