Rails has bigger community and they are pioneers for alot of things that each new framework takes inspiration from. Practically i think ruby wasn't going to be this famous without rails. So its cool that Sinatra had it early on, but now we have it in rails.
If you want true stability you probably have to switch to a language with a stronger type system. That Sinatra bug proves that even small codebases can suffer from basic type errors.
Definitely. I like things like contracts and optional type annotations very much. Some code is just hard to understand without those kinds of things, which leads to bugs.
The only thing better than having tests is not needing tests. That's what a robust type system gives you.
Type systems don't eliminate all testing, but they do eliminate a large swath of possible errors that need to be tested for, like the one that has (had?) been afflicting Sinatra.
"Some programming language theorists would have us believe that the one true path to working systems lies in powerful and expressive type systems which allow us to encode rich constraints into programs at the time they are created. If these academic computer scientists would get out more, they would soon discover an increasing incidence of software developed in languages such a Python, Ruby and Clojure which use dynamic, albeit strong, type systems. They would probably be surprised to find that much of this software—in spite of their well-founded type-theoretic hubris—actually works, and is indeed reliable out of all proportion to their expectations."
As someone who worked with Ruby since ~1.8.1, has written a ridiculous amount of OSS Ruby and now works mostly in Scala, this is the exact opposite of my experience.
YMMV, but I've never seen the Ruby project that didn't suffer from stupid bugs even the most basic type system would have caught.
One of the biggest advantage of type-systems for me is that they don't suffer from No True Scotsman. If you don't have a test that covered this bug, people are happy to tell you you're doing it wrong. The type-system doesn't have that problem. It doesn't "rot". It expresses only what you tell it to. It enforces maintenance and rigor in a way that tests, as non-integral code, fundamentally can't.
I can't watch because no subtitles, but man that intro is condescending. Not saying that academics are completely innocent either, but maybe if the description focused more on the substance of the data, it wouldn't seem like the smugness was a cover-up for trying to rationalize their choice of language.
Anyway, I'm no PL theorist, only a schlub that's a better programmer because of ML. Yeah yeah, sample size of one...
I'm not a programming language theorist or in any sort of functional-programming-static-type-system ivory tower – I just want to catch more bugs prior to runtime without needing to write tedious mechanical tests of method contracts. I find good type checking insanely refreshing. I find that I need fewer tests, they are easier to write, and they test more essential attributes of the program.
I've written lots of useful stuff in Python and Ruby, but I've also sunk lots of time into tests that I would have preferred not to need to write.
Some poo-pooed the notion, but you can clearly see that the popularity of realtime frameworks and the way that apps are built client-side heavy is pulling Rails in this direction.
Performance is still the key factor here, and I suspect that's half the reason why you've got some people who espoused Ruby in the past now playing with other languages beginning with Ru, but that have a much less friendly syntax compared to Ruby.
Some welcome changes though nonetheless, especially on the WebSockets front.
I've recently switched from Sinatra to Grape for pure REST microservice development. Grape does a lot of things that turn into wasteful boilerplate in Sinatra. Haven't gotten far enough with it to find the downsides yet.
I've down API dev in Rails too, but it really feels like killing a fly with a hammer sometimes. And as I shift strongly to microservices (thanks Docker!), I want my API code to be as minimalist as possible. Grape/Sequel feels simple, which is good.
This gem was created because this feature was going to be in Rails a few years back, but was pulled out by DHH before release. But, as you can see, he's cool with it now.
IMHO this is nice code, nothing against the devs, but I just don't see why its getting added. As someone who has built lots of rails apis, I don't really see any benefit other than perhaps speeding up bootstrapping. But as is, right now its incredibly easy in rails to require the action-X packages you want and setup middleware how you like it. Maybe I'm missing something though...
This is good, DHH basically is talking about making rails (in the future version 5ish) more flexible for all those people building just backend rails apis that are consumed by seperate client frontends, mentions integrating websockets too. So it sounds like this is the first step in that direction.
I don't think you're missing anything, but I think you (as many have before) are forgetting about one of Rails earliest and biggest selling points: curation of best practices for creating specific kinds of applications. While the ease with which skilled practitioners can configure the framework to work well for an API-driven application is a testament to its flexibility, the out-of-the-box conventions have been in need of some love for awhile.
I don't think this is a huge deal, but it will definitely be nice to have official support for this configuration.
Probably https://rails-assets.org/, you add it as a source in your Gemfile and then add gems based on the scheme "gem 'rails-assets-BOWER_PACKAGE_NAME'"
I recommend just using webpack or browserify... the workflow supports super fast on-the-fly bundling. Most reasonably large Rails apps end up embedding v8 anyway.
I love this. I find that Rails-API sometimes does/needs some screwy stuff because it has to be 2nd class citizen. This promotion of it is great news because it will obviously be kept in sync way better.
Regardless, SPAs are fast becoming the best way to develop and this sort of thing (rather than the bandaid of turbolinks) gives me a lot of hope for the future of rails. I can even see rails eventually replacing views with a presenter layer (though something like that would probably wait for 6).
Reminds me of what someone once said about America: "they always do the right thing, after exhausting all other possibilities".
39 comments
[ 2.7 ms ] story [ 98.8 ms ] threadIf you want true stability you probably have to switch to a language with a stronger type system. That Sinatra bug proves that even small codebases can suffer from basic type errors.
Type systems don't eliminate all testing, but they do eliminate a large swath of possible errors that need to be tested for, like the one that has (had?) been afflicting Sinatra.
"Some programming language theorists would have us believe that the one true path to working systems lies in powerful and expressive type systems which allow us to encode rich constraints into programs at the time they are created. If these academic computer scientists would get out more, they would soon discover an increasing incidence of software developed in languages such a Python, Ruby and Clojure which use dynamic, albeit strong, type systems. They would probably be surprised to find that much of this software—in spite of their well-founded type-theoretic hubris—actually works, and is indeed reliable out of all proportion to their expectations."
YMMV, but I've never seen the Ruby project that didn't suffer from stupid bugs even the most basic type system would have caught.
One of the biggest advantage of type-systems for me is that they don't suffer from No True Scotsman. If you don't have a test that covered this bug, people are happy to tell you you're doing it wrong. The type-system doesn't have that problem. It doesn't "rot". It expresses only what you tell it to. It enforces maintenance and rigor in a way that tests, as non-integral code, fundamentally can't.
But that's just my opinion man.
Anyway, I'm no PL theorist, only a schlub that's a better programmer because of ML. Yeah yeah, sample size of one...
I've written lots of useful stuff in Python and Ruby, but I've also sunk lots of time into tests that I would have preferred not to need to write.
You could see this move towards JSON APIs way back in 2012 as I suggested here: http://paulbjensen.co.uk/posts/2012/07/11/thoughts-on-rails-....
Some poo-pooed the notion, but you can clearly see that the popularity of realtime frameworks and the way that apps are built client-side heavy is pulling Rails in this direction.
Performance is still the key factor here, and I suspect that's half the reason why you've got some people who espoused Ruby in the past now playing with other languages beginning with Ru, but that have a much less friendly syntax compared to Ruby.
Some welcome changes though nonetheless, especially on the WebSockets front.
I've down API dev in Rails too, but it really feels like killing a fly with a hammer sometimes. And as I shift strongly to microservices (thanks Docker!), I want my API code to be as minimalist as possible. Grape/Sequel feels simple, which is good.
Would love to see a few examples
> I've down API dev in Rails too, but it really feels like killing a fly with a hammer sometimes
More like creating a few extra layers of abstraction to confuse the fly.
This gem was created because this feature was going to be in Rails a few years back, but was pulled out by DHH before release. But, as you can see, he's cool with it now.
EDIT: sorry, I mis-read your post. This is just "Why Rails and not Sinatra," not "this is easy enough to do on its own, why bother."
I wasn't directly involved in the decision, so I cant' tell you, to be honest.
https://thechangelog.com/145/
I don't think this is a huge deal, but it will definitely be nice to have official support for this configuration.
Regardless, SPAs are fast becoming the best way to develop and this sort of thing (rather than the bandaid of turbolinks) gives me a lot of hope for the future of rails. I can even see rails eventually replacing views with a presenter layer (though something like that would probably wait for 6).
Reminds me of what someone once said about America: "they always do the right thing, after exhausting all other possibilities".