4 ms·

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 feat

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.

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.