> Today with Spring Boot, for instance, you can bootstrap and develop your app as quickly and easily as any other cool and alternative framework but with the advantage of using a really popular and fast language.
Looking at the Spring Boot guides, the amount of setup, complexity and lines of code just to get an application running with MySQL doesn't support this statement: https://spring.io/guides/gs/accessing-data-mysql/
Even 20 years ago this would be easier in Rails.
Or try building the blog demo that's build on the Rails homepage video in Spring Boot.
35 minutes to build a blog with rich text (including image uploads), live comments, notification mails and tests. And after changing the database to PostgreSQL, deploy it to production.
https://rubyonrails.org/
The 15% is for the total request time including waiting for blocked IO.
> All that work allowed us to speedup our storefront total web request time by 10% on average, which is including all the time the web server is blocked on IO, for example, waiting for data from the DB, which YJIT obviously can't make any faster.
For 3.2 there also was an improvement of the interpreter:
> We now speed up railsbench by about 38% over the interpreter, but this is on top of the Ruby 3.2 interpreter, which is already faster than the interpreter from Ruby 3.1. According to the numbers gathered by Takashi, the cumulative improvement makes YJIT 57% faster than the Ruby 3.1.3 interpreter.
Nobody cares about performance if you build a business application with a couple of users, a common use-case in 2005. The reason a lot of Java people jumped on the Rails bandwagon, was that an application that would take a month to build in Java with Spring/Hibernate, would take a day in Rails.
See also: https://www.oreilly.com/library/view/beyond-java/0596100949/
Some Java people did, there is a reason why Ruby is hardly used outside Rails, while Java rules most of the backend workloads, a mobile OS, and plenty of embedded workloads.
There's also a reason Kotlin has become the language of choice for the Android development industry, Scala became a thing, and ThoughtWorks recommended against using JavaServerFaces.
Because Android team had some Kotlin shills that pushed for it with management blessing, and they are in bed with JetBrains for the Android IDE, that is why, and even them had to accept updating Java support, otherwise Android/Kotlin would lose the ecosystem of Java written libraries, hence Java 11 LTS last year, and Java 17 LTS this year going, back to Android 12 with APEX archives.
Scala became a thing indeed, where it is now besides Spark?
ThoughWorks is a consultancy that recomends whatever brings new projects.
