I can't quite find one place that articulates well what the Swift development philosophy is and what it brings to the table besides just being modern language with shims for interacting with legacy Apple APIs.
It's a modern, fast, statically compiled, statically typed, language (that also has shims for interacting with legacy Obj-C code, but that's not a very important aspect) that unlike Go keeps up with modern PL features and expressibility, and unlike Rust has automatic RC-style memory management that you don't have to think about as much. There's no over-arching principle at play -- it's a pragmatic language.
Why would I use Swift on Linux?
Because you like the actual language and its ecosystem (or not). It's not like you should be using any language just because of some "design philosophy" it's supposed to have.
Most of the posts that I see related to Swift are RFCs evaluating solutions to problems in other languages. I rarely get to see the actual solutions being integrated into the language.
Well, there are several free books from Apple and tons of material to see what the language itself offers.
It also has a really slow compiler and that generates code which is about 2x slower than modern C++, which incidentally also has everything you mention (mostly in the form of libraries to prevent bloating the language).
It also has a really slow compiler and that generates code which is about 2x slower than modern C++
Considering it uses the same compiler infrastructure, it's mostly because of using higher level more expensive constructs. It can also generate code as fast as C++ in some cases (see the language benchmarks game).
which incidentally also has everything you mention (mostly in the form of libraries to prevent bloating the language).
Well, hard to bloat C++ further anyway. It does have a better ecosystem and more mature compilers, but on a purely language level, I'd take Swift over C++ (including "modern C++" that still comes with all the historical baggage and a trillion gotchas) any day.
C++ has header file, which is extremely bad for compile time. You can engineer around it (for example, see Zapcc, which is 4x faster than clang) but it's so difficult most don't. Since Swift does not have header file, even if Swift is higher level Swift should be faster to compile. The fact that it isn't, IMO, indicates problems in Swift frontend (which is, NOT shared with clang, hence NOT the same compiler infrastructure).
Comments
It's a modern, fast, statically compiled, statically typed, language (that also has shims for interacting with legacy Obj-C code, but that's not a very important aspect) that unlike Go keeps up with modern PL features and expressibility, and unlike Rust has automatic RC-style memory management that you don't have to think about as much. There's no over-arching principle at play -- it's a pragmatic language.
Because you like the actual language and its ecosystem (or not). It's not like you should be using any language just because of some "design philosophy" it's supposed to have.
Well, there are several free books from Apple and tons of material to see what the language itself offers.
It also has a really slow compiler and that generates code which is about 2x slower than modern C++, which incidentally also has everything you mention (mostly in the form of libraries to prevent bloating the language).
Considering it uses the same compiler infrastructure, it's mostly because of using higher level more expensive constructs. It can also generate code as fast as C++ in some cases (see the language benchmarks game).
Well, hard to bloat C++ further anyway. It does have a better ecosystem and more mature compilers, but on a purely language level, I'd take Swift over C++ (including "modern C++" that still comes with all the historical baggage and a trillion gotchas) any day.
C++ has header file, which is extremely bad for compile time. You can engineer around it (for example, see Zapcc, which is 4x faster than clang) but it's so difficult most don't. Since Swift does not have header file, even if Swift is higher level Swift should be faster to compile. The fact that it isn't, IMO, indicates problems in Swift frontend (which is, NOT shared with clang, hence NOT the same compiler infrastructure).
Unfortunately the problem here happens to be of a theoretical nature and not something a few years of engineering can reasonably fix.
Swift's slowness comes from its typechecker, not LLVM.
I mean runtime slowness, not compile time.
See for yourself:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...