Swift Evolution acceptances: The big three(ericasadun.com)
ericasadun.com
Swift Evolution acceptances: The big three
http://ericasadun.com/2016/03/03/swift-evolution-acceptances-the-big-three/
36 comments
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.
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.
We are indeed in a great space right now.
At QConLondon next week, I'm hosting the "Modern Native Langauges" track which will have presentations on Rust, Go, Pony and Swift:
https://qconlondon.com/track/modern-native-languages
The presentations are being recorded and will be published at http://www.infoq.com/qcon-london-2016/ over the next few months (you can see last year's conference content at http://www.infoq.com/qcon-london-2015/ if you're interested).
It's certainly a great time to be a developer with an interest in languages!
At QConLondon next week, I'm hosting the "Modern Native Langauges" track which will have presentations on Rust, Go, Pony and Swift:
https://qconlondon.com/track/modern-native-languages
The presentations are being recorded and will be published at http://www.infoq.com/qcon-london-2016/ over the next few months (you can see last year's conference content at http://www.infoq.com/qcon-london-2015/ if you're interested).
It's certainly a great time to be a developer with an interest in languages!
Sadly many of us don't get to chose what languages are used at work.
You have my Swift Essentials book listed (one of the first, published in 2014) but the second edition came out covering Swift 2 last month:
https://www.packtpub.com/application-development/swift-essen...
There's a discount available until 20th March:
50% on eBook: SSEE50 30% on Print: SSEE30
https://www.packtpub.com/application-development/swift-essen...
There's a discount available until 20th March:
50% on eBook: SSEE50 30% on Print: SSEE30
Wouldn't code released be a better measuring stick?
There are a lot of a Swift GitHub projects.
http://www.h4labs.com/dev/ios/swift.html?q=github.com&age=10...
http://www.h4labs.com/dev/ios/swift.html?q=github.com&age=10...
RedMonk publishes a language index which charts a language's GitHub and Stack Overflow ranking. Swift has risen quickly in the rankings: https://redmonk.com/sogrady/2016/02/19/language-rankings-1-1...
For that to happen, they need to have the compiler target more than just OS X, iOS and GNU/Linux.
There are some porting efforts underway in the early stages of development.
SwiftAndroid: https://github.com/SwiftAndroid
Swift for Cygwin: https://github.com/tinysun212/swift-cygwin-bin
SwiftAndroid: https://github.com/SwiftAndroid
Swift for Cygwin: https://github.com/tinysun212/swift-cygwin-bin
I am curious to see if Microsoft is going to support it in their iOS bridge for Windows.
I see Swift more as a way to bring FP concepts to the masses via the desire to target iOS/AppStore.
Personally I am already sold to other ML influenced languages.
I see Swift more as a way to bring FP concepts to the masses via the desire to target iOS/AppStore.
Personally I am already sold to other ML influenced languages.
I hope so since the goal of the iOS bridge is to get as many iOS applications on Windows as possible. Maybe after (or in conjunction with) Swift 3.0.
Don't see it on their roadmap: https://github.com/Microsoft/WinObjC/wiki/Roadmap
But there's an open issue for it so that's promising: https://github.com/Microsoft/WinObjC/issues/25
Don't see it on their roadmap: https://github.com/Microsoft/WinObjC/wiki/Roadmap
But there's an open issue for it so that's promising: https://github.com/Microsoft/WinObjC/issues/25
And it sounds like FreeBSD support is on the way: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-2016...
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.
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.
Big things missing from Swift IMO:
- Higher-kinded types
- Strictly-typed "throw"
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.
- Higher-kinded types
- Strictly-typed "throw"
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.
Would you have an example for someone who doesn’t know anything about higher-kinded types?
Both Optional and Array have flatMap, i.e.
T?.flatMap(T -> R?) -> R?
[T].flatMap(T -> [R]) -> [R]
protocol FlatMappable
{
typealias Value
func flatMap<R>(Value -> Self<where Value == R>) -> Self<where Value == R>
}
Swift protocols are begging for HKTs.
Link was down for me here is the google cached version http://webcache.googleusercontent.com/search?q=cache:B3qA4jq...
What's the alternative? I actually thought databases were the cutting edge. Or maybe I've been out of the loop.
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.
http://www.h4labs.com/dev/ios/swift.html
I'd like to add more features but I don't want to reinvent everything. Anyway, Go and App Engine handle the load well and so far it has been free.
http://www.h4labs.com/dev/ios/swift.html
I'd like to add more features but I don't want to reinvent everything. Anyway, Go and App Engine handle the load well and so far it has been free.
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.
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.
Django runs on app engine, so a blog no problem. WordPress is a one click install I believe ( on a VM). Oh and app engine https://github.com/GoogleCloudPlatform/appengine-wordpress-p...
I think you meant to reply to bigdubs
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.
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.
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.
Meta Commentary: that people are still serving blogs out of a database boggles my mind (as I write this the blog is down because of database issues).
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.
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.
A static compiled blog system like Jekyll, or a simple caching system in-front of the blog.
What's the alternative? The blog (according to the HTML source) is pretty stock WordPress, which is database-backed.
Use a cache plugin or migrate to a static site (works really well for blogs).
Just a regular github.io page, or if you wanna be a bit more fancy https://hugotunius.se/2016/01/10/the-one-cent-blog.html.
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