The problem of "ping" Ruby real in our time?

Greetings friends ! Very briefly describe the problem :
My colleague and I decided to write a game server in Ruby on Rails, is now working as it learned of more experienced colleagues and did not approve, citing some reasons :
1) RoR is slow, services, brake
2) Not intended for high-loaded projects
3) RoR don't write a game server because of the slowness, there is a high latency and so forth ...
And advised us to : Python+Django or Node.js !
But I kinda got used to the RoR, and Python I do not know (node.js tembolee) and don't know what to do and how to act ?
Is it true that now when the terms are SSD, lots of RAM and multi-core boilers, there is a performance problem ? Or is it the old myth about the Ruby and now it's not important ? Or should I switch to Python !
Help colleagues ...
July 12th 19 at 22:02

Related questions

More answers about "The problem of "ping" Ruby real in our time?"
8 answers
July 12th 19 at 22:04
Solution
For example, the logic of a game server can be implemented as micro-services in a more lightweight frameworks than Rails: Sinatra, Hanami and so on. The easiest option is to use JSON as the format for input/output data.
Or by using MessagePack (has gem), you can exchange with various micro services that can be implemented in other languages.

In the case of using MessagePack (or analogues) and microservices can always later go to solutions in other languages, if necessary due to bottlenecks in performance.
July 12th 19 at 22:06
listen to these colleagues, and start writing in python.
then listen to other colleagues, and go to nodejs.
then listen to other colleagues, and go to java.
then listen to other colleagues, and go to C.
then listen to other colleagues, and go to go.
then listen to other colleagues, and go to erlang
then listen to other colleagues, and browse to the assembler.
But what about machine code?
Quickly... - keven81 commented on July 12th 19 at 22:09
July 12th 19 at 22:08
1) RoR is slow, services, brake
No, the same order of performance with similar solutions (compare with frameworks in PHP and Python).

2) Not intended for high-loaded projects
The highload is a problem of architecture, not language.

3) RoR don't write a game server because of the slowness, there is a high latency and so forth ...
All right.
However, I hope you mean the Ruby (the language), not RoR (the framework).
Look in the direction of Java, if you want to solve such problems.

And advised us to : Python+Django
Performance Django on the level of RoR.

or Node.js !
It is impossible to compare with RoR, this is the solution for different tasks.
"The highload is a problem of architecture, not language. "Very well said. - keven81 commented on July 12th 19 at 22:11
July 12th 19 at 22:10
If you have something hard-coded RTOs, all intepretive, especially without JIT, drop and write the bottlenecks in C/C++/Go. Step-by-step and you can write on anything.
July 12th 19 at 22:12
What kind of game will be?
If you do some simple browser game with no harsh streams of data synchronizations provisions and other realtime - then surely you can at least bash to write (if time nowhere to go of course).
July 12th 19 at 22:14
Always choose language according to the decreasing priority:
a) requirements for TK (and it happens, but it is better to persuade)
b) the one most familiar (if you prefer)
C) the one you like more

Because it's likely if you are well versed in Ruby, it would take less time, and pitfalls will be less.
No, Ruby is not slow, he's just not as popular. And Yes, if you want something new and bright look at Erlang
July 12th 19 at 22:16
Pfft, I know someone who works on the project RoR'e with an audience of > 100 million users (game on Facebook). So what about the bad scalability and slow RoR'a - blatant bullshit. Yes, ruby, the reputation of the language of startups, but it doesn't make it high-load projects. Just the approaches are different.
And you can link to the game? - keven81 commented on July 12th 19 at 22:19
July 12th 19 at 22:18
Game servers are different and requirements to the performance is also different.
If you have no experience of building similar projects - make the first prototype in the language you know better. With this experience you will understand where to focus attention in the final product, as a result, whether to change the language, too.

Find more questions by tags Web DevelopmentPythonNode.jsRubyRuby on Rails