It's opt-in in Swift 5 mode and opt-out in Swift 6 mode, the Swift 6 compiler supports both modes though and lets you migrate a codebase on a module-by-module basis.
Agree that opt-in sort of defeats the point, but in practice it's a sort of unavoidable compromise (and similar to unsafe Rust there will always be escape hatches)
Swift does have data race safety as of Swift 6 with their actor-based concurrency model and are introducing noncopyable types/a more sophisticated ownership model over the next few releases
Swift fits the description too
Not that specific tbh, most newer native languages these days are compiled and memory safe (Rust, Swift, Go, Kotlin Native, etc)
Coming from Haskell, OCaml always felt a bit strange to me. The double semicolons, the inconsistency in the standard library between curried and uncurried functions etc. Maybe I'm confusing it with Standard ML though, can't remember.
It took them a few years, if I remember right, though they did add the unlock-with-watch pretty early.
Counterpoint, I believe the Swift syntax strikes a much better balance than Rust in terms of ergonomics and argument labels are awesome for designing fluent APIs. There are things that Rust does better, aside from having a bigger ecosystem, namely the whole borrowing/ownership system, though they're catching up (noncopyable types and references are coming soon).
The concerns about ARC are generally a bit overstated, ARC only comes into play with classes, which modern Swift greatly deemphasizes in favor of structs, enums and protocols. Sure, sometimes you need them, especially when interoperating with Objective-C, but Rust has its escape hatches for reference counting too (Rc/RefCell, Arc/Mutex), those are just (intentionally) a bit more verbose.
In short, Swift encourages a very similar, value-oriented programming style as Rust with a modern type system (generics, associated types etc.), while offering lots of nice syntactic sugar (property wrappers, result builders etc.)
CMake can also emit its own errors during the configure step though, particularly if you have complicated build logic and/or lots of external packages.
That's mostly still true, with the small caveat that the default prefix on arm64 macOS is /opt/homebrew rather than /usr/local, so you might have to add it explicitly to your PATH
Projects for Apple platforms usually also use .h, where it could mean anything from C/C++ to Objective-C/C++.
In practice, Clang handles mixed C/C++/Obj-C codebases pretty well and determining the language for a header never really felt like an issue since the API would usually already imply it (declaring a C++ class and/or Obj-C class would require the corresponding language to consume it).
If a C++ header is intended to be consumed from C, adding the usual #ifdef __cplusplus extern "C" {... should alleviate the name mangling issues.
or Swift, Rust has semicolons while Swift doesn't
Tbh rust-analyzer is still pretty great. What bothers me more is that Kotlin is pretty much the only language without an official language server, because it doesn't align with their business interests...