Earlier quoted context omitted.
> It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends. Right I see your point, but in this case it’s about Ruby, the language itself, not RoR.
Not denying it, I just struggle to find any non-RoR usage of Ruby out there except maybe for Homebrew.
Ruby 3.3
261–270 of 277 posts
Re: Ruby 3.3
#262I believe with version 3.3 Ruby is back in a big way! The language focused on developer happiness and derided for its slowness is slow no more. 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 performanc…
One area where Ruby could help improve developer experience is by providing a better debugging experience. I feel incredibly spoiled with Chrome Dev Tools. Meanwhile the last time I tried debugging heavy metaprogramming Ruby code it was a pain to figure out what was happening.
Re: Ruby 3.3
#263Earlier quoted context omitted.
Google, Facebook, Amazon and Twitter beg to differ (not completely C++, but for services where it makes sense). Also nginx, passenger and other parts of your Ruby app.
shrug the companies you mentioned do not use C++ for web-app. 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...
Re: Ruby 3.3
#264Earlier quoted context omitted.
I agree but people are doing it anyway. So technically Ruby on Rails and C++ are competitors in the web backend space.
Who builds web backend in C++?
Re: Ruby 3.3
#265Earlier quoted context omitted.
Sounds like Mike found a good feature that would encourage companies to purchase a license. I have a tremendous admiration for the business he's built.
You would think not losing jobs would be a required feature in any job queue software product.
A free software doesn’t have to be anything because it’s free.
Re: Ruby 3.3
#266Earlier quoted context omitted.
It sounds like you haven't worked with many startups which is where Rails has been the goto option for a very long time. Rails is a framework. Go is a programming language. Show me a Go command line which sets up a fully-baked MVC app complete with data model, migrations, CORS, caching, asset pipeline, mailer, mailbox, chat(Action Cable), job queue and a Hotwire equivalent. While you're baking all of that yourself I'…
> While you're baking all of that yourself I'm launching our MVP. 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.
Re: Ruby 3.3
#267Earlier quoted context omitted.
You would think not losing jobs would be a required feature in any job queue software product.
> You would think not losing jobs would be a required feature in any job queue software product. A free software doesn’t have to be anything because it’s free.
Re: Ruby 3.3
#268Earlier quoted context omitted.
> While you're baking all of that yourself I'm launching our MVP. 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.
I think that’s as far as the grand scheme of a project goes, coding productivity is a myth. 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…
Re: Ruby 3.3
#269Earlier quoted context omitted.
On the other hand, why is it wrong to say Ruby or Rails is slow? Especially in the context of Java or Go? What is wrong with accepting a simple ground truth that is compiled language is and will always be faster than an interrupted language, even with JIT. 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…
> What is wrong with accepting a simple ground truth 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 CRU…
>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.
Re: Ruby 3.3
#270Earlier quoted context omitted.
I don't know if a slight performance increase is going to sell anyone on ruby but I'm glad they're making incremental improvements on things. Being overly concerned about performance is almost always premature optimization, and ruby is more than fast enough for everything I've ever asked of it (including the binding glue between our redis DNS record storage and PowerDNS, where the entire stack serves half a billion q…
> half a billion queries a month across 14 tiny VPSes 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 I always do this when I see large-sounding query counts; a month has a lot of seconds in it, and it’s easier to visualize only one at a time: I can imagine hooking a speaker up to the server and getting a 14Hz buzz, or do…
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.