On the other hand, running into Java or C# projects is hardly ever an issue; it's a lot of boiler plate (many (request/response/dto etc) models/entities and layers), but it's readable immediately and if it still runs, it means that all data is validated and I can trust it.
On the JVM its novelty will fade out while Java adopts whatever features might be relevant to the millions of Java developers out there, just like it happened with all other that came before.
And I remember the days back when Groovy was supposed to be the scripting language for JEE, and Spring was going full speed with it as Java alternative, and we even got strongly typed variant.
The impact on maintainability is about what you'd expect. Maybe, on an abstract level, the software isn't as complex as what you can do in Ruby, but the verbosity of the language brings its own maintenance challenges. I can't speak to Ruby specifically, but, in practice, I haven't found that I'm all that much more afraid to change things in a large Python codebase than a large Java one.
I'm now coming to think that the real challenge is dynamicism in general, regardless of whether it's built into the language or implemented as a library solution. So, if Java has an advantage here, it's simply that it tends to discourage people from overdoing it by making it awkward to do.
Sure, but if you don't reach market fast enough you'll have no reason to slog through anything, period. Can you imagine writing something like Facebook using Rust? It's an almost ludicrous proposition.
Static typing requires that you know what you're building at a relatively fine-grained level--how the pieces will fit together at the source code level, at least roughly. No amount of automated refactoring could ever match the flexibility of dynamic typing when you're just trying to bang out features, let alone explore the feature space, which almost by definition is what any novel solution is doing--exploring. That's why I love using embedded scripting, particularly Lua. You can gradually move components outside the dynamic environment as their place in the architecture becomes fixed and well understood.[1] So-called gradual typing doesn't really permit the same kind of flexibility because it's not the static typing, per se, that burdens development, but rather that static typing has the effect of forcing a more rigid hierarchy of higher-order abstractions and interface boundaries. What you want is the ability to slowly solidify the architecture from the outside to the inside, not the inside to the outside.
Microservices is another way to address the problem, at least in theory, but in practice doesn't actually directly resolve the real dilemmas. At best it just multiplies the number of environments in which you're faced with the problem, which can both help and hurt.
[1] Statically typed scripting languages seem rather pointless to me, and more a reflection of a fleeting fascination with REPL.
Building some or all of those backend APIs in Rust from day 1 would not be crazy, or less productive than any other language.
I think differences in proficiency drive bigger differences in productivity than inherent language differences.
So if you were starting today to build Facebook, using a language you are already effective with would matter more than which language you use (there are plenty of people out there for whom that could be Rust, or Haskell, or Ruby, or PHP, etc).
Rust lets me make sure my code still works through refactors and code changes. With PHP I could easily break something that would only cause an error when that code actually runs. That's right, there is no sanity check at all until the parser reads that code.
I was involved in developing large PHP and Rubby codebases and its so hard to maintain.
These days I just use SpringBoot. It strikes a good balance between providing speed to market (PHP/Ruby), maintainability and performance (the next version should support GraalVM). Cant complaint so far.
