I think it's only in comparision to php, python etc.
I haven't seen any benchmarks or analysis that say JIT is ready for production use, but indications are strong that the next version of Ruby will include a lot of surprising things, like maybe a type system?
Ruby got a reputation for being slow very early on, and my understanding is a lot of that was due to slow code in Rails (version 2 and/or 3?). Rails is a lot better now. Ruby continues to evolve. Still, I don't know how many Ruby developers have chosen it for reasons owing to CPU-intensive work. This does seem like a stretch, even if we are beating Python in some benchmarks.
Conceptual compression means that you can unpack those ideas and work with them when you need them, or pack them back up and don't pay attention to them when you don't need them.
The biggest example that I can think of is ActiveRecord. I can't tell you the number of times I've seen presentations by programmers who work with other frameworks like .NET, who have embedded large, complex SQL queries into their code. They don't think twice about it, don't even flinch, parsing SQL is part of the cost of doing business in this language.
Having said that, it makes me a bit sad that there are quite a few developers who actively avoid SQL. Granted the syntax is absolutely awful, but it is a very useful and powerful language. The concepts behind relational databases are embraced by SQL in ways that I can't imagine in any other language (I'm sure there must be other good relational query languages somewhere, but I've never been exposed to them). Honestly, if I have developers working with a relational DB doing anything even a little bit complex I want them to not not think twice or even flinch to use or read it (and I say that not really being all that accomplished with the language myself).
Rails has some good niches where it is very well suited. ActiveRecord is OK if you have a very particular data model. However, as they say, if a hammer is your only tool, every problem starts to look like a nail. You may find that if you approach the problem differently, you will find reasons why people choose not to use very simplified ORMs.
What ActiveRecord isn't is discoverable. Which is to an extent understandable. Its domain is literally anything you could express in SQL. But you really can do anything you want with it, you just have to find the right abstraction. A tool I use a lot is to .to_sql which will show you the compiled SQL fragment in a debugging session. You can compose with bare SQL fragments and ActiveRecord even includes an intermediate library so that you can work at the relational algebra level if you want.
It's not that ActiveRecord forces you to work a certain way. It just doesn't advertise all its features.
Ryan Bigg wrote a great book about breaking away from AR in Rails called Exploding Rails[3]. It's a good read.
[0] http://sequel.jeremyevans.net/
[1] https://github.com/elixir-ecto/ecto
[2] https://rom-rb.org/5.0/learn/introduction/active-record/
found [ActiveRecord] to be severely limited in
working with complex queries which use many
JOIN statement and sub-queries
I would certainly agree that SQL > AR once your queries grow past a certain (fairly low) complexity threshold.
But, AR (wisely) doesn't try to be a complete replacement for SQL. It very happily (and even elegantly, I might say?) lets you use raw SQL pretty much any time you, the developer, feel it's more convenient/productive. That principle is pretty explicitly baked into AR.
Many ORM frameworks don't make this easy at all, whereas with AR it's very painless.
I have a lot of beef with AR but I think this is one of its strong points.
My biggest issue with AR is that the arbitrary SQL cannot be combined or reused in a way which leads to compositional queries. An example would be to break up a large SQL statement into several smaller statements and then recombine them in different ways, safely.
What I found with Ecto and ROM is that, while simple to low complexity SQL was about the same as AR, maybe 10% harder to understand, complex to very complex statements were about equivalent to their SQL counterparts and could be composed together. That was a major win over AR for non-trivial queries.
You can do this, look into arel. Here's a blog post:
https://blog.codeship.com/creating-advanced-active-record-db...
As another commenter noted, yes you can do composable AR/Arel with raw SQL.... but like you said, it does get hairy pretty fast.
I've used sequel before and agree, it's closer to the SQL and does the job well. ROM looks excellent. I'm just reading down the page you linked, and I love every word. I can say I've had all of these problems with ActiveRecord, and ROM's answers to them all look great!
Granted [SQL's] syntax is absolutely awful, but
it is a very useful and powerful language. The
concepts behind relational databases are embraced
by SQL in ways that I can't imagine in any other
language (I'm sure there must be other good relational
query languages somewhere, but I've never been exposed
to them)
It's somewhat significant, I think, that when Microsoft came up with LINQ (sort of a language- and backend- agnostic query language) they basically settled on something that looks like SQL but puts the FROM clause first, mainly so the editor can give you typing hints.
I'm not saying LINQ was a rousing success, but that was a pretty major greenfield MS devtools initiative and they have some pretty smart language/compiler people, so it's interesting that they settled on something not too different from good ol' SQL.
Computing power can be increased by scaling vertically or horizontally. Vertical scaling has an upper limit, and when one reaches it, in certain contexts, end of the happiness :-)
Case in point: GitLab; they have Go microservices. GitHub was also hiring Go developers, so very likely they've done the same.
Of course, few companies are GitLab/GitHub, but the point is that it's not possible to make absolute statements about power being cheap.
By being able to run your service on a single server instead of ten allows your team to focus on features instead of scaling your application using background concurrency, caching, or “micro-services”.
Imagine what you could do when you don’t need to manage a fleet of web-servers.
You make it sound like an unconfirmed rumour? It's there in the release.
That's an unusual result - if it's faster for an actual app you're using in production you should report that as they'll be thrilled.
Each visitor hits a Ruby process which renders the page directly, or serves it up from filesystem cache. I'm not honestly sure which, it could be monitoring the filesystem for changes to the markdown files, and only recompiling them when it observes a change on disk... or it could be rendering each request freshly for the visitor.
It would be hard-pressed to call this a production deployment though, I can say without a blog post or any hard data to back it up that when I did side-by-side trials, the page loading response times were marginally faster with the JIT enabled, after repeated trials.
After watching @tenderlove's talk from RailsConf 2019, I think I'm obligated to say also about this that, your results will improve if you paid attention to cache hit ratios, and consider tuning the JIT Cache size to achieve the maximum benefit. Perhaps these things will be better in a later iteration of Ruby JIT?
35 minutes cpu for a 200 line Ruby fannkuch-redux program
— is "jit not having enough time to kick in"?