Have you looked at Crystal? It has a lot of the same strengths you note that swift has, but with stronger Linux support and a more rubylike expressibilty and stdlib.

Swift is quite good for developers on Apple platforms, but isn't unique in language features nor tooling.

F#, Ocaml and Haskell come to mind.

Swift has a nice mix of features that allows you to write pretty close to functional while also allowing you to write code that compiles to the same code as equivalent C (albeit a bit more verbose).

I don't think there are any languages out there outside of Rust (which has it's own niche since Swift is ARC and Rust is more or less manual) that does the same.

F# should get a bit more love by Microsoft.

ARC is just a GC implementation algorithm with a couple of compiler optimizations to reduce counting operations.

Plenty of GC books describe such algorithms, including the canonical "The Garbage Collection Handbook".

All the languages I referred do compile to native code as well. So you can also check the generated Assembly, just like with C.

They also do provide ways of doing C pointer style tricks, use value type allocations or manual memory management.

Then there is ATS and ML Kit as well.

As language greek I do like Swift, but it isn't really meaningful outside Apple's ecosystem.

I honestly never understood why F# has never managed to get more popular. Ocaml style type system with .Net lib support would have make it an absolute killer language if it were really advocated by MS, but they probably thought the language was too different from C style to be really mainstream...

Or are there any other reason, more technical ?

I haven't done .Net for a couple years but Microsoft never really supported F#. It wasn't a full-fledged citizen in their web frameworks; you could include compiled modules that you made with F# but couldn't use it the way you use VB or C#. And you'd think a functional language would be great for data transformations in SSIS, but same deal there, just VB or C#.

Microsoft always positioned it as "use F# for the hard stuff and C# for the rest." The trouble is that C# isn't that bad for the hard stuff, and if you're spending most of your time with C#, then for you it's probably better than F#.

Microsoft's management cannot make their mind what it is good for, mainly because FP is not really something that 99% of typical enterprise developers care about.

When they made it officially part of .NET, it was the black swan of .NET languages with tooling only for libraries and command line applications.

Afterwards they attempted to position it as a language for ASP.NET MVC applications.

Then they largely left it for the community as F# was one of their very first FOSS projects.

Meanwhile the new MDIL compiler came out for Windows 8.x, followed by .NET Native, none of them support MSIL features required by F#.

Likewise .NET Core only accounted for C# and VB.NET, and they are still reimplementing type providers and the REPL for it.

Finally after all these years F# still lacks tooling for Forms, WPF and EF.

Meanwhile C# keeps getting some F# features.

Currently F# is being positioned as a language for data science with its type providers and Azure Netbooks.

Then you ought to try Kotlin! It's a lot like Swift but with great libs and tooling.

Except kotlin doesn't have anything close to swift regarding enums + switch (like : enum with associated values of various arity, and a switch that makes sure you're handling all the cases), nor regarding null safety.

And, it still has java underneath, which means everytime you're using a java lib, you have absolutely no idea what the null safety is going to be underneath (which is also the case with swift and objc libs, but which diminishes the attractivness of using the java libs ecosystem)

EDIT: also, value-based programming is highly encouraged by the full support for structs, either mutable or immutable. That's also a huge plus for safety against race conditions.

Kotlin has sealed classes (enums), when expressions (switch checking) and absolutely does have null safety. It also reinforces null safety when using Java libraries if they have nullability annotations.

Kotlin might look like Swift on the surface, but under that they're very different in how they're designed.

Surely the question of using Kotlin is dominated by whether or not you can tolerate the JVM.

you can compile to native with kotlin-native but compilation times are even more abysmal than the jvm kotlin.

What difference does that make?