7 ms·

I want to add my POV here because I've been working with Rails for 6 years and recently changed jobs and moved to Python and Node.JS (and been working with Gola

I want to add my POV here because I've been working with Rails for 6 years and recently changed jobs and moved to Python and Node.JS (and been working with Golang for the last 3 years). One thing I would like to say is that the development experience with Ruby/Rails is by far the best out of all of these languages. By FAR. The way you can start a project in a second is amazing, the TDD experience and Rspec integration with Rails is simply mind blowing comparing to anything else. Express might be 100% faster than Rails but it will take you 5 days just to get something running vs what you can do with Rails in a matter of minutes. From Authentication to Authorization and all the community around these. Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't. Most of the slowness you are experiencing in Rails and Ruby apps is by doing poor engineering, not by Rails or Ruby itself. Big Surprise... If you query 1000 rows and bind them to the controller things will be slow. There are things that are natively slower, JSON parsing and marshaling for example is one. It's much slower than Go for example but it's so much easier and for 99% of us, this is what matters. I don't get the hate that Ruby and Rails are getting. Really don't.

avitzurel 9y ago
I said it before in my streams many times [1] This is a classic case of weighing solutions against other solutions. When you do that the one with the most features or the fastest will always seem the best. But, you need to weigh the solutions against your problem. Your problem is time-to-market. Your problem is development time. Your problem is software reliability. Your problem is finding great engineers to do great work. When that's your problem. Ruby and Rails are great solutions. Not good. Great solutions. Show me an express app that is as monolithic as some Rails apps and I will show you how Node.js halts to a crawl. [1] https://twitch.tv/kensodev https://twitch.tv/kensodev EDIT: Typo
- avitzurel 9y ago
  Yes. It's easier to find people with Javascript experience to work on your Node.JS app. But are they as good as the engineer doing Ruby for 6 years? Are they as good as someone doing Python for the last 10 years? I am not going to try and answer these, it will be idiotic but all of these articles and some of the thrust behind leaving Ruby and these articles are just driven by the wrong reasons.
  - weberc2 9y ago
    I'm really interested in the answers to those questions, because I have experience working in Python and JS shops and I haven't noticed much of a difference in terms of engineering quality between the groups. I suspect it's because most JS and Python engineers lack experience working with "non-magical" languages, and thus they frequently lack the ability to make good performance estimates or balance competing priorities. Or maybe the non-magical thing is a red herring, and it just happens that non-magical languages tend to be employed in domains where "just make it work; we'll solve performance with hardware" isn't acceptable. This isn't to hate on Python or JS engineers; just that I don't see the same jump from JS to Python/Ruby that I see in dynamic to static languages (esp static langs with manual memory management).
  - tracker1 9y ago
    That's a fair question... I've been building web based applications for over two decades now... I've been a fan of JS since before the "Good Parts" book, though that spelled out a lot of what I already knew. There are a LOT of developers that use and know a little about JS. However, the vast majority of "JavaScript Developers" don't know JavaScript all that well. Most haven't taken time to learn the newer features and/or syntax. Many try to write JavaScript like it's Jave or C#, or whatever else instead of using it for its' strengths. Not to mention performance implications. Most of the time a lot of that doesn't matter. Most apps have enough performance to handle their load, and if they can scale to 4-5x the users with minimal relative extra cost, it never will. But when you do need those extra bits, it helps a lot. I've worked on a few node/c# apps where each ms counts... getting an extra 10k requests/second on a large server, or reducing latency by 10ms is a win. Not all things are equal. One should evaluate each use case. To each their own... I only dabbled in RoR and wasn't much into it. Ruby seems like a great next gen Perl imho, and I thought that was cool. I just didn't like the everything in the box RoR experience. I lived through the early ASP.Net and didn't want a repeat of that. I like the lego blocks approach that Node and .Net Core are taking. I try to avoid many of the bigger pieces/sets.
zokier 9y ago
> I don't get the hate that Ruby and Rails are getting. Really don't. Is RoR really getting much hate? Because I sure haven't seen that. Admittedly I usually don't really pay that much attention to random framework flaming, so I might not be the best to judge, but I feel like at least on HN RoR is still discussed in mostly positive tone. Besides "everyone" already knows that RoR is dog-slow (relatively), which I think balances the discussion to reasonable level.
- avitzurel 9y ago
  What I see is a big shift. few years back, lots of the companies I knew and worked with had a Rails based product. Most of the companies I talk to today, don't choose Ruby. They mostly go with JS (Either express or Meteor or others). The "Hate" for me is articles like this. Don't know if "Hate " is the right word.
  - zokier 9y ago
    Yeah, the crowds have moved on from Rails/RoR. But the crowd is also always moving with latest fad, almost by definition. That does not imply any sort of hate in my view.
    - LyndsySimon 9y ago
      I don't even know if this is a bad thing - engaged developers want to work with what's new and exciting, especially early in their careers. Using a "fresh" stack is a means of targeting those devs and wooing them to your company. I also believe there is a very viable long-term strategy of choosing a few of the current "hotness" stacks over your early career and learning them thoroughly. When the time comes that you're not wanting to chase the new thing so much and you start to experience age-related discrimination, you can focus on maintaining and improving existing projects written in those "old" stacks. There are lots of people out there today making good money doing "unsexy" work like maintaining Java/JSP or ASP Classic apps. In ten or twenty years, those jobs will be maintaining Rails, Django, and Laravel apps.
intininit 9y ago
It's a bit silly to compare Express to Rails, Express is the Sinatra of JS, and the Sinatra philosophy is to be minimalist and give you more power, whereas the Rails philosophy is to be everything you need assuming you have typical requirements. It's a trade-off, neither is inherently better or worse, they're each good for certain situations.
- avitzurel 9y ago
  Maybe I wasn't clear enough. I am not comparing Express to Rails feature to feature (which if you read my other comments you understand I am against). Anyway, welcome to HN! It is great that as your first comment you say someone else's comment is silly.
  - intininit 9y ago
    I'm sorry. I didn't mean to come off snippy and I must have read your comment wrong. It's been a long day.
thekevan 9y ago
You talked about how great Rails is but you also switched to Python. Why the switch?
- avitzurel 9y ago
  New workplace is a python shop. All of our microservices are written in python and gateway to services are written in Node.JS.
  - deleted 9y ago
    [deleted]
flavio81 9y ago
> Express might be 100% faster than Rails but it will take you 5 days just to get something running vs what you can do with Rails in a matter of minutes. You should compare Express to Sinatra, not to Rails. Express is ridiculously easy to learn, btw. Coming from Flask (under Python), i learnt Express in 3 hours. Seriously. > Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't. Speed DOES (caps, emphasis) matters for many projects, in particular the projects that will go to real-life, to get massive use by consumers/common people. However, I do agree that for prototyping, startups, or simple apps that don't demand lots of performance, the speed of development under Ruby and its tools is a very important asset. > I don't get the hate that Ruby and Rails are getting. Really don't. Agree with you, one shouldn't "hate" Ruby, no reason, really.
- avitzurel 9y ago
  The express <> Rails comparison was not meant to be a feature to feature one. I did not explain myself correctly. The point on the speed for me wasn't that speed as a whole doesn't matter. Speed in the language level doesn't matter. If you do stupid shit with rails it will take 5.1 seconds and if you do stupid shit with Golang it will take 5.05 seconds. It simply doesn't matter all that much in the language/framework level for most of us. For example: In my current job place we are using Flask for all microservices. One of the endpoints was very slow to respond and took 3 seconds. It ended up being a missing index in the DB. Once fixed it's taking 20ms. So, Is python slow because it's taking 20ms vs 12ms?
  - flavio81 9y ago
    > If you do stupid shit with rails it will take 5.1 seconds and if you do stupid shit with Golang it will take 5.05 seconds. Honestly, if you do the same stupid shit with Go, it will take 0.51 seconds, according to many benchmarks out there. > So, Is python slow because it's taking 20ms vs 12ms? No, bad code is bad code. But on companies that have good programmers, sometimes you do hit a performance problem caused by the platform, and then you have to either a. throw more money (more servers, more CPU cores, more mem), or b. rewrite that section in other language. Actually, for example this is what some Python libraries do, for example Numpy has a lot of code actually implemented in C, not python.
drspacemonkey 9y ago
>Big Surprise... If you query 1000 rows and bind them to the controller things will be slow. Every time I've been involved in a situation where people complained about Rails being slow, this was the problem. It's not the ORM's fault if you're pulling every row from a table and iterating over them to find the record you want. It's not the framework's fault if you're pulling every row from a table to calculate the average value of a column. And it's not the language's fault if you're pulling every model entry into memory and chopping the array by hand to power pagination. Rails doesn't save you from having to know SQL. No ORM can do that. The best an ORM can do is save you from having to actually write SQL most of the time.
LyndsySimon 9y ago
In chronological order of professional web experience, I used PHP for 3 three years, Python for 6 years, and am about a year into Ruby. I've got tons of time in other languages and areas as well, but that's less relevant to this discussion. > One thing I would like to say is that the development experience with Ruby/Rails is by far the best out of all of these languages. By FAR. So far I find Rails very sane and well-thought-out, but I really, really dislike Ruby. I realize that's a personal preference issue, but it is what it is. > The way you can start a project in a second is amazing This seems pretty ubiquitous to me with "batteries included" frameworks. Rails doesn't have a huge leg up here over, say, CodeIgniter circa 2009. > the TDD experience and Rspec integration with Rails is simply mind blowing comparing to anything else. I very much like Rspec. One of Ruby's greatest strengths is the ability to define simple and semantically meaningful DSLs. Rspec is a great example of a good DSL. > Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't. I agree 100%. Python is my preference, and not because it's lightning fast. It's fast enough that I'm almost never trying to improve performance, and when I am, my project has progressed to the point that it makes sense to scale horizontally instead of trying to make it fit into existing resource constraints. > I don't get the hate that Ruby and Rails are getting. Really don't. For me, it's because Ruby is just hard to grok. You have an object that's acting funny? Where is it defined? Here... here... here... some over here... Which one of those have been executed, and in what order? That sort of thing makes me want to pull my hair out.
- malyk 9y ago
  > For me, it's because Ruby is just hard to grok. You have an object that's acting funny? Where is it defined? Here... here... here... some over here... Which one of those have been executed, and in what order? That sort of thing makes me want to pull my hair out. I hear this almost every time Ruby is discussed, but I've been building rails apps pretty much exclusively since 2007 and I've only once experienced this problem and it was due to someone trying to make the most generic thing possible to solve a relatively simple problem incorrectly. Can you point to a specific example? Is it in Ruby libraries? Is it in the application code you are working on? In Rails?
apeacox 9y ago
After 18 years of programming in a wide range of languages (almost 10 spent on Ruby/Rails) I surely agree that Ruby is a joy to use for many tasks. A different opinion goes to Rails: it's speed of development is inversely proportionate to the time taken to reach a messy codebase if you follow the infamous rails way. You need some decent design pattern to get something that is still usable after 6-12months of active development. Performances and speed can be important for many aspects, especially when there are alternatives that offer same speed of development consuming 10% of the resources needed by a ruby/rails app. Can you put a non trivial web app written in rails on a 512mb ram/1 core VPS for production (serving responses in microseconds, and consuming only a total of 50-60mb of ram)? That's what I did with 2 apps written in Elixir/Phoenix. The speed of development was the same (if not better!) than Ruby/Rails, the apps are running on cheap instances and can be scaled if needed. The hate toward rails: it's getting more crappy on each release. Several new additions (especially in the v5.x) are pretty wrong (eg: global shared variables). Yes, it's still a choice, but it has lost the real game-changing that was few years ago.

avitzurel 9y ago

I said it before in my streams many times [1] This is a classic case of weighing solutions against other solutions. When you do that the one with the most features or the fastest will always seem the best. But, you need to weigh the solutions against your problem. Your problem is time-to-market. Your problem is development time. Your problem is software reliability. Your problem is finding great engineers to do great work. When that's your problem. Ruby and Rails are great solutions. Not good. Great solutions. Show me an express app that is as monolithic as some Rails apps and I will show you how Node.js halts to a crawl. [1] https://twitch.tv/kensodev https://twitch.tv/kensodev EDIT: Typo

avitzurel 9y ago
Yes. It's easier to find people with Javascript experience to work on your Node.JS app. But are they as good as the engineer doing Ruby for 6 years? Are they as good as someone doing Python for the last 10 years? I am not going to try and answer these, it will be idiotic but all of these articles and some of the thrust behind leaving Ruby and these articles are just driven by the wrong reasons.
- weberc2 9y ago
  I'm really interested in the answers to those questions, because I have experience working in Python and JS shops and I haven't noticed much of a difference in terms of engineering quality between the groups. I suspect it's because most JS and Python engineers lack experience working with "non-magical" languages, and thus they frequently lack the ability to make good performance estimates or balance competing priorities. Or maybe the non-magical thing is a red herring, and it just happens that non-magical languages tend to be employed in domains where "just make it work; we'll solve performance with hardware" isn't acceptable. This isn't to hate on Python or JS engineers; just that I don't see the same jump from JS to Python/Ruby that I see in dynamic to static languages (esp static langs with manual memory management).
- tracker1 9y ago
  That's a fair question... I've been building web based applications for over two decades now... I've been a fan of JS since before the "Good Parts" book, though that spelled out a lot of what I already knew. There are a LOT of developers that use and know a little about JS. However, the vast majority of "JavaScript Developers" don't know JavaScript all that well. Most haven't taken time to learn the newer features and/or syntax. Many try to write JavaScript like it's Jave or C#, or whatever else instead of using it for its' strengths. Not to mention performance implications. Most of the time a lot of that doesn't matter. Most apps have enough performance to handle their load, and if they can scale to 4-5x the users with minimal relative extra cost, it never will. But when you do need those extra bits, it helps a lot. I've worked on a few node/c# apps where each ms counts... getting an extra 10k requests/second on a large server, or reducing latency by 10ms is a win. Not all things are equal. One should evaluate each use case. To each their own... I only dabbled in RoR and wasn't much into it. Ruby seems like a great next gen Perl imho, and I thought that was cool. I just didn't like the everything in the box RoR experience. I lived through the early ASP.Net and didn't want a repeat of that. I like the lego blocks approach that Node and .Net Core are taking. I try to avoid many of the bigger pieces/sets.

zokier 9y ago

> I don't get the hate that Ruby and Rails are getting. Really don't. Is RoR really getting much hate? Because I sure haven't seen that. Admittedly I usually don't really pay that much attention to random framework flaming, so I might not be the best to judge, but I feel like at least on HN RoR is still discussed in mostly positive tone. Besides "everyone" already knows that RoR is dog-slow (relatively), which I think balances the discussion to reasonable level.

avitzurel 9y ago
What I see is a big shift. few years back, lots of the companies I knew and worked with had a Rails based product. Most of the companies I talk to today, don't choose Ruby. They mostly go with JS (Either express or Meteor or others). The "Hate" for me is articles like this. Don't know if "Hate " is the right word.
- zokier 9y ago
  Yeah, the crowds have moved on from Rails/RoR. But the crowd is also always moving with latest fad, almost by definition. That does not imply any sort of hate in my view.
  - LyndsySimon 9y ago
    I don't even know if this is a bad thing - engaged developers want to work with what's new and exciting, especially early in their careers. Using a "fresh" stack is a means of targeting those devs and wooing them to your company. I also believe there is a very viable long-term strategy of choosing a few of the current "hotness" stacks over your early career and learning them thoroughly. When the time comes that you're not wanting to chase the new thing so much and you start to experience age-related discrimination, you can focus on maintaining and improving existing projects written in those "old" stacks. There are lots of people out there today making good money doing "unsexy" work like maintaining Java/JSP or ASP Classic apps. In ten or twenty years, those jobs will be maintaining Rails, Django, and Laravel apps.

intininit 9y ago

It's a bit silly to compare Express to Rails, Express is the Sinatra of JS, and the Sinatra philosophy is to be minimalist and give you more power, whereas the Rails philosophy is to be everything you need assuming you have typical requirements. It's a trade-off, neither is inherently better or worse, they're each good for certain situations.

avitzurel 9y ago
Maybe I wasn't clear enough. I am not comparing Express to Rails feature to feature (which if you read my other comments you understand I am against). Anyway, welcome to HN! It is great that as your first comment you say someone else's comment is silly.
- intininit 9y ago
  I'm sorry. I didn't mean to come off snippy and I must have read your comment wrong. It's been a long day.

thekevan 9y ago

You talked about how great Rails is but you also switched to Python. Why the switch?

avitzurel 9y ago
New workplace is a python shop. All of our microservices are written in python and gateway to services are written in Node.JS.
- deleted 9y ago
  [deleted]

flavio81 9y ago

> Express might be 100% faster than Rails but it will take you 5 days just to get something running vs what you can do with Rails in a matter of minutes. You should compare Express to Sinatra, not to Rails. Express is ridiculously easy to learn, btw. Coming from Flask (under Python), i learnt Express in 3 hours. Seriously. > Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't. Speed DOES (caps, emphasis) matters for many projects, in particular the projects that will go to real-life, to get massive use by consumers/common people. However, I do agree that for prototyping, startups, or simple apps that don't demand lots of performance, the speed of development under Ruby and its tools is a very important asset. > I don't get the hate that Ruby and Rails are getting. Really don't. Agree with you, one shouldn't "hate" Ruby, no reason, really.

avitzurel 9y ago
The express <> Rails comparison was not meant to be a feature to feature one. I did not explain myself correctly. The point on the speed for me wasn't that speed as a whole doesn't matter. Speed in the language level doesn't matter. If you do stupid shit with rails it will take 5.1 seconds and if you do stupid shit with Golang it will take 5.05 seconds. It simply doesn't matter all that much in the language/framework level for most of us. For example: In my current job place we are using Flask for all microservices. One of the endpoints was very slow to respond and took 3 seconds. It ended up being a missing index in the DB. Once fixed it's taking 20ms. So, Is python slow because it's taking 20ms vs 12ms?
- flavio81 9y ago
  > If you do stupid shit with rails it will take 5.1 seconds and if you do stupid shit with Golang it will take 5.05 seconds. Honestly, if you do the same stupid shit with Go, it will take 0.51 seconds, according to many benchmarks out there. > So, Is python slow because it's taking 20ms vs 12ms? No, bad code is bad code. But on companies that have good programmers, sometimes you do hit a performance problem caused by the platform, and then you have to either a. throw more money (more servers, more CPU cores, more mem), or b. rewrite that section in other language. Actually, for example this is what some Python libraries do, for example Numpy has a lot of code actually implemented in C, not python.

drspacemonkey 9y ago

>Big Surprise... If you query 1000 rows and bind them to the controller things will be slow. Every time I've been involved in a situation where people complained about Rails being slow, this was the problem. It's not the ORM's fault if you're pulling every row from a table and iterating over them to find the record you want. It's not the framework's fault if you're pulling every row from a table to calculate the average value of a column. And it's not the language's fault if you're pulling every model entry into memory and chopping the array by hand to power pagination. Rails doesn't save you from having to know SQL. No ORM can do that. The best an ORM can do is save you from having to actually write SQL most of the time.

LyndsySimon 9y ago

In chronological order of professional web experience, I used PHP for 3 three years, Python for 6 years, and am about a year into Ruby. I've got tons of time in other languages and areas as well, but that's less relevant to this discussion. > One thing I would like to say is that the development experience with Ruby/Rails is by far the best out of all of these languages. By FAR. So far I find Rails very sane and well-thought-out, but I really, really dislike Ruby. I realize that's a personal preference issue, but it is what it is. > The way you can start a project in a second is amazing This seems pretty ubiquitous to me with "batteries included" frameworks. Rails doesn't have a huge leg up here over, say, CodeIgniter circa 2009. > the TDD experience and Rspec integration with Rails is simply mind blowing comparing to anything else. I very much like Rspec. One of Ruby's greatest strengths is the ability to define simple and semantically meaningful DSLs. Rspec is a great example of a good DSL. > Regarding the fast/slow it's simply bull-crarp, seriously. It DOES NOT matter for 99% of us. It simply doesn't. I agree 100%. Python is my preference, and not because it's lightning fast. It's fast enough that I'm almost never trying to improve performance, and when I am, my project has progressed to the point that it makes sense to scale horizontally instead of trying to make it fit into existing resource constraints. > I don't get the hate that Ruby and Rails are getting. Really don't. For me, it's because Ruby is just hard to grok. You have an object that's acting funny? Where is it defined? Here... here... here... some over here... Which one of those have been executed, and in what order? That sort of thing makes me want to pull my hair out.

malyk 9y ago
> For me, it's because Ruby is just hard to grok. You have an object that's acting funny? Where is it defined? Here... here... here... some over here... Which one of those have been executed, and in what order? That sort of thing makes me want to pull my hair out. I hear this almost every time Ruby is discussed, but I've been building rails apps pretty much exclusively since 2007 and I've only once experienced this problem and it was due to someone trying to make the most generic thing possible to solve a relatively simple problem incorrectly. Can you point to a specific example? Is it in Ruby libraries? Is it in the application code you are working on? In Rails?

apeacox 9y ago

After 18 years of programming in a wide range of languages (almost 10 spent on Ruby/Rails) I surely agree that Ruby is a joy to use for many tasks. A different opinion goes to Rails: it's speed of development is inversely proportionate to the time taken to reach a messy codebase if you follow the infamous rails way. You need some decent design pattern to get something that is still usable after 6-12months of active development. Performances and speed can be important for many aspects, especially when there are alternatives that offer same speed of development consuming 10% of the resources needed by a ruby/rails app. Can you put a non trivial web app written in rails on a 512mb ram/1 core VPS for production (serving responses in microseconds, and consuming only a total of 50-60mb of ram)? That's what I did with 2 apps written in Elixir/Phoenix. The speed of development was the same (if not better!) than Ruby/Rails, the apps are running on cheap instances and can be scaled if needed. The hate toward rails: it's getting more crappy on each release. Several new additions (especially in the v5.x) are pretty wrong (eg: global shared variables). Yes, it's still a choice, but it has lost the real game-changing that was few years ago.