Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.3

ruby-lang.org

Post reply on HN
Print view View original

181–190 of 277 posts

Re: Ruby 3.3

#181

Post by hello_moto »

gls2ro wrote: post #102
lp4vn wrote: post #66

Earlier quoted context omitted.

I worked with ruby, ruby in rails(RoR) more specifically, a bit more than ten years ago(2011-2013). At that time it was already the afterglow of RoR, the framework for web development that had come to life in 2005 and raged between 2007 and 2009. The latest-technology-addicted crowd was jumping into the boat of node.js, that was crazy fast compared to anything done RoR, and API oriented development with angularjs. In…

Ruby and Ruby on Rails are not in a downward trend. There were maybe some year where the interest was decreased but in the last 2 years a lot of things happened: Ruby has a lot new features, Rails 7 is out and comes with a new approach to web apps like for example Horwire with the just released Turbo 8. And there is a lot more: new conferences, new books and new gems. (Shameless plug: I curate a newsletter called Sho…

Hi-tech are cyclical.

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.

Re: Ruby 3.3

#182

Post by jsjohnst »

rjzzleep wrote: post #13
ksec wrote: post #2

I think Ruby 3.3 is perhaps one of the most important and feature rich Ruby release in the past 10 years. I never thought Ruby would have a shipping and production ready JIT before Python. And Prism, Lrama, IRB. A lot of these were discussed in previous HN submissions. 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 wo…

The one thing I genuinely don't understand is why there is no single task queue that works across ruby and python. I get that at some point people just started making http based microservices to pass information around, but at the end of the day a simple task queue that has a unified storage format across both is a better way to connect ruby(rails) based with the ml stack. There are probably thousands of custom rabbi…

> The one thing I genuinely don't understand is why there is no single task queue that works across ruby and python.

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.

Re: Ruby 3.3

#183

Post by lp4vn »

hello_moto wrote: post #181
gls2ro wrote: post #102

Earlier quoted context omitted.

Ruby and Ruby on Rails are not in a downward trend. There were maybe some year where the interest was decreased but in the last 2 years a lot of things happened: Ruby has a lot new features, Rails 7 is out and comes with a new approach to web apps like for example Horwire with the just released Turbo 8. And there is a lot more: new conferences, new books and new gems. (Shameless plug: I curate a newsletter called Sho…

Hi-tech are cyclical. 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…

Correct.

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.

Re: Ruby 3.3

#184

Post by jupp0r »

x86x87 wrote: post #144
jupp0r wrote: post #115

Earlier quoted context omitted.

The test was local, ie using the loopback interface on a large server.

Are you actually going to the DB or is that json synthetically generated? Is it the same json? What exactly are we testing here?

Sorry I was oversimplifying. Most of the data for the response comes from the db with some API calls for authorization and some auxiliary data. Benchmark was actually hitting the DB. Quite a bit of the 1mb response size is redundant (json-api format).

Re: Ruby 3.3

#185

Post by dexwiz »

wolfgang42 wrote: post #96
kyledrake wrote: post #69

Earlier 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…

The reverse is good also. 0.00005 vs 0.005 cents/request seems very close as a human. But considering that times the seconds in a day or month results in very different values.

Re: Ruby 3.3

#186

Post by jupp0r »

harshreality wrote: post #145
jupp0r wrote: post #97

Earlier quoted context omitted.

Ruby the language may be fast but the whole ecosystem is painfully slow. Try writing a server that serves 1mb of json per request out of some db query and some calls to other services. I get 100 requests per second in Rails. Same service rewritten in go serves 100k requests/s.

Why Rails, instead of a lighter-weight framework, if performance is such a priority? Obviously that wouldn't get you to [anywhere near] the performance of compiled Go code, but Rails has a lot of overhead. 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, reque…

First implementation was in Rails because the company is a Rails shop and the monolith was the easiest place to get something that works.

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.

Re: Ruby 3.3

#187

Post by KerrAvon »

jupp0r wrote: post #186
harshreality wrote: post #145

Earlier quoted context omitted.

Why Rails, instead of a lighter-weight framework, if performance is such a priority? Obviously that wouldn't get you to [anywhere near] the performance of compiled Go code, but Rails has a lot of overhead. 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, reque…

First implementation was in Rails because the company is a Rails shop and the monolith was the easiest place to get something that works. 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.

Why not something like Sinatra so it’s easy to prototype and move on from there if it’s still not good enough? What you’re describing isn’t that complex and the base Ruby language is so much better than Go.

Re: Ruby 3.3

#188

Post by neonsunset »

ochoseis wrote: post #160
seabrookmx wrote: post #152

Earlier quoted context omitted.

There's always this rift between the "language is slow" crowd and the "but it's not the bottleneck" crowd. I think this comes from the types of applications you work on and their scale. 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 th…

Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.

One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged).

I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.

Re: Ruby 3.3

#189

Post by 999900000999 »

hello_moto wrote: post #175
999900000999 wrote: post #57

Worth it to learn Ruby if you already know Python and NodeJS ? I find Ruby fascinating yet difficult.

Only if you want to build web-app that fit Rails. I wouldn't use NodeJS to build web-app that fits Rails. NodeJS ecosystem feels like building on a house of cards though.

NodeJS is probably my strongest language. But it's horribly unstable, the sheer amount of legacy code is overwhelming.

Python feels alot cleaner, but I wouldn't pick it over Node for web UI automation or Rest API testing.

Re: Ruby 3.3

#190

Post by cutler »

wredue wrote: post #180
cutler wrote: post #140

Earlier quoted context omitted.

But you factored-out developer productivity. What you gain in reduced server costs is lost many times over in developer productivity. Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++. They did the math and the business case for Rails was more compelling.

Rails is no more productive than go, and a developer taking 20 extra minutes (frankly, not likely, even if we’re talking rust) to write go rather than Ruby is not going to cost more than the $1000 a month the extra Ruby servers cost you just to run. “But but but developer productivity” is a myth.

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'm launching our MVP. There's Buffalo but you compared Go with Rails so I assume you meant rolling your own using just the Go standard library.
Post reply on HN