Rust is Eating JavaScript
-
Is this a 2yo write up, considering the last update was in 2023?
It was recently shared on Hackernews, I assume that's why it's showing up here now.
-
This post did not contain any content.
lmao.
rust seems pretty desperate to remain relevant.
"rust is replacing c"
"rust is replacing the Linux kernel"
"rust is replacing javascript"
"rust is replacing your mom" -
lmao.
rust seems pretty desperate to remain relevant.
"rust is replacing c"
"rust is replacing the Linux kernel"
"rust is replacing javascript"
"rust is replacing your mom"well, joke's on you. Since I rewrote her in Rust, my mum runs the 100 meters hurdles in 14 seconds
-
- It's statically compiled and isn't dependent on system binaries and won't break if there if the system has the wrong version like C/C++, allowing you to distribute it as a single binary without any other installation steps
You can do that with C++ too.
- Still produces fairly small binaries unlike languages like Java or C# (because of the VM)
I mean, the jars are actually pretty small; but also I really don't get the storage argument. I mean we live in a world where people happily download a 600 MB discord client.
- Is a modern language with a good build system (It's like night and day compared to CMake)
Meson exists ... as do others.
- And I just like how the language works (errors as values etc.)
Fair enough; though why? What's wrong with exceptions?
I work in a code base where I can't use exceptions because certain customers can't use exceptions, and I regularly wish I could because errors as values is so tedious.
- 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
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, maybe
-
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
Droptrait, 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.
Thanks for taking the time to explain it. Indeed the new runtime method does not guarantee when the resource will be cleaned, so something like that Drop trait would be quite useful
-
- 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
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, maybe
That sounds a lot like how checked exceptions work, though with some terser handling syntax.
-
Sure you can spawn threads but now you have all the hazards of shared memory and locks, giving the 2.0 version of aliasing errors and use-after-free bugs. Also, those are POSIX threads, which are quite heavyweight compared to the in-process multitasking of Golang etc. So I would say that's not really an answer.
What exactly are the hazards of shared memory and locks? The ownership system and the borrow checker do a pretty good job at enforcing correct usage, and if you are clever you can even guarantee no deadlocks (talk at rustconf 2024 about the fuchsia network stack).
-
- 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
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, maybe
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 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.
-
That 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 ?
-
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.
-
System shared this topic
