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

131–140 of 277 posts

Re: Ruby 3.3

#131

Post by SkyPuncher »

jupp0r wrote: post #97
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…

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 does that matter?

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.

Re: Ruby 3.3

#132

Post by SkyPuncher »

TheAceOfHearts wrote: post #105
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…

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.

Meta programming is my largest complaint with Ruby. It creates huge surprises that are very difficult to inspect and debug.

Re: Ruby 3.3

#133

Post by SkyPuncher »

xivusr wrote: post #90
999900000999 wrote: post #57

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

I’d genuinely love to hear more about what you find difficult about Ruby coming from a heavier Python or NodeJS background. 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…

I’m primarily a Ruby dev, but still find most languages easier to work with.

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.

Re: Ruby 3.3

#134

Post by tauchunfall »

the_gastropod wrote: post #116
jupp0r wrote: post #114

Earlier quoted context omitted.

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.

But you could return the 1000 objects (or less? 1000 records sounds like a lot for any UI to show at once) of 1kb size and allow the clients to request specific pages with a request parameter. There may be applications where you need to ship the full 1M records I guess, but that seems like very much an edge case as far as web apps go.

True, you would not return 1000 objects at once to the frontend.

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.

Re: Ruby 3.3

#135

Post by SkyPuncher »

Alifatisk wrote: post #30
nextaccountic wrote: post #20

> RUBY_MAX_CPU=n environment variable sets maximum number of N (maximum number of native threads). The default value is 8. Shouldn't the default be the number of logical cores? Like Rust's Tokio and countless other M:N runtimes

Yeah, setting a hard cap on the maximum cpu count doesn’t feel right? Why not depend on the available cores?

It’s a safe choice. Some systems won’t report cores correctly which can lead to reallllllly bad performance.

Re: Ruby 3.3

#136

Post by weaksauce »

nerdponx wrote: post #82
burlesona wrote: post #75

Earlier quoted context omitted.

Ruby is basically a less popular but more elegant Python. It’s a solid general purpose language, but especially good at shell scripting, data munging, etc. 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 expressin…

Having tried to use Ruby for text processing specifically, I'm not sure I agree it beats Python at that particular task. Maybe I'm just used to the Python way of doing things, but I found it difficult to work with the lack of first-class functions and iterators/generators, as well as the general iteration protocol.

> lack of first-class functions and iterators/generators, as well as the general iteration protocol

can you elaborate on what you miss here? ruby has a robust enumerable suite of methods so i'm curious what you found lacking

Re: Ruby 3.3

#137

Post by [deleted] »

jupp0r wrote: post #97
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…

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.

[deleted]

Re: Ruby 3.3

#138

Post by jupp0r »

SkyPuncher wrote: post #131
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 does that matter? 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.

1MB is "absurdly large"? This is not the Todo app industry sorry.

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.

Re: Ruby 3.3

#139

Post by jweir »

SkyPuncher wrote: post #132
TheAceOfHearts wrote: post #105

Earlier quoted context omitted.

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.

Meta programming is my largest complaint with Ruby. It creates huge surprises that are very difficult to inspect and debug.

We ban most meta programming in our own code. While the meta programming solutions are fun and clever they are often more code than a functional version and hard to maintain.

We do allow the occasional use of “send” but try to avoid it. Dynamic method definitions are strictly banned.

Re: Ruby 3.3

#140

Post by cutler »

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

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.
Post reply on HN