Earlier quoted context omitted.
I also question the revenue claim. Google has a lot of revenue. Pinterest, Hashicorp, Uber, Twitch, Dropbox, etc. all have a good amount of golang and collectively have a lot of revenue. It might need a few more years to tip the scale, but it's closer than suggested here.
Twitch was initially built with Ruby on Rails as well.
Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
71–80 of 158 posts
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#72> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
Are there companies in the last 7 years that have started with rails and have become big like spotify?
Partly, you need mobile now, so any Rails stuff is likely to be back-end and hidden. Plus big investors like to go for the exciting stuff.
But if you're looking at companies aren't household names (taking smaller amounts of investment), there are lots out there.
Syft (recruitment) were founded in 2016 and have revenues of over $100m per year - although that's partly due to acquisition by a larger competitor, so when I just looked, separating their valuation from the group wasn't immediately obvious.
I've freelanced and contracted across a few niche industries (construction, print, airport signage management!) where I was building something against competitor software that I discovered was at least partially built with Rails. Those big players in each niche would have revenue in the tens of millions and from what I could see, very small technical teams.
But anyone outside those industries would never have heard of these companies.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#73> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"
Ok now what is the cost of all the instances. And how many instances would be required if Go/Rust would have been used? Also what is the cost in man hours spent on optimizations and profiling.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#74Earlier quoted context omitted.
Rails was initially too slow for Github, so they forked it, didn't use "Rails" for a while [1], lost literal engineering years to upgrading it (same for Shopify), and now Github has an engineering department dedicated to working of the Rails master branch directly, which is huge engineering overhead and a problem and solution that shouldn't exist. Github co-founder Tom lamented using Rails at Github and has stopped u…
Yes, not ideal. But we can’t know what would have happened if they had chosen a different language in 2007. Did they have the option of an efficient, well supported language that continues to be used in 2023? Maybe Java, although Java languished for years before development picked up again. C# is also a candidate. But one thing we can’t measure - how many candidates chose to join Shopify and GitHub because they were…
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#75Earlier quoted context omitted.
I also question the revenue claim. Google has a lot of revenue. Pinterest, Hashicorp, Uber, Twitch, Dropbox, etc. all have a good amount of golang and collectively have a lot of revenue. It might need a few more years to tip the scale, but it's closer than suggested here.
Twitch was initially built with Ruby on Rails as well.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#76Earlier quoted context omitted.
Ok now what is the cost of all the instances. And how many instances would be required if Go/Rust would have been used? Also what is the cost in man hours spent on optimizations and profiling.
Name one success on the scale of Shopify using Rust
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#77Earlier quoted context omitted.
That's not on a per-host basis. Shopify's design is, quite fortunately, one that partitions really well, as each store is completely independent of each other. Each store can be assigned to one pod, each pod can have as many hosts as it takes to optimize the use of a database instance, and then you can add more pods as the need arises. Edit: to be clear, that's not to say Rails can't scale. It can. It's just that it…
>That's not on a per-host basis. I'm sorry, but this is one of the silliest nit picks ive ever seen on this site. Of course 1 million rps and 3TB/s isn't coming from a single host. 3 TB/s is far beyond the throughput of any network I've ever seen, considered or thought of, short of maybe a data center (and I don't work in that domain). 1.3 million requests per second is far beyond the capacity of pretty much any hard…
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#78Earlier quoted context omitted.
Yeah it’s nearly the main benefit of Ruby/Rails that you can spin up an mvp of your company in like a week, and have a decent feature set within a couple months. The trap is when you start growing and it is hard to change. Because the features that took 1-2 months in RoR might take 3-4 months (or more!) to port to another language, and do you really want to stop your working business when it isn’t a problem? Because…
It is not 2006 anymore. Rails was a trailblazer. The productivity difference is not as large as it was compared to alternatives.
Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster
#79Earlier quoted context omitted.
That's not on a per-host basis. Shopify's design is, quite fortunately, one that partitions really well, as each store is completely independent of each other. Each store can be assigned to one pod, each pod can have as many hosts as it takes to optimize the use of a database instance, and then you can add more pods as the need arises. Edit: to be clear, that's not to say Rails can't scale. It can. It's just that it…
>That's not on a per-host basis. I'm sorry, but this is one of the silliest nit picks ive ever seen on this site. Of course 1 million rps and 3TB/s isn't coming from a single host. 3 TB/s is far beyond the throughput of any network I've ever seen, considered or thought of, short of maybe a data center (and I don't work in that domain). 1.3 million requests per second is far beyond the capacity of pretty much any hard…