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.
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 .
