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...
Not everything else, Rust, OCalm just to name a few. Maybe it's just recent hype of such languages, but it definitely fits very well in some situations.
Last month, about 60% of our iOS users already used Swift, and the gap in favor of Swift is growing very quickly (it was 50/50 in November 2015). Some of our Swift users you’d probably expect: apps from Vimeo, Digg, Hipmunk or Misfit wearables. But in the past 1-2 months we’ve seen Swift + Realm apps from some real large companies like Cisco, the NFL, NBC Universal, GoDaddy and 7-Eleven. I hope this helps!
I'd love to use realm, but for now i'm still hesitating. One reason is that you're using your own custom storage engine, and building a reliable one is hard. You should release some jespen-like testbench to prove how robust your technology is.
I definitely agree that custom storage engines can be scary! In a way you could say the fact we’re used happily by so many applications on literally hundreds of millions of devices is a test of our reliability, although it’s far from being a formal test of course. We field the overwhelming majority of our issues in public on GitHub and StackOverflow, so you can see the kind of issues we have there. We have a bunch of internal testing on top of that of course, including our own device testing, test suites, and fuzz testing. We’re always up for recommendations on testbench for the kind of storage we do (Jepsen concerns itself only with distributed failure scenarios iirc, which doesn’t apply to us since we’re an embedded/centralized database engine by necessity). I don’t know if this helps or not, but I’m always happy to chat if there’s anything more you’d like to know about
Maybe you could make videos and talks about your testing procedures. That would probably help build trust.
nb : you're not distributed, but you're enabling multi-threaded access, in an environment where your app can be killed anytime by the OS. That's quite hostile as well :)
I never used this framework, but everything i know from the next era is starting to show its age (including coredata, with its messed up support for multi threading access).
The more i think about it, the more i think golang approach is the right one : the only hard part today is concurrency. As long as swift ( and rust for that matter) hasn't standardized patterns that people would use on the whole stack for concurrent access to ressources,as well as asynchronicity, they won't have made the necessary step to truely advance the state of the art.
Rust exists in a domain where one-size-fits-all approaches to concurrency just don't work and where asynchronicity is usually irrelevant. Meanwhile Rust's type system manages to statically prevent data races without requiring Erlang-style deep copying, which is an advance to the state of the art. :)
> I never used this framework, but everything i know from the next era is starting to show its age (including coredata, with its messed up support for multi threading access).
EOF is not Core Data and Core Data is not from the NeXT era.
GCD is the best I've seen in terms of language design for concurrency. It's also a bit higher level than managing threads on your own. Though I might be wrong.
You probably should have a try at golang concurency management with channels, and you'll see what i mean.
GCD isn't much more than a low level job launching and scheduling library. It doesn't provide advanced patterns for resource sharing.
Concurrency goes further than parallelism, it's also a way to manage concurrent memory access (although golang does let you shoot yourself in the foot if you want to with low level mutexes as well). There's a great talk from rob pike on the subject http://blog.golang.org/concurrency-is-not-parallelism
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.
I'm not offended in the slightest. Except by your misuse of the apostrophe. I agree that nobody was hurt in "it is making." Note that this is my idea of fun, and you don't have to be offended by it.
The purpose of my comment was to point out that gender charged images are going to draw attention in the tech industry, and that is worth avoiding. I made no commentary that suggested the image was not fun, or was offensive. You made those extrapolations all by yourself. Someone out there will make a very similar mistake to yours, by extrapolating a nonexistent gender message in the logo of this project.
That's where the real time wasting starts. My advice to the project maintainer is to skip all that bullshit by picking something neutral. I genuinely wish this was not the kind of stuff we have to worry about, but I have at least one friend whose industry reputation was needlessly tarnished by people who didn't see the same joke he did.
The only time wasted is the complaining about a photo that is obvious to the intended audience. You are specifically nitpicking gender for no justifiable reason.
Please explain: how is it fun exactly? Do you enjoy the image of a bound woman about to be hit by a train? Does your girlfriend / wife / mother find this image "fun"?
It is a reference to Taylor Swift combined with Ruby on Rails. That sort of makes sense. I assume they wanted to combine rails and Taylor swift somehow and this seems like on easy way of doing it.
I reacted a bit like you, but given that this only makes sense with Taylor Swift, I figured okay, whatever no need to moralize over this one.
Haha! I just googled her, and that picture makes sense now. Yes I'm an adult male from Texas, but I'd never heard of her before. Hell I just had someone explain to me who Beyoncé is at a Christmas party a couple months ago.
I appear to live under a rock. But anyway, clever joke. I like it.
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 might fork and do my own version where I try to adhere to Swifts strengths while still staying close to Rails API where I can, e.g same naming scheme and pipeline design as Rails.
Rails biggest weakness is Ruby. Leveraging Swifts strengths with protocol extension, where clauses and generics could actually improve on Rails current API.
Edit[0]:
Added an idea for filter API. Not happy with it, but it's a start.
Before/After filters could just be a list of "stuff" (selectors, closures, etc) to be called before any action.
It could also use group_dispatch to ensure that filters are called in sequence and only call the method once all filters are done.
group_dispatch (think semaphores, but not as "dangerous") :)
Rails biggest weakness is Ruby?!?! The only reason Rails came about (so says DHH) is because of Ruby and its expressiveness as a dynamic language.
Granted, we're in Swift mode here and it's static typing, protocols, generics, and closures all the way. I'm fine with this (I write in Swift everyday) but Ruby is a great language as well - I love them both.
I think there's a place for both static and dynamic typed languages and I'm not going to throw away Ruby just because Swift is more "correct" with typing.
Having worked on my own Swift web framework for the past few months, and Rails for years, we're not even close to approaching Rails feature set. Rails has been in active development for over a decade and it's going to take a while for a Swift framework to make some inroads.
We're both right. Rails look the way it looks because of Ruby. What I am advocating is a compromise between the two of them. Rails-esque packaging, and API design on the entire stack e.g Active Record to Active Support.
But using Swift strengths with protocol conformance, extensions, associated-types and etc.
I would never want to work on a larger Ruby code base again. It's just too hard to iterate on as things break too much compared to a larger Swift code base. That's just my take.
I actually like Ruby, but for scripts and smaller code. Not large applications. Same applies for ES6, where I think TypeScript would do a better job.
Seivan, thanks for your gist. I also tried to make controllers more protocol oriented, but it didn't help much with nice DSL for filters. Let's keep trying, maybe something beautiful will born soon. I would love to see you Swifton fork with your experiments.
I think Ruby is both strength and weakness of Rails. From my 10 years experience with large scale and large codebase Rails projects I can say that Ruby dynamism helps in web development. But for sure it comes with really high price tag.
I believe DHH first started to use "Omakase" term in Rails context, so his blog post and discussions afterwards is good place to check. You can alse check original Omakase https://en.wikipedia.org/wiki/Omakase .
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?
