Aaron Patterson

This is a nitpick, but this isn't entirely accurate:

"This is a function of how Rails does concurrency, which is by using multiple processes."

Multi-process vs multi-threaded is an application server architecture matter, not a Rails matter. Yes, your application must be thread safe, but this has been available in some form for Rails apps since a long time now [1]. The biggest problem in recent history has been Gems and their thread-safetyness (is that a word). The number of threaded Ruby application servers has been on the rise for a long while now, and even Passenger (traditionally the multi-process front-runner) is going threaded in version 4.0.

1: An interesting blurg post related to Config.threadsafe! (which was a huge source of confusion): http://tenderlovemaking.com/2012/06/18/removing-config-threadsafe.html

I think a parser is perhaps the example of very resorting to a compiled extension can be beaten by something more JIT-favourable, in a language like Ruby it tends to be heavily dominated by scanning text, and creation of objects, and 1) you can often speed it up drastically by reducing object creation. E.g. here is Aaron writing about speeding up the GraphQL parser partly by doing that, 2) creating Ruby objects and building up complex structures in the C extension is going to be almost exactly as slow in the C extension as in the Ruby, 3) the scanning of the text mostly hits the regexp engine which is already written in C.

[1] https://tenderlovemaking.com/2023/09/02/fast-tokenizers-with-stringscanner.html

> I don't know about the security vulnerabilities,

About 14 months ago, it caused some of the most serious vulnerabilities in the Ruby on Rails world ever: http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html

> why not just use JSON?

JSON is not really human-editable. Those quotes and commas, ugh! Also, JSON lacks comments.

The vulnerabilities in YAML (which is a superset of JSON, by the way) point at why YAML and JSON both aren't appropriate for configuration: they are _serialization_ formats. Configuration isn't what they're built for.

And you're right, it's really just not a huge deal in any way. Especially once we have `cargo project` to autogenerate the basics.

Great point. I haven't looked, but I think nokogiri fixes that bug. I think that was one tenderlove's motivations for creating nokogiri. He talks about it more on his blog:

http://tenderlovemaking.com/2008/10/30/nokogiri-is-released/

"I just want to tell you that you shouldn't worry about that old legacy code that uses Hpricot. Nokogiri can be used as a drop in replacement! Really! Nokogiri doesn't reproduce the bugs that are in Hpricot, but should work in most cases. Just use "Nokogir::Hpricot()" to parse your HTML. Of course, I've tried to keep the syntax of Hpricot that I like."

1. Rails + SSE (server sent events) - http://tenderlovemaking.com/2012/07/30/is-it-live.html

2. Rails + Pusher

Those are the best solutions, at hand that would work well with Rails.

I wouldn't advise smashing a Rails app and a Meteor app together unless you have a solid case to do so (like migrating).

Rails, aside, I'm happy to here oplog has landed. 1.0 feels imminent, the tension is growing, even here in Toronto. Stop waiting sheeple, Meteor is great as is, and it's only getting better.

> I hate that I can't easy determine where a given method of an arbitrary object is defined.

https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer.html

The relevant bit is under the heading:

> I’m calling a method, but I don’t know where it goes

def index
p method(:render).source_location
render params[:id]
end

It sounds like this is the answer to your monkey-patching woes.

my_object.method(:my_method).source_location # returns path/to/file:[line number]