Ruby 3.3(ruby-lang.org) |
YJIT is an amazing technology, and together with other innovations like object shapes and various GC optimizations, Ruby is becoming seriously fast! Big Ruby shops such as Shopify [1] have been running 3.3 pre-release with YJIT and reporting double digit percentage performance improvements.
Personally I'm really excited about Ruby and its future. I can't wait to start working with Ruby 3.3 and using it on my client's production sites...
[1] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...
Edit: add percentage to performance improvements.
The recent irony of the web is anyone that implemented a web app with "slow" ruby and backend rendering now has the fastest page loads compared to bloated front-end web apps backed by actually slow eventually consistent databases that take seconds to load even the tiniest bits of information. I see the spinner GIF far too often while doing menial things on the "modern" web.
For reference:
$ units -1v '1|2 billion reqs/month / 14 servers' 'req/sec/server'
1|2 billion reqs/month / 14 servers = 13.580899 req/sec/server
What database is on the backend, and is that db serving cached content? What happens if you cache it with e.g. redis to avoid the heavyweight rails ORM stuff?
Do you have granular benchmarks for the db query, requests to other services, and the web processing itself (using artificially pre-cached responses from db and those other services)?
You’re likely in one of two situations as a businesss:
* You’re a struggling startup. Development velocity trumps literally everything. Your server costs are trivial, just turn them up.
* You’re a successful business (maybe in part because you moved fast with Ruby), you can pay down the debt on that absurdly large response. Chunk it, paginate it, remove unnecessary attributes.
You mean like 10% faster, or 10x faster?
Edit: clicked the link; it's 10%. I don't think that's going to make any difference to the perception of Ruby's slowness given that it's on the order of 50-200x slower than "fast" languages like Rust, Java, Go and C++.
The 100x to 200x mainly comes from Rails.
One is scripting language, the other compiled, the difference is huge already there.
a nice ide integrated experience:
https://code.visualstudio.com/docs/languages/ruby#_debugging...
https://github.com/ruby/vscode-rdbg
https://code.visualstudio.com/docs/editor/debugging
heavy metaprogramming in any language is going to be a pain to debug so i'm not sure what you're expecting but there are tools to help. you can also call source_location on some method to figure out where things exist.
The link shows 13-15%.
If I’m going to give it even a second glance, I can’t be seeing “ruby 10,000% slower than Java” for measured use cases.
But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async. Especially in the context of Rails. I am wondering if any one are using these features in productions and if you could share any thoughts on the subject.
[1] https://mac.install.guide/ruby/update.html
Just curious, which version manager would you recommend? Previously I recommended asdf, frum, or chruby.
Do other language runtimes do similar things? Creating a thread sounds too heavy, though it might not matter in practice. As per their own benchmark, the overhead is minimal but still not zero.
10000.times {
Addrinfo.getaddrinfo("www.ruby-
lang.org", 80) }
# Before patch: 2.3 sec.
# After ptach: 3.0 sec.
100.times {
URI.open("https://www.ruby-lang.org").read }
# Before patch: 3.36 sec.
# After ptach: 3.40 sec.My impression is that everything was migrated to be asynchronous by default, unlike in Python where all of these operations were reimplemented in the async "color". Is that true?
I find Ruby fascinating yet difficult.
Shouldn't the default be the number of logical cores? Like Rust's Tokio and countless other M:N runtimes
On paper it’s awkward, but in reality convention and social norms make it rarely an issue.
The global namespace only supporting exactly one version of each gem encourages a health culture of stable ABIs and deprecation periods too. An absolute dream compared to some language ecosystems
Or I'm speaking out of my ear and completely wrong (and I don't know which :D)
If anything Rails autoloading (Zeitwerk really) make it much easier to find where constants come from as it enforce a constant name -> file name convention, so all you need is fuzzy file search.
Ruby imports have always used a single global namespace. I'm not convinced that this is an issue in practice - it's worked just fine for several other languages.
It looks like a big leap, but when you compare the actual speed to _any_ other language you realize Ruby still has many, many percent to go to even be in the same game.
If you look at CPU bound micro-benchmarks like most similar announcements uses, you easily get into the 3x territory: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...
Where are you seeing 3x improvement?
Because even this graph from your article doesn’t show that, unless you’re comparing JIT vs non-JIT. But JIT has existed for awhile now (not new in 3.3).
https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...
This is entirely predictable - Ruby does not have a big scientific computing community which happened to depend on every implementation detail of the hosting interpreter.
It is quite common to see "Python" libraries that are just thin bindings layers, they could just as well be "Tcl" libraries for that matter.
Python workloads, with deep pocketed backers, do spend more time inside GPU or C runtime.
Really? What’s so significant with this release?
> But one thing that is not mentioned or discussed enough, is Ractor, M:N thread scheduler, Fibre and Async.
Yes! Ractors deserve more highlighting! It’s a huge feature.
I think the Prism parser update is a standout highlight for me. This is the start of many new static analysis tools for ruby.
It's also significant that RBS type information is starting to be used in IRB autocompletion. Previously RBS has been an interesting experiment but hasn't had much practical use compared to Sorbet.
Ruby seems to now have good answers to non-blocking IO (async fibers) and tooling questions (ruby-lsp). We're starting to see YJIT performance improvements starting to compound with more to come too.
That all seems significant to me. Thanks to everyone involved.
By the way, celery was born as a protocol spec to support multiple languages but never moved past Python. I can't google a quote for that, I remember I saw it years ago in the documentation somewhere.
External systems come with a cost, especially if it's more than a library.
Not sure I can recommend it, but Gearman does fit the bill. There’s client and worker libraries for a dozen languages, including Python3 and Ruby.
A Ruby implementation would probably not be hard.
I don't how much people use this in serious or high performance work but it might be an option.
If you’re fluent in Node and Python it should be quite easy to learn. The downside is it’s not going to do anything fundamentally new for you coming from those languages. The upside is mostly aesthetic, Ruby offers and encourages really beautiful ways of expressing code, and it’s neat to experience that.
Add to this also Shopify, Github, Gitlab, Basecamp and some others and you will see that Ruby can be use for more than shell scripting and data munging. Yes they are Rails but Rails is written in Ruby so they are Ruby.
Ruby is also very fun, probably the most fun language I’ve used regularly. That makes it its own reward.
The most interesting part IMO is how it's so similar to Python along many categories, but also so different.
Biggest example is how Ruby just loves Blocks. They're all over the place in the std lib, tons of syntax sugar for them, and countless DSLs built around them. All the standard functional stuff is there in the std lib and has been from very early on, so doing functional-style stuff is really smooth and reads well. In Python, you can technically do most of the same stuff, but it all seems a lot more awkward to write and to read (though maybe just my opinion from doing Ruby first). Python has lambdas, but it doesn't seem to like them much for more than trivial things. But instead functions are first-class everywhere.
This introduction about a framework built with ruby and not ruby itself was necessary because even today, I would guess that 95% of all development with ruby is RoR applications. It's my understanding that ruby rose to prominence mostly because of ruby on rails, now that RoR is in a downward trend I think ruby will follow the same trend until it's reduced to a small community of enthusiasts in the same way that happened to perl.
As for the language itself I can't think of a single reason to opt for ruby over python or typescript. Ruby doesn't do anything better both in terms of language or platform than its already better established competitors.
I'll bite.
Even at the most basic level of built in functions/methods (String, Array, Hash) - I found Ruby's to blow Python's out of the water.
https://ruby-doc.org/core-2.5.1/String.html
https://www.w3schools.com/python/python_ref_string.asp
Even Python's choice of naming and syntax to use these basic functions just hasn't been thought through as much as Ruby's implementation. There's a reason it's called the language of Developer happiness.
Ruby's community I've found is more focused on best engineering practices (like testing) than others, which is perhaps why RSpec and MiniTest are fantastic frameworks. The likes of PyTest doesn't even compare to what those two offer.
Plenty of reason above to use Ruby, and we haven't even got to Rails yet.
And there is a lot more: new conferences, new books and new gems.
(Shameless plug: I curate a newsletter called Short Ruby that covers news from Ruby world every week).
Maybe Ruby is not at the level where is was in 2007-2009 but it is also NOT in a downward trend.
It's really sad if that's the case. What's replacing it (mostly JS/TS everywhere, relying on PaaS) really isn't as fun.
For me, coming from more of a Ruby background, I found Python and Node to not be too hard to understand, and my only nitpick would be on how eggs/packages were managed and dealing with dependancies.
In particular, Python dependancies compared to Ruby dependancies were more challenging initially for me. I’ve grown to appreciate Python indents and find it nice to read, but that was also annoying at first.
Ruby itself is not the issue. The way people and frameworks (looking at you Rails) abuse its mechanics in pursuit of “clean code” drives me crazy. An incredible number of things are downright challenging to debug because of the insane flexibility of Ruby.
I wouldn't use NodeJS to build web-app that fits Rails. NodeJS ecosystem feels like building on a house of cards though.
Python feels alot cleaner, but I wouldn't pick it over Node for web UI automation or Rest API testing.
This is paginated (page size of 1000) and the caller chooses only the attribute they need already, thanks.
Even successful companies care whether they need to run 1000 servers or one for something.
I think that shim still uses ruby 2.6, I may try to upgrade it to 3.3 with yjit and see what the latency drop is, which is probably a more interesting number anyways, but again only really matters for a single caching request that only happens once in a while.
The real reason I continue to use ruby is because it's a quick way to get things done on business logic heavy web apps, but I continue to be impressed how much I can get away with using it for things it's really not known for being good at. I run into people often that refuse to use it for absolutely anything because there's a perception that it's "too slow", but when pressed I learn that they're not really working on anything that requires high performance provided by more esoteric languages with stricter memory management that is very likely nerfing their productivity unnecessarily. My goal here was to push back on that perception a bit, not to make the dns shim sound impressive.
But something to keep in mind. I’ve seen servers before that could serve in the 100,000 QPS range on a single instance! They weren’t written in Ruby.
We do allow the occasional use of “send” but try to avoid it. Dynamic method definitions are strictly banned.
But my point is that the YJIT team never really communicate numbers from synthetic benchmarks, it's very focused on real world workloads.
Synthetic benchmarks are used internally, but mostly to optimize a specific pattern that was identified as a common hotspot.
All this to say this figure you quote is not to be directly compared to many similar announcements from other projects or benchmark suites.
Now if you still think it's not good enough, I encourage you to try your hand at it to see how much of an accomplishment that really is.
Then add in something like Pry or Irb, where you are able to build castles in your sandbox.
Most of my data exploration happens in Pry.
A final book I’ll toss out is Data Science at the Command Line, in particular the first 40 or so pages. They highlight the amount of tooling that exists that’s just python shell scripts posing as bins. (Ruby of course has every bit of the same potential.) I had always been aware of this, but I found the way it was presented to be very inspirational, and largely transformed how I work with data.
A good practical example I use regularly is: I have a project set up that keeps connection strings for ten or so SQL Server DBs that I regularly interact with. I have constants defined to expedite connections. The [Sequel library](https://sequel.jeremyevans.net/) is absolutely delightful to use. I have a `bin/console` file that sets up a pry session hooking up the default environment and tools I like to work with. Now it’s very easy to find tables with certain names, schemas, containing certain data, certain sprocs, mass update definitions across our entire system.
``` # Something failed, and not everything loaded as you expected # explore explore explore…
db::CompetitorPricing.tables
db::CompetitorPricing.tables.grep(/^pricing_/)
latest = DB::CompetitorPricing.tables.grep(/^pricing_/).map {|table| [table, table.max(:create_ts)}
latest = latest.sort_by(&:last)
# serialize to csv, or json, or perhaps copy the data into excel:
Clipboard.copy latest.map{ _1.join("\t")}.join("\n") ```
Just like with work in the shell, you have a really easy time iteratively exploring the problem and building up your answer. The ability to serialize your data you’ve found, and keep your favorite tools in your pocket feels extremely productive. And of course, all of this can be written in ruby 1-liner shell scripts, or more complex shell scripts to pipe in and out of other tools if desired.
With the recent additions of the prefix/suffix methods I have no desire for any more.
https://docs.python.org/3/library/stdtypes.html#string-metho...
Meh. Been in the industry longer enough to not care about Developer happiness but more about solving problems quickly.
Your developer happiness ain't necessary mine just like some people prefer the cuteness of Ruby and other prefers the strictness/patterns of Java.
NodeJS does not attract the kind of people who build ElasticSearch, Kafka, Hadoop, Spring Framework, etc so the quality of the libraries reflected of that the Web Developers crowd: the short-term Do-ers (need it today, let's build it, and let's move on to the next interesting stuff).
But that way your sacrificing integration into your system's nsswitch which may want to do something completely different with your requests.
You could also query over dbus which can be async https://www.freedesktop.org/software/systemd/man/latest/org.... (if you can depend on systemd)
If you want more context, you can read: https://bugs.ruby-lang.org/issues/19430
If you rewrite it anyway, might as well use something else than ruby.
The db (mysql) is not the problem in the scenario I described.
You just said the company is a rails shop, why would you force a new language on everyone who already invested in understanding ruby?
I used to be a huge Ruby fan but having exposure to Python where this isn't an issue, life is just easier.
I like how Ruby's imports work - just load a file, similar to C. On the other hand, modules in Python always felt like something to overcome rather than "just works as you expect".
Oh, and not needing __init__.py files in order to import something. Goodness, what an absolute pain.
First of all, it contains a ton of custom C code, which to some extent could be extracted to a separate library in theory, but isn't. Second, a lot of that custom code interacts deeply with the Python C API, which historically was very open-ended. Even getting it to work on another implementation of Python was a challenge that took a long time to reach baseline usability.
You could forego Numpy and call out to a library like Eigen, but even then you have a huge amount of work ahead to achieve anything resembling feature parity.
I still think Rails has the best ORM design I've ever seen, iterated with practical applications. Django's ORM and migrations are, for lack of a better word, odd.
I'm a bit surprised that people here argue that no one using Rails would ever want to interface with other languages. Most big companies do. How can you not interface with python these days.
Looks to me like celery might just be the only job queue left like that. Might be worth writing a current ruby en-queuing library for it. Retracting my previous statement about ActiveJob since it would probably be too much effort to execute anything bidirectionally.
We started another project later on and we planned the database first. We wrote one model per table, no inheritance, only a few cleanly delimited apps. We still use makemigrations and migrate but if we want we can write a piece of software on any language to access that database.
I just looked at the source, I guess Mike has been mostly working on both projects on his own for the last 4 years, so Faktory has a lot of features that require the enterprise license.
I wonder if he could change the situation it he markets a bit more to the python and more specifically Django community.
a = [1,2,3,4]
for b in a
print(b)
But you would write `[1, 2, 3, 4].each { |n| print(n) }`
Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.
Also I remember Rails' ActiveRecord having some pretty egregious performance footprint (we're talking 10ms to 100ms on top of DB waiting) but I hear that was fixed a while ago.
The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead.
Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.
All these micro-benchmarks shootouts means nothing either. Is anyone running a mandelbrot or pi-digits SaaS company? I'd think not.
Similarly saying Rails is slow out of context, means nothing, Rails is "slower" than Ruby micro-frameworks X because it does useful things the other doesn't like CSRF protection etc. If you don't need these features, turn them off and Rails will be about as fast as these frameworks.
If anything annoys me more than clueless people shitting on Ruby for bad reasons it's Rubyists spreading FUD about Rails.
Some use cases with small margins call for the utmost efficiency to be viable business. Some use cases just need decent efficiency and are happy to trade some efficiency for some other properties.
Many successful people and companies are happy with Ruby, can we just give them a break? Or is there somehow some moral duty to use the "fastest" language available regardless of whether it makes any kind of business sense that nobody told me about?
For Rails I often compare to it another CRUD app, StackExchange [1] using ASP.net And the easiest real world comparison with Rails App would be Cookpad. Are we not seeing at least 10x difference if not more.
Is Rails fast enough? That depends on the context. Everyone's business model is different. It is almost definitely fast enough for most SaaS cases.
Where am I denying that? Saying that one of the most dynamic language is slower than Java or Go it's such a truism it's pointless.
What annoys me is the figures quoted. I can craft you benchmarks were Ruby is barely any slower than these two, or benchmark where it's 1000x slower. So which is the correct number to quote?
> For Rails I often compare to it another CRUD app, StackExchange [1] using ASP.net
This makes zero sense. You said:
> If you compare pure Ruby without Rails to fast language like Rust, Go and Java. It is probably closer to 10-20x.
> The 100x to 200x mainly comes from Rails.
So somehow you are blaming Rails for making Ruby 10 times slower whatever that means. That is a stupid statement that you took out of your hats and that doesn't reflect any reality. Please stop doing that, it's really unnerving for the people who maintain these projects.
My entire point was that Rails is not designed for this.
I first thought it's just a backend use-case, where processing 1000 records in a paginated result is common, but the parent mentions "rails", so it sounds like a frontend use-case.
On an average mobile connection, it’s maybe a second or so.
“Why would I pointlessly accept this clear case of massive technical debt for literally no reason what-so-ever?”
Rails does not present any sort of promise that go does not also present, so just saying “yeah, I’ll handcuff my app like this cause I feel like using Ruby” is, frankly, absurd.
When you ask the right questions, you never land on Ruby, and that’s why Ruby continues to decline.
Ruby is concise compared to Go though. I like Go and but when I use it I have to accept that I'll write (and debug) at twice as much code as I would do in Ruby.
If you're mostly just loading data into a large fast cache, lines of code may be a more critical dimension than execution speed.
That's how well designed Rails projects work and you get most of what you need straight out of the box.
Still, your lengthy explanation only confirms how much C and how little Python, that specific case happens to be.
>That is a stupid statement that you took out of your hats and that doesn't reflect any reality.
I will leave it at that.
I work at what a company that's not particularly large. Our original API is a Django monolith that serves about 1000req/s.
While you could argue Python isn't the bottleneck, Django often is. I hear the same feedback from colleagues that work in Rails. Not only do we run into issues with latency per request but we have to run a significant number of Kubernetes pods to serve this workload. With c#, golang, java or a similar language we would only require a handful of pods and drastically cut our compute costs.
Even for web workloads, these slow interpreted languages and their developer experience optimized frameworks absolutely do become a bottleneck and claiming they don't (or that you need to be at Google/Facebook scale before they do) is false.
Everything is a tradeoff but the way I think of it: speed is a feature.
You wouldn't spend so much of your time reading and writing about ruby if you didn't care about it. You'd move to things you do care about.
Ruby, and scripting languages in general, are fast enough for the jobs they get used for. When they're not they get replaced.
For every engineer insisting Ruby is fast enough in a situation where it is not, there are 1000s in environments where Ruby absolutely is more than sufficient, insisting it’s too slow.
It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends.
Anything and everything that has a web backend is a fair game for comparison.
This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).
It's not only that ruby and ruby on rails are trending down, this has been the case for at least 10 years.
https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/
This is only an article, but you will find the same point of view in many other places. The decline of ruby and RoR is obvious for anyone doing web development. Python is only getting stronger, Typescript the same, not to mention the statically typed competitors like Java with Spring Boot.
I wouldn't doubt that even languages like Go and Rust might surpass ruby soon in web development because as general purpose languages they are already more relevant.
I'm a former RoR developer and I took off the keywords ruby and ruby on rails from my curriculum because for me professionally it makes no sense to invest time in them.
So, if you decide to switch, it is only logical for you to believe that the Ruby community does not bring anything new to the table. I am not saying it as a bad thing. I decided to stay with Ruby, so of course, I am looking for clues that my decision is still reasonable.
One point about your last phrase: the market for Ruby developers - especially seniors - is active. At least in my own corner of the internet.
https://trends.google.com/trends/explore?date=all&q=Ruby%20o...
It could be my optimism, or it could be that I am biased, but I have seen at least a flat line since 2022 in that graph.
As I said, I see an increase when I look at the number of conferences, books, or gems started. That is a strong signal for me that the community is growing, or at least the community thinks it is growing.
Ruby got nothing else bigger than Rails unfortunately no matter how people in that community is hyping Ruby out.
It's okay if Ruby and Rails on a downward trend it might pick up again in the future.
C'mon now, we all know that our industry is like a Fashion industry.
The only reason why Rails is making a comeback is because we're in tough time: no more VC money to hire tons of Engineers to build a web-app.
When money was flowing, folks tend to build over-engineered solution (microservice, mesos, container, k8s, cloud-y orchestration), when money is tight, folks tend to build simple stuff because of lack of resources.
But now there is another complication to an eventual reemergence of ruby on rails: the competition defeated the initial comparative advantage - i.e. the simplicity - of the RoR platform. The premises that justified RoR in the past are too weak today in my opinion. The framework was sold on how easy and no-nosense it was setting it up and start prototyping your commercial solution in a time where the competitors were awkward and epitomized by J2EE, where setting up and developing the most basic application was time consuming and complicated.
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.
Technologies don't die quickly and COBOL and Perl are the living proof, but it's really hard to see a bright future for RoR and ruby and I think that most of their contribution was already given.
Spring Boot has been there for ages. It changes nothing really.
Spring Boot was created solely for spinning up Microservice quickly. This is a different segment than Rails.
Spring Boot was overtaken by Golang in the microservice arena in US hi-tech scene. There's just way too may Go-based infrastructure that boosted Go ascend to the Microservice arena from 2016/2017-today. My experience might be just anecdotes but I worked for multiple companies that used to be Java based shop and they all moved away from Java/Scala to Golang and build tons of microservices (whether that strategy is the right thing to pursue or not is a different discussion altogether).
Yeah, Spring Boot might eventually decided to "tack" on the UI option (thymeleaf) but it's too late. Hi-tech already jumped to the latest fashion: Go, docker, k8s, with some sprinkle of ELK and Prometheus for monitoring.
> It's really hard to see a bright future for RoR and ruby and I think that most of their contribution was already given.
They're going to sit nicely in the corner where they belong: web-app. Nothing more, nothing less.
I'd argue the one trending down is Spring, especially after they joined VMWare and now VMWare is part of Broadcom.
Take this with a lot of grain of salt from someone who was a staunch defender of Java during the Spring (DI, MVC), DropWizards, Hibernate=>JPA2 era, skipping Ruby/Rails hype. I moved on from Java to Golang in 2018-2019 and haven't looked back despite switching multiple companies. Prior to that, I was swimming in Java world with multiple companies.
Now that I'm back in the market for my own webapp (side project, fun), I'm not going to use Golang for good reason and I'm not planning to go back to the Spring world either. Rails it is for me...
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/
IMO, it is proposing another way to build web apps that goes back to the original proposal of Rails: simplicity and convention over configuration.
Rails 7 makes building modern web interfaces easy in the same way Rails 2 made building modern web pages easy.
Right I see your point, but in this case it’s about Ruby, the language itself, not RoR.
Ruby has iterators/generators. It doesn't have first-class functions because it doesn't have functions at all, but blocks/procs serve the same purposes.
Blocks are a syntactically special single argument to a method that can either be yielded to (a Ruby construct similar to a function call but which only applies to the block passed to the current method) or converted to a proc (but the latter only as part of the method definition, since they aren't first class and thus cannot be manipulated or referred to directly.)
It seems to me that Python still has these holdovers from when it was not fully object-oriented, where a lot of string and data structure manipulation is done with language-level functions rather than methods on the objects, which can be quite confusing.
Another issue I had was that Python's test frameworks like PyTest were just so weak compared to the likes of MiniTest and RSpec.
can you elaborate on what you miss here? ruby has a robust enumerable suite of methods so i'm curious what you found lacking
I'd love to hear what makes you say this - none of it is meaningfully true (ruby doesn't have functions, but it has blocks and callables).
It has:
https://en.m.wikipedia.org/wiki/First-class_function#Languag...
> The identifier of a regular "function" in Ruby (which is really a method) cannot be used as a value or passed. It must first be retrieved into a Method or Proc object to be used as first-class data. The syntax for calling such a function object differs from calling regular methods.
https://blog.appsignal.com/2018/09/04/ruby-magic-closures-in...
> Ruby doesn’t have first-class functions, but it does have closures in the form of blocks, procs and lambdas. Blocks are used for passing blocks of code to methods, and procs and lambda’s allow storing blocks of code in variables.
It is possible Ruby itself got accelerated a lot, okay, I am just not sure that's relevant since almost all Ruby usage is Rails.
[0] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...
Blocks are sort of like anonymous function literals that are not first class, one (but no more than one) of which may be attached to a function call.
A free software doesn’t have to be anything because it’s free.
On a side note, you can actually compare their performance here if you’re really curious. But take it with a grain of salt since these are synthetic benchmarks.
You're trying to make it seem like it's a wash, because "scripted" but it's not. Node.js outperforms Ruby in every department. And it's based on one of the slowest scripting languages of all time. Ruby is a dead language in many countries.
In Canada, you would have to travel the country to find a Ruby job. And if you don't think in American-centric terms, that is meaningful.
I enjoy writing Ruby a heck of a lot more than I do writing JavaScript. I like the object model. I like Ruby’s standard library. I like the Ruby community. I like the tooling: irb is fantastic. Bundler is still one of the best package managers around—makes npm and yarn look silly by comparison.
The spec sheet just does not matter for virtually any of my work. Switching to a less enjoyable, more performant, language might make a 60ms response time average become 55ms. Who cares? That performance difference was even bigger 15 years ago, and it didn’t matter then. It matters less today.
GitHub, Shopify, Airbnb, Netflix (yes! Even Netflix!), Soundcloud, Kickstarter, etc. etc. all use Ruby today. It is a fantastic development environment when you’re more concerned with doing your job, and less concerned with performance pissing contests.
We're talking about performance because of the context, which is – there aren't the jobs to support the language's continued growth and dedication. We're talking about speed because there needs to be a defining reason to continue using a language and develop in an ecosystem that isn't moving at the growth of other communities.
If Nintendo Switch had 4 games, and they all looked like dog piss - asking why would I bother wasting time with Switch is a valid opinion.
There's also this insect-minded logic of only being a "front end developer" or "back end developer", and that mindset is furthered by languages that don't bother speaking the language of the web. If I learn javascript, I can be both - pretty much on day 1. If I learn Ruby and Javascript, great. How easy is that to do for a junior developer just getting out of school? Not widely.
I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.
As for EF Core - it very good as of today (has it ever been bad?). You can transparently compose your queries with `context.FromSql(...).SingleAsync()` which will use string interpolation API to consume your plain $"SELECT * FROM {myTable} ..." and make it injection-safe and transform passed arguments as appropriate. It's quite handy.
Amazon is a huge Java shop.
Twitter used to be huge Rails app with Java/Scala services.
NGINX and Passenger are infrastructure pieces just like Memcached so I think you need to understand the context here...
[1] https://en.m.wikipedia.org/wiki/Programming_languages_used_i...
We're talking about web-app, not microservices.
We're talking about CRUD with DB migration, sessions, caching, etc.
I recalled Google's dl.google.com was implemented in C++ and Brad F rewrote it with Golang. We're not talking about microservice that serves file here. We're talking about the main web application that serves wikipedia, youtube original version (they might had revamped it sometime post acquisition with web gateway and bajillion microservices), Google Search (was Java servlet), Facebook original web-app (was PHP, became HVVM/H4CK.
So yes, I _know_ what I'm talking about in terms of the context of a web-application here. Do you?
But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion! And that is what I was trying to point out.
I did not claim that in general sense, I said it with the context that even if Ruby got accelerated a lot then that's still kind of inconsequential because most Ruby usage is Rails.
e.g. Numo for NumPy or Ruby-Polars for python polars.
So I think you’re right.
More accurate statement would be: Python is piggy-backing on hugely successful C libraries and claims big performance on their backs, IMO.
And I find that bit sad because Ruby is also good at other things like building cli apps (have a look at Metasploit for example) & gluing different moving parts together, creating your own DSL thanks to its flexible language structure.
I wouldn't say Ruby is better than any other languge though, all general purpose language could probably achieve the same result, it's just a matter of taste.
Why?
Just today I again had to do Homebrew cleanups so one recipe can install. Likely my fault, 100% sure about it, but I just need non-confusing tools in my life.
...Or I kept grooming my homemade cross-machine provisioning scripts (i.e. install baseline tools like git and a few others, and then bring my up entire environment along) and in the end it still couldn't source a script that is right there in the file system and even after I made sure it got sourced, it still couldn't find the stuff inside it... while all other 20+ such similar `source stuff.zsh` work just fine.
At one point you do get fed up. (And yes I know this is not strictly related to strong static typing; it's just one example of a thing that will reduce bug surface.)
Ruby is easy to write. And that's the problem. People tried to do too much with it. And it's early glory of including a gem that monkey-patches the core library APIs did not do it any favors either.
Nowadays I don't appreciate unbridled freedom as much. I appreciate and even enjoy constructive limitations. Truth is we can be very much like kids and should be protected from harming each other.
But yeah, that's venturing into philosophy which was not the topic.
TL;DR: Ruby is fine but is fairly limited for my taste. My needs are far bigger and they also include maximum 50ms of startup time.
I guess you touch on something why many of the discussions on HN and Internet fail to get the point across, when you could have someone in their 10s or 20s who couldn't understand it. Just like how we were told when we were young.
>Nowadays I don't appreciate unbridled freedom as much. I appreciate and even enjoy constructive limitations. Truth is we can be very much like kids and should be protected from harming each other.
It is unfortunate this line of fine balance thinking is not well understood by many, young or old.
Let's not act like everyone who tries Rust gives up. OK? Sure it's definitely more difficult but people are learning and practicing and the pool is slowly expanding (me included, though I am not at production-grade experience yet).
> What you gain in reduced server costs is lost many times over in developer productivity.
Are you exaggerating for dramatic effect? I'd say depending on your people's seniority the productivity loss is anywhere from -50% to -500%, which is hardly "many times over".
You absolutely do iterate slower with Rust writing web backends -- no two ways about it. But you also (a) exaggerate the multiplier and (b) underestimate the long-tail of gained productivity that a language like Rust brings to the table (strong static typing et. al.)
And even if we take into account your comparison between server costs and programmer productivity -- there are areas where correctness and speed are more important than Joe and Susan being able to crank out 17 CRUD endpoints this week. I feel that this nuance is often ignored.
> Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++.
I have worked with Rails for 6.5 years and they knew no such thing. They treated server costs exactly like they treated programmers -- a necessary evil, a cost center that (currently) cannot be optimized away.
I am consistently blown away by the protected and downright pampering environments that some HN people have lived in. It's pretty brutal out there though, and somebody has to point that out to you every now and then, lest you forget it (which it seems that you did).
> They did the math and the business case for Rails was more compelling.
They did no math, except one: how easy it is to hire 5 new devs in the next 1-2 months. No other analysis was involved whatsoever. Again, I've looked from within, a good number of times.
---
I am all for an informed debate but that seems to be difficult with you as you resort to exaggerations and dramatic language.
For the record, I don't do my main work neither with Ruby on Rails nor with Rust (though I know both, or should I say I knew RoR because I haven't used it in a while now). I got no horse in the race, I am simply looking for an objective discussion based on merits that can hopefully ignore network effects and popularity. Technologies absolutely can and have won by utilizing network effects and popularity (see: Python) but that does not say much about their objective merits.
Luckily we now have company that is large enough with incentive to optimise it.
“But but but developer productivity” is a myth.
I skip Ruby hype but I know RoR and I use Golang professionally to build microservices serving Fortune 10,50,100,500, whatever and I wouldn't use Go to build a web-application.
Golang for microservice that relies on other microservices are great (i.e. my Golang service doesn't handle authN/authZ, but another service does), Golang for monolithic web-app that has to handle db migration (yeah I know something exist), implement multiple crud objects (remember, Golang microservices typically has smaller context and challenges than a medium size web-app) is pain in the ass!
PS: cut my teeth in Java servlet/jsp, moved on to Spring Framework+GWT, skipped RoR went straight to JS and ended up in Golang for the last 5+ years. I'm not Rails worshipers but I'd probably pick Java Spring ecosystem over Golang for monolithic web-app.
That language with C++ mindset is just... horrible.
I do appreciate Rust a lot but nowadays find myself reaching for Golang more often. I simply don't have the extra time and energy to learn the final more advanced Rust pieces in my own leisure time so I'll learn it whenever I can but yeah, in the meantime: Golang to the rescue.
Nobody does these days. Language is just a tiny piece of the whole Cloud ecosystem aside from k8s, docker, different storages (elastic, rdbms, mongo), different monitoring/metrics solution, etc.
I work for a company that is testing Rust and the complain was that the tooling wasn't there compare to Golang.
That's the only thing RoR wins at: speed of delivering first MVP.
Once you get into areas where companies don't die if they can't deliver a demo next week, RoR is not at all impressive or even consequential.
Can a python or ruby dev bang out Advent of Code faster than I can in zig or rust? Sure. Is advent of code representative of a multi-year long business system where coding is 15% of the time cost at the high end? Nah.
When you look at the actual bills and where the actual time goes, spending time on optimizing the code pace of a MVP is simply not valuable. You’re saving a small percent of a small percent of time at the beginning to accept using languages that are not know for their steady state support ability.
Well I don't know if this is a shallow generalization or just observation but in case it's the latter: I am a senior dev with too much stuff in my hands already, and my personal life's list of pleasures comprises of 2 items: sex and sleep. I figured that at 40+ that is VERY NOT OKAY and I am working to change it.
So yes, I no longer will sacrifice personal time to hone my programming weapons.
Or as we say here in the Balkans: "The quality of the music depends on the tip to the musicians".
Found nothing that would impress me. Ruby syntax? Who cares? Compiled and with better performance? Well, what's wrong with Golang and Rust? They do fantastically well.
I don't see what niche is Crystal trying to cater to. Other languages have better compilers and a bigger, more developed ecosystem.