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

171–180 of 277 posts

Re: Ruby 3.3

#171

Post by asylteltine »

ciconia wrote: post #18

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

I’ve never met literally anyone who saw ruby and was happy. It’s always “but it’s written in ruby”

Re: Ruby 3.3

#172

Post by hello_moto »

jupp0r wrote: post #89
ric2b wrote: post #81

Earlier quoted context omitted.

Building a web backend with C++ is a very dangerous and complex ordeal, you're extremely likely to expose memory based vulnerabilities to the entire world.

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...

Re: Ruby 3.3

#173

Post by hello_moto »

pdimitar wrote: post #84
ric2b wrote: post #81

Earlier quoted context omitted.

Building a web backend with C++ is a very dangerous and complex ordeal, you're extremely likely to expose memory based vulnerabilities to the entire world.

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

#174

Post by hello_moto »

wredue wrote: post #130
cutler wrote: post #95

Earlier quoted context omitted.

Web backends in Rust and C++? Not saying web frameworks in these languages don't exist but to claim they're anything other than curiosities is misleading. In any case, good luck with the fraction of a millisecond such languages gain you while waiting on database i/o. There are use cases for switching to a compiled language like Rust or C++. Web back-ends isn't one of them.

Nah. One rust based server can power the same number of connections as 10-100 ruby based servers. 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).

I'd choose Go and Java any given day before Rust.

That language with C++ mindset is just... horrible.

Re: Ruby 3.3

#175

Post by hello_moto »

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.

Re: Ruby 3.3

#176

Post by hello_moto »

bluerooibos wrote: post #148
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 doesn't do anything better 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…

You bite, I'll spit.

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.

Re: Ruby 3.3

#177

Post by [deleted] »

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…

[deleted]

Re: Ruby 3.3

#178

Post by samtheprogram »

asylteltine wrote: post #171
ciconia wrote: post #18

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

I’ve never met literally anyone who saw ruby and was happy. It’s always “but it’s written in ruby”

Pleasure to meet you.

Re: Ruby 3.3

#179

Post by [deleted] »

jupp0r wrote: post #114
the_gastropod wrote: post #108

Earlier quoted context omitted.

But, like, why do you need a 1MB json response? That’s probably either a bad design or a use-case Rails is not designed for.

It's a paginated list of 1000 objects of 1kb size each. Any nontrivial API will have responses like that. My entire point was that Rails is not designed for this.

[deleted]

Re: Ruby 3.3

#180

Post by wredue »

cutler wrote: post #140
wredue wrote: post #130

Earlier quoted context omitted.

Nah. One rust based server can power the same number of connections as 10-100 ruby based servers. 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).

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.

Post reply on HN