On the other hand, you can kind of make your own language within Swift because most of the keywords aren't required but allow some additive features. For example, some features help you write your code functionally and others support a declaritive style. It reminds me of what's going on with Babel and JavaScript, where babel extensions are like these language plugins you can mix and match to create your own language.
If you think of metaprogramming as a way to build your own language within a language, lisps and Ruby were kind of like pioneers of a build-your-own-language trend. I could see that as an interesting direction, I wonder if people have tried it before.
[1] https://medium.com/the-traveled-ios-developers-guide/swift-k...
> you can kind of make your own language within Swift
This is one of my favorite aspects of working with Swift. Because it's a relatively un-opinionated language with a diverse toolkit, and because of the powerful type/protocol system, it can really feel like you can carve out a DSL for each specific use-case.
"Progressive Disclosure" is an interesting idea for PL research, but IME Swift doesn't do a very good job at it. There's a million cases I've seen where people trying to do simple things run into a pandora's box of complexity (e.g., the infamous "Protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements"). There isn't really a "small subset" I've found that's usable for anything but the absolute simplest programs. Even the fundamental types like Int and String have a lot of not-entirely-hidden complexity in Swift.
> Because it's a relatively un-opinionated language
It seems awfully opinionated to me. There is a clear preferred way to write almost anything. Ask online about how to do things differently, and you'll be told to do it in a more "swifty" way.
> because of the powerful type/protocol system, it can really feel like you can carve out a DSL for each specific use-case
I'll have to see if the new features in the latest versions of Swift (used for SwiftUI) enable this more readily, but as of 4.2, anyway, writing DSLs in Swift is moderately limited and painful.
That's a big reason why I don't like it. I also can't stand func, let, and var. Because func and var are totally useless, and let is the wrong word (should be const at least).
There is also all the question marks and other confusing syntax.
Summary
Number of keywords: 310
Out of curiosity, when's the last time you worked with Rust? A lot of the lifetime's have been able to be elided in recent releases, especially in the 2018 edition. That's not to say that you don't still run into them, but in the middle of the road cases, it's much less frequent that you run into them unexpectedly.
I haven't been able to narrow down exactly what it is, but with Swift I can just put pencil to paper. With Rust I feel like I need to plan more, I dunno.
I do think my experience is colored by tooling, though
I'd love to see a Rails like framework come to Swift. I don't think we'll ever see that.
For me personally, Swift is often fast enough for my needs as a compiled language, but it's so much easier to be productive in since it obviates many of the more tedious concerns of Rust.
Both languages play nicely with the C FFI so it's also possible to write high-level code in Swift and drop down into C or Rust for the performance sensitive parts.
Apple Swift developers are actively working Linux support, but I suppose it'll forever remain a second-tier platform to iOS & macOS. Kind of like C# to Windows, but Swift doesn't have its Miguel de Icaza to create its Mono on Linux.
I'm sure the Swift team is well aware of this cultural bottleneck, hence the current efforts to support Linux, but it remains a cultural chicken-and-egg problem.
OCaml is single-threaded, yes, but in practice that's not a big deal. There's a great concurrency library (Lwt) and the recently-added monadic (and applicative) bind syntax makes it look almost like sequential code. And if you really need a separate OS thread, there are ways to do that :-)
Last I checked, Swift still does concurrency mostly with Node-style callbacks.
But I do remember having to implement myself protocols for standard library types, most of them obviously belonged to the standard libraries, they even had theses protocols as examples in Apple's docs.
The language is truly great, but was not ready for primetime out of Cocoa apps.
Has anything changed?
https://discuss.ocaml.org/t/multicore-prerequisite-patches-a...
For a while I was enamored of Haskell and its famed "if it compiles it works" saying, but I think I've realized that the features that contribute to that are: non-nullability and algebraic data types. Turns out I don't particularly like the extreme functional nature or (especially) the lazy aspect of it.
Rust is almost there, but then I'm dealing with lifetimes and working a little lower than I usually need. But I found I _love_ its exhaustiveness checking for enum variants.
The ML family is pretty much in my sweet spot, for some reason it doesn't really get the love that it seems it deserves, and last I heard Ocaml had an issue with being single threaded.
So that leaves Swift, with its non-nullability, algebraic data types, and exhaustive enum pattern matching. The only downside is its focus on Macs! I'm holding my breath, waiting for it to run just as smoothly on linux, and developing some developer cultural cachet and libraries for servers. I hope it does! I'm glad to see in this article that it's being used more and more at Apple.
And with SwiftUI, which looks pretty promising, I have to imagine it will only continue to grow in popularity.