5 ms·

There is also sinatra, which has had a stable API for years.

sparaker 12y ago
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.
ad_hominem 12y ago
Not really: https://twitter.com/maccaw/status/576437511729221632 https://twitter.com/maccaw/status/576437511729221632 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.
- grandalf 12y ago
  uh, it appears that a chance to Rack's API caused that bug, no?
  - beat 12y ago
    Same problem, though. Ruby's dynamic typing comes with some wonderful advantages (yay metaprogramming!) but some pretty bad disadvantages as well.
    - grandalf 12y ago
      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.
- pjonesdotca 12y ago
  Actually a good testing suite fixes that issue. It's probably the most bogus "issue" strong type addicts bring up.
  - jallmann 12y ago
    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.
    - erokar 12y ago
      You might want to watch this talk for some data on this subject: https://vimeo.com/74354480 https://vimeo.com/74354480 "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."
      - counterplex 12y ago
        The politest put down ever?
      - ssmoot 12y ago
        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. But that's just my opinion man.
paulbjensen 12y ago
Let's not forget Grape either: https://github.com/intridea/grape https://github.com/intridea/grape 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-node-and-the-web-apps-of-today 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.
beat 12y ago
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.
- grandalf 12y ago
  > Grape does a lot of things that turn into wasteful boilerplate in Sinatra 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.

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.

ad_hominem 12y ago

Not really: https://twitter.com/maccaw/status/576437511729221632 https://twitter.com/maccaw/status/576437511729221632 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.

grandalf 12y ago
uh, it appears that a chance to Rack's API caused that bug, no?
- beat 12y ago
  Same problem, though. Ruby's dynamic typing comes with some wonderful advantages (yay metaprogramming!) but some pretty bad disadvantages as well.
  - grandalf 12y ago
    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.
pjonesdotca 12y ago
Actually a good testing suite fixes that issue. It's probably the most bogus "issue" strong type addicts bring up.
- jallmann 12y ago
  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.
  - erokar 12y ago
    You might want to watch this talk for some data on this subject: https://vimeo.com/74354480 https://vimeo.com/74354480 "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."
    - counterplex 12y ago
      The politest put down ever?
    - ssmoot 12y ago
      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. But that's just my opinion man.

paulbjensen 12y ago

Let's not forget Grape either: https://github.com/intridea/grape https://github.com/intridea/grape 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-node-and-the-web-apps-of-today 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.

beat 12y ago

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.

grandalf 12y ago
> Grape does a lot of things that turn into wasteful boilerplate in Sinatra 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.