>>106999222
Ruby’s a beautiful language and Rails a great framework. Personally I use Django, but Rails is a great choice if you like it

>>106999222
if you dont know enough to answer this yourself then it probably makes no difference for your use case. Just do it.

>>106999222
I use ruby as my main language at work for the last 4 years. Some very critical stuff for one of the largest tech companies in the world runs on it. It's comfy, but I wouldn't recommend it or any other dynamically typed language for basically anything.

>>107001519
Forgot to add, we've lost millions of dollars over the years due to people making typos or forgetting to import or include something

>>107001532
Come to think of it we may have lost that much this year alone due to these and other ruby language issues

>>107001519
critical -> we'll lose money if our site goes down
mission critical -> people die, electricity goes out, jet crashes, etc.

Ruby isn't used for mission critical stuff, it's used for websites.

>>107001532
>Forgot to add, we've lost millions of dollars over the years due to people making typos or forgetting to import or include something
Don't you have tests and a CI/CD pipeline? Those issues should get caught.

Thank god these trannies are getting replaced by AI

>>107001714
All it takes for this to happen is to have a method that makes a call to a method provided by a 3rd party package. In your unit test, you mock the call, so it's never actually exercised. And you likely won't have integration tests that cover every single line of code, so things slip through. Not to mention this software touches physical devices, which for practical reasons may not be available or in the right state to cause every code path to be exercised, so it becomes extremely impractical to exercise every possible end to end code path. Think of interacting with satellites in space from a Rails API, your business logic containing the bad method call may be error handling logic that wouldn't normally run if the satellite is in a healthy state. The more external dependencies you have, the harder it's going to be to set them all up/simulate them in various failure states to ensure your app logic behaves correctly in every single circumstance. In a perfect world you might do that, but in the real world businesses make tradeoffs between test coverage/quality and spending that development effort on feature work instead. If you just used a compiled language instead, that simply eliminates several failure modes - things like methods that were removed during Rails or gem version upgrades.