Really? At my company it seems like 90% of the tests are catching things that would be caught automatically if we had used a proper language with strong types/compiler.
IMO Ruby is slow, not particularly beautiful (yes, this is subjective), and seems optimized for shoving crappy REST endpoints out the door as quickly as possible.
It sounds like the tests are testing the wrong thing
> seems optimized for shoving crappy REST endpoints out the door as quickly as possible
Ruby is a general purpose language. Perhaps it is Rails that you have gripes with?
I'd also like to hear what you are doing that leads you to the conclusion that 'ruby is slow'. For most domains I would say ruby is fast enough to solve the problem in a way that customers are perfectly happy with.
I would argue 90% of the software businesses I've seen are simply CRUD REST endpoints. If that means you can get those out the door as quickly as possible, why on earth would you want to use anything else?
It's almost like you're actually advocating for it...
And if those bugs would be prohibited by static typing, then it sounds like Ruby is creating work.
> if we are passing a string instead of an array of strings somewhere, the test will fail
Is this an example of a real bug? It's mind boggling that anyone would use a language that allows them to type that bug into existence without an immediate error.
I know we used to be forced to use JS, but not we even have TS so that we don't have to catch extremely machine-catchable errors in tests or, worse, production.
Ruby's fun to write but I hope never to onboard to a Rails codebase again. I think the vast majority of the ones in the wild are... not great, to put it mildly.
I feel like in my career, across many different languages and platforms, "legacy" codebases (ie, any codebase that pre-dates me and is a non-trivial amount of code) are uniformly "not great to put it mildly".
1) The amount of "magic" available and how much it's used—in low-magic scripting languages or frameworks, you can at least grep to find definitions, even if better code navigation tools aren't available. The more often the answer the "wtf is this?" can't be known for-sure until runtime, the harder it is to find your way around, and the more memorization you have to do. Rails and its ecosystem are very high-magic, even more so than something like the roughly-comparable Django. It can be annoying to even figure out which gem defines a given symbol, in a given context.
2) The level of reliance on tests to keep things from falling completely apart. Tests are generally good things, of course, regardless of language, but a poorly-maintained test suite in a Rails codebase is a far more grave problem than it would be in, say, a Go or Typescript codebase (yes, it's mainly the static typing that makes the difference). That is, keeping the codebase viable requires more active attention and work.
This is exacerbated by Rails being a common choice for bootstrapping startups (the library ecosystem, especially Devise, which might be single-handedly the main reason Rails wins as many "what should we use?" discussions as it still does, is a pretty damn strong argument in its favor) and bootstrapping startups having a tendency to go through multiple teams in short order (contractors and external dev teams being common, both in the early days and in the somewhat-later, very common, "oh god the cut-rate shop we got to build this fucked it up, please save us" phase) means that a whole lot of live Rails codebases have been treated very poorly, and that, for the above reasons, a Rails codebase that's been treated very poorly is a special kind of hell.
It's not just the framework, but the fact that have proper tests, architecture, and CI/CD.
If I'm in a situation where I need to throw up a rest server as soon as possible, I'm probably using NodeJS. It's dirty but it works ( except when you have the wrong Babel compiler installed and lose 3 days of your life trying to fix it)
Also, it seems like a very small team behind the language. Is longevity an issue?
Your questions point out the obvious shortcomings of Crystal currently. While it is easy to find libraries, they are few and their support is questionable. Not to do anything with the language itself or the ability of community, just the nature of a new and small ecosystem.
The team is small but I take solace in the fact that they have been at this for a very long time now (2011).
Once nicety that helps the ecosystem is the easy of interoperability with C-libraries. Many shards are simple wrappers around an already established C library.
I haven't looked at other languages seriously - at the moment Elixir and Crystal seem to be the most interesting to me