ruby-science VS ruby

So, bigger is worse, but how big is bad? At what number should you take action? Thoughtbot's Ruby Science book suggests a method is long or complex with a flog score above 10. It also posits that a class is long or complex with a flog score above 50.

Ruby Science - it's a free book by thoughtbot. It might be the most short term beneficial thing honestly. It just points out all of these various practical patterns you can immediate use to increase code quality.

I think you would appreciate Ruby Science. I love this book, it's extremely practical.

Well, if you're programming in Ruby, a great place to start is the Ruby Science book by ThoughtBot. It's a bottom-up approach to improving your code by identifying code smells and applying OO principles to fix them. Identifying smells in your own code will lead you to the OO principles that you need to learn to build your OO skills.

Read Ruby science to learn about code smells and good architecture.

It's a bit more advanced, but I like Ruby Science by thoughtbot.

Check out Ruby Science by Thoughtbot which I found useful at your stage.

Code smells. Ruby science is a good one for Ruby.

Currnetly reading ruby science. 200+ page guide on code smells and solutions.

This book is old but it's still very relevant https://github.com/thoughtbot/ruby-science. Also check out thoughtbot's blog and www.gorails.com

There's no need for ref counting, since Ruby has a mark & sweep GC.

The interned string table uses weak references. Any string added to the interned string tables has the `FL_FSTR` flag set to it, and when a string a freed, if it has that flag the GC knowns to remove it from the interned string table.

The keyword to know to search for this in the VM is `fstring`, that's what interned strings are called internally: https://github.com/ruby/ruby/blob/b146eae3b5e9154d3fb692e8fe...

> * A pointer to a unique class for that instance, called the “singleton class” of the object, also used for method lookup

I don't think this is accurate. The source code shows a generic `RObject` [0] contains flags, a pointer to a class (named `klass`), and instance variables. An `RClass` [1] contains flags, `klass`, `super` and a table of methods.

In both cases there is only a single pointer to a class that's used for method lookup.

> Ruby will look in the singleton class for the specific user instance first, and will only look for an instance method of the class if there is no matching method in the singleton class.

This is true, but it implies that Ruby does two separate lookups. The actual solution is more elegant.

An object's `klass` points to its singleton class, and method lookup happens only on that class and its superclasses. The second lookup implied above actually happens implicitly because the class of the object is an ancestor of the singleton class.

Specifically, for `class C`, its `klass` points to `<< C`, whose ancestors are `<< Object`, `<< BasicObject`, `Class`, `Module`, `Object` and `BasicObject`.

Ruby's whole object model, and the way it sets up this inheritance chain, is IMO beautiful and underappreciated.

> I’m not really sure why the Smalltalk solution wasn’t used

I think the way Ruby actually works is closer to the Smalltalk approach than the author realizes.

[0] https://github.com/ruby/ruby/blob/71f402c5d50919b0329d04704d...

[1] https://github.com/ruby/ruby/blob/71f402c5d50919b0329d04704d...

Ruby 3.4.0 was released today, December 25th, as the annual Christmas release (Ruby 3.4.0 Release). This year, we will also be explaining the NEWS.md file for Ruby 3.4 on the STORES Product Blog (incidentally, this will be an article for the STORES Advent Calendar 2024, written in Japanese). Please see the previous article for an explanation of what a NEWS file is.

I am most excited about the parser change, previously discussed here:

https://news.ycombinator.com/item?id=36310130 - Rewriting the Ruby parser (2023-06-13, 176 comments)

I remember being taught to use yacc in our compiler course because "writing it by hand is too hard". But looks like Ruby joins the growing list of languages that have hand-written parsers, apparently working with generated parsers turned out to be even harder in the long run.

That said, replacing a ~16k line parse.y[1] with a 22k line prism.c[2] is a pretty bold move.

[1] https://github.com/ruby/ruby/blob/master/parse.y

[2] https://github.com/ruby/prism/blob/main/src/prism.c

In fact, CRuby successfully combined “Self Tagging” with pointer tagging. Here's the commit:

https://github.com/ruby/ruby/commit/b3b5e626ad69bf22be3228f8...

Unix sockets can use tcp, udp, or be a raw stream

https://en.wikipedia.org/wiki/Unix_domain_socket#:~:text=The....

Puma creates a `UnixServer` which is a ruby stdlib class, using the defaults, which is extending `UnixSocket` which is also using the defaults

https://github.com/puma/puma/blob/fba741b91780224a1db1c45664...

Those defaults are creating a socket of type `SOCK_STREAM`, which is a tcp socket

> SOCK_STREAM will create a stream socket. A stream socket provides a reliable, bidirectional, and connection-oriented communication channel between two processes. Data are carried using the Transmission Control Protocol (TCP).

https://github.com/ruby/ruby/blob/5124f9ac7513eb590c37717337...

You still have the tcp overhead when using a local unix socket with puma, but you do not have any network overhead.

However, it turned out that this is really a bug in Ruby and will be fixed in Ruby 3.2.7, 3.3.7 and 3.4.0. While we're at it, I'd love to thank the Ruby core team for their swift responses and their efficiency at fixing this. It took Peter Zhu only a few hours, I wish I was as motivated as this gentleman.