It seems that, outside of what's used in Cocoa, the Swift language is pretty volatile right now. I would hesitate to commit to a large project that didn't involve the App Store.
I think the hope of projects like these is partly to try to advance interest in Swift which draws in more users who then help contribute to making the language more cross-platform, and partly to be f1rst in the project's niche when the language finally crosses that barrier, so that it becomes the de facto standard. (Think Compojure for Clojure, in the same problem domain.)
My personal hope is that a lot of the long-term risk is mitigated due to IBM's partnership with Apple and alleged goals to use Swift in enterprise. Admittedly, that may not deal with the short-term risk.
Seems to me like the real challenge in those framework (excepting performance, of course) will be in the orm component. Having a library that can query a db in a typesafe way is a must.
Another will be in the concurrency patterns ( promises ? Coroutines ?, etc).
But i get a great hope that they will succeed. Having a strong open source community will help. In fact, i'm so fed up with the sad state of uikit right now, that i see a brighter future for swift on the server side than on the client. Maybe an android sdk for swift would be a great idea...
The challenge with any type safe language is interacting with the outside world -- internal consistency is easy, but figuring out how to mediate the non-typesafe outer world is always a bit of a fight. Slick is one swing at the typesafe ORM, but I'm not sure it gets it quite right.
For concurrency, I'd be very intrigued if streams were the first-class concurrency approach -- It's been interesting working with Akka Streams in Scala. They make 90% of concurrency-related things easy and 10% of things seem to be fighting leaky abstractions, but I'd be curious if they were built into the language early on as primitives whether the leaks would go away.
Swift concurrency is interesting topic for sure, looks like language isn't actually built around concurrency unlike other popular new languages these days. Interesting document here about Swift concurrency https://github.com/apple/swift/blob/master/docs/proposals/Co...
The project banner depicting a damsel in distress on the railway tracks is going to make some people twitch. I'd avoid that distraction by picking something gender neutral. My 2c.
Parent comment is just trying to be helpful, and people are down voting it. The comment points to a legitimate concern so ... like all advice, take it or leave it, but I think it would be gracious to say thanks rather than pile on.
Also you really can't legally use the image of a performer without their permission, if you care abut such things.
You could have made it better by using protocols for the actions. So the methods for adding routes would ensure that the methods for new and update exists using a where clause checking protocol conformance.
There is potential here, I like a "full" package like "Omakase", granted its built using Swifts strength and a pipeline model like Express.js and/or Rails and its rack middlewares.
Seivan, thanks. Yes, Rails "Omakase" is driving Swifton development.
I'm not sure that protocols will help here, because Swifton supports before/after filter. Could you explain more your idea about how protocols could help here to implement actions with filters?
I am mainly a hobbyist/newbie that recently started to learn Ruby, and Ruby on Rails. While I like them both, I would prefer to just work in Swift.
How soon does HN expect a Swift-based framework that is comparable to the maturity of Rails, or other powerful frameworks for that matter? Do you think Apple might jump in and introduce one of their own?
[+] [-] autoreleasepool|10 years ago|reply
[+] [-] sdegutis|10 years ago|reply
[+] [-] PakG1|10 years ago|reply
[+] [-] bsaul|10 years ago|reply
Another will be in the concurrency patterns ( promises ? Coroutines ?, etc).
But i get a great hope that they will succeed. Having a strong open source community will help. In fact, i'm so fed up with the sad state of uikit right now, that i see a brighter future for swift on the server side than on the client. Maybe an android sdk for swift would be a great idea...
[+] [-] jowiar|10 years ago|reply
For concurrency, I'd be very intrigued if streams were the first-class concurrency approach -- It's been interesting working with Akka Streams in Scala. They make 90% of concurrency-related things easy and 10% of things seem to be fighting leaky abstractions, but I'd be curious if they were built into the language early on as primitives whether the leaks would go away.
[+] [-] necolt|10 years ago|reply
[+] [-] seivan|10 years ago|reply
[+] [-] kawsper|10 years ago|reply
They seem to have adoption in some bigger companies, but I don't know if any of them are using the Swift version yet.
[+] [-] JamoneK|10 years ago|reply
[+] [-] protomyth|10 years ago|reply
[+] [-] supster|10 years ago|reply
[deleted]
[+] [-] hagmonk|10 years ago|reply
[+] [-] PKop|10 years ago|reply
Stop wasting people's time, let them focus on productive aspects of the project.
[+] [-] mrits|10 years ago|reply
[+] [-] henryw|10 years ago|reply
[+] [-] whiddershins|10 years ago|reply
Also you really can't legally use the image of a performer without their permission, if you care abut such things.
[+] [-] staticelf|10 years ago|reply
[+] [-] jakobegger|10 years ago|reply
Good software stands on its own, and doesn't need corny jokes like this.
[+] [-] mastazi|10 years ago|reply
[deleted]
[+] [-] moneypenny|10 years ago|reply
[deleted]
[+] [-] seivan|10 years ago|reply
There is potential here, I like a "full" package like "Omakase", granted its built using Swifts strength and a pipeline model like Express.js and/or Rails and its rack middlewares.
[+] [-] necolt|10 years ago|reply
I'm not sure that protocols will help here, because Swifton supports before/after filter. Could you explain more your idea about how protocols could help here to implement actions with filters?
[+] [-] Razengan|10 years ago|reply
How soon does HN expect a Swift-based framework that is comparable to the maturity of Rails, or other powerful frameworks for that matter? Do you think Apple might jump in and introduce one of their own?
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] herbst|10 years ago|reply
[+] [-] coldcode|10 years ago|reply
[+] [-] fleshweasel|10 years ago|reply
[+] [-] aroman|10 years ago|reply
Node's tight coupling to JavaScript seems like more of an exception than a rule — look at Java, Ruby, Python, etc.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] yeskia|10 years ago|reply
[+] [-] Pxtl|10 years ago|reply
[+] [-] vortico|10 years ago|reply
[+] [-] supster|10 years ago|reply
[+] [-] steveklabnik|10 years ago|reply
[+] [-] harunurhan|10 years ago|reply
[+] [-] supster|10 years ago|reply
[+] [-] jernfrost|10 years ago|reply
[+] [-] muhmi|10 years ago|reply