In the relevant sense of safety, they are safer. The commenter's claim was not about vulnerabilities, since those apply to implementations, not to languages.
The semantics of F#/Scala are memory safe because they're defined to be dynamic. The semantics of Rust are not memory safe. A subset of Rust is provably memory safe, but none that uses eg. much of the standard library which is unprovably memory safe against the lang's own semantics.
It seems weird to treat stuff that Scala must rely on but you can't write in Scala as part of the implementation, and yet not do the same for stuff Safe Rust has to rely on from Unsafe Rust.
Breaking down the full argument is very subtle, sure.
But, at the outset, we can simply observe that the "safety" Rust provides is memory safety, which is a non-issue in a dynamic language.
To say that Rust is as safe, or more safe, than a dynamic lang is false. It's strictly less safe, since by construction, it is a language where allocation is managed by the programmer.
The whole argument about "saftey" in the sense Rust addresses is between languages of "manual allocation". To imagine that any of these language is "safer", is to have misunderstood a great deal. Rust is about enabling an otherwise C-programmer to limit the impact of manual memory handling, it is *not* to prevent eg,. use-after-free errors in javascript. Since there are no such errors by construction.
The same "by construction" safety applies to Safe Rust as to the dynamic GC'd languages you're discussing. You can't write a use-after-free error in Safe Rust, the same way you can't write one in Javascript.
But, Safe Rust also chooses to construct safety that those GC'd languages don't have.
The reason Javascript doesn't have data races for example is that it doesn't have concurrency - can't have a race with only one runner. Java does have data races (with limited but still unsettling consequences), Go's data races are really bad, like actual Undefined Behaviour bad in some cases. Whereas Safe Rust doesn't have data races - you can write concurrent Safe Rust but you can't write a data race.
The difference you're grappling for probably feels intuitively like it should exist, but I assure you it does not.
Theoretically, memory-safety between Rust and managed languages is equivalent.
However, memory-safe languages (i.e. not Managed C++) running on a memory-safe VM have one more layer of defense in depth than Rust. This matters in case there is a bug in the compiler or any of the dependencies. Additional layers may include, for instance, Unix and containers.
"dynamic" languages, though? That's entirely orthogonal to memory-safety and not very good for general software safety.
As far as I understand, both these languages are subject to data races whereas (safe) Rust is not.
Now, Scala is a JVM language and so presumably you get Java's rules, you aren't Sequentially Consistent but the damage is constrained - however human programmers still can't successfully reason about this state in non-trivial programs.
