With server functions (and of course client/server in the same codebase/language) I also finally get why anyone would be attracted to running JS/TS on the server side.
I always thought WASM would be difficult to use. With Leptos, it’s easier than JavaScript.
I'm going to dig in a bit here: What do you mean specifcally by this? It is quite the claim! I suspect it has to do with meaning there is a low likelyhood of crashing, e.g. no type errors at runtime. My skepticism is that that general statement implies more than this.
I've seen more than one Java program that will compile, but will throw a NullPointerError that gets unhandled.
Though it is interesting that a lot of the frustration I had with C++ in my younger years were crashes for unknown reasons.
You still have to deal with errors in logic, but it's quite nice to not have to deal with all the other headaches.
From a more theoretical perspective, Rust's type system, ownership model, and borrow checker are general-purpose tools you can use to express compile-time-checked application invariants. The language and standard library use them to implement provably safe memory management, but you can also use them to prevent invalid states in your own applications or libraries. My understanding of the history of Rust's development is that the strong type system/ownership/lifetimes came first as a way of preventing logic bugs in complex concurrent applications, and only later the designers realized that system was powerful enough for full memory safety without garbage collection.
When I work with other programming languages, the experience of writing several hundred lines of code, compiling, and have them all work perfectly the first time is rare enough to be a surprise. When I write Rust, it's the norm.
I agree that "if it compiles it's correct" is a sloppy and possibly disingenuous statement. The compiler guarantees that your program is free from memory management errors and type errors; and it gives you the tools to turn most logic errors into type errors; but it does not guarantee absolute freedom from logic errors.
The other advantage: with JavaScript/TypeScript, I find myself frequently getting the output and testing my functions in JavaScript to make sure stuff works. I don't do that when doing Rust -> Rust. If it's a DateTime chrono, the behaviour will be the same.
Also TypeScript is more like type documentation that strong typing enforcement. So it does help but only a little.
If you design a program's types with this in mind - which requires a fairly powerful type system to do well - that goes a long way to achieving the other commenter's claim.
Related to this is the idea of "static debugging". Following the above approach, the type checker will alert you to many semantic bugs while you're writing the program, without needing to actually run it.
Working through this process tends to help you discover bugs that the type checker alone can't detect. The type system and checker helps you reason about the program's behavior.
The end result of this is that it does indeed tend to seem that "if it compiles, it almost always works."
That's not to say you never experience dynamic logic errors, and it can depend on the kind of program you're writing.
Another way to think about it is that good type systems are the ultimate "shift left" in the software development cycle. They allow you to detect problems about as early as you possibly can. Leveraging that can make a big difference to the SDLC.