Swift is changing fast. Chris Lattner has stated that Apple will have a good migration solution to update current Swift code. If Apple does it right, Swift will be a major cross platform language within a few years.
You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage.
Simply look at the number of Swift books published in the first 18 months:
If anything, I'd argue that we're in the middle of a fantastic time for languages. I have at my disposal Go, Rust, Swift, and Nim, not to mention a re-emergence of Erlang (and birth of Elixir), Clojure on the JVM (and what the heck, Java)...
There's so much happening in languages now, it's a wonderful time to be a developer! People will always argue about which is the best, why Go needs generics, etc., but when you're a "right tool for the job" kind of developer, your toolbox is looking pretty sweet right about now.
I recently did a game jam with my brother where we wrote a small OS X game in a weekend in Swift using SpriteKit. It was quite fun, and Swift was really pleasurable to write in.
These changes look great and will really improve the clarity of the standard API, and are just good coding guidelines in general.
I write web applications all day, and no current web language is as fun to write in as Swift.
I'm not sure about dropping "Type" from protocols because it's pretty commonly used to separate the protocol definition (which is extended to provide most of the implementation) from the concrete base implementation, e.g. RAC's SignalProducerType/SignalProducer.
However, you cannot write a protocol for "things that can be flatMapped", because you cannot refer to a Self<T> specialized with a different type (Self<R>). With HKTs, you can do that, which would let you write something like this:
protocol FlatMappable
{
typealias Value
func flatMap<R>(Value -> Self<where Value == R>) -> Self<where Value == R>
}
That's not useful on its own, but it means that you can now write functions and extensions that reason about the general concept of anything FlatMappable (this is most of the way to what is known as monads, FWIW).
Databases are fine, but blogs change infrequently and mostly serve the same static content. Caching the database-generated pages, or just serving static files, if much more efficient, especially when a crowd comes.
Can better blogs be built on top of Google's App Engine? I've been building on top of it with Go but I don't use app engine's data store, and I'm not sure that I want to. My little database is a pregenerated Go variable.
You can run a blog on a cloud platform, set up auto-scaling, and withstand a reddit / hn / slashdot crowd.
You will likely run out of the free tier and into significant spending during the spike pretty soon.
If you ran a highly interactive page that required a lot of non-trivial server-side processing, I'd understand.
But blogs serve the same static content to almost every request. I don't see why burning a whole lot of CPU and IO on it by running python/php/ruby and hitting a database many times is worth it. Serving a set of static files automatically generated by a blog engine (like Jekyll) seems much more reasonable to me.
Regarding comments: Disqus or something like that could help. Or you could turn the comments off during a spike: seeing the content without comments is a much better user experience than seeing a 500 Server Error page.
I'm basically glad to see the Type suffix removed from the standard library protocols. I'm hoping that they'll have a solution to make it so writing a function over a generic sequence isn't such a mouthful.
I'm a little flummoxed by the new effort for first argument labels. Function names often imply the meaning of their first arguments very effectively and the new splits in function names seem arbitrary at times. Labeling subsequent arguments is an excellent feature of Swift but first argument labels often seem to complicate the syntax, especially labels like of: which don't always imply much about the meaning of the argument by themselves.
The function name often includes the name of the first argument just by virtue of it being spelled out. Current Swift function names are usually two parts, one part for the function itself, and one part that indicates the meaning of the first argument. For example, consider removeAtIndex, substringWithRange, or joinWithSeparator.
To me, it makes a lot more sense to just call these remove, substring, and join, and label the first argument to express what's removed, substringed, or joined with. This makes the first parameter consistent with subsequent parameters, and makes the actual function name purely about the function's, uh, function.
In my brief experience with Swift the first argument convention struck me as a little weird. I ended up adding labels anyhow as it made more sense to me. Glad to see this being embraced.
Why wouldn't you? Most websites run on some sort of database. Technology can fail, especially when facing a higher load than expected but generally relational databases are among the most mature technologies in computing.
Removing technical dependencies to avoid such problems is throwing the baby out with the bathwater.
Besides, WordPress is dead simple to set up on almost any shared hosting plan. The static blogging solutions you probably have in mind for the most part aren't.
There's a pretty massive difference in the amount of effort needed to publish a post with either of those approaches vs. just typing it into the WYSIWYG editor on WordPress. If your time is worth $60/hour then you're looking at around ~$10/post in additional time spent. You also lose a bunch of features: comments, trackbacks, RSS, etc.
Git commit and push takes a minute or two tops I fail to see how that is less efficient than clicking save in a WYIWYG editor. The setup time between the two options is probably very similar.
You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage. Simply look at the number of Swift books published in the first 18 months:
http://www.h4labs.com/dev/ios/books