Hacker News Reader

Comment by seivan | Hacker News Reader

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.

View on HN

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?

What do you mean by Rails Omakase? All I could find is a blog post by DHH saying that "Rails is Omakase." Is there more to it than that?

https://news.ycombinator.com/item?id=4973383

I've seen the blog post, I was just wondering if there was more to it than that.

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 .

Others have given you good links behind the idea; I wrote a blog post about one of the ecosystem effects a while back: http://words.steveklabnik.com/rails-has-two-default-stacks

Sure, here https://gist.github.com/seivan/6b6bb19c899dd46f599e

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") :)

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.

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.

Reply on news.ycombinator.com