I'm quite certain it's a troll.

Well, plus, Austin, your weather sucks. And, you're in Texas. You're the best that Texas has, sure, but still, you're in Texas.

Flip those around to positives, because they are relative and preferences, and you've got the recipe for why Austinites love Austin, the weather being among the top 3 reasons.

Also, Texas is objectively a better place to start a business, other than funding sources. Your tax rate is about HALF of what it is in California.

Not anymore. http://www.nytimes.com/2012/09/03/business/media/reddit-thri...

Can't even call it a Chinese wall...

I have a friend who's an O'Reilly author. Granted, he's not the author of, say, the book on Bash, or Git, but it's a current book. He likes to joke around about how little money he makes on the book (now in second edition): "I make hundreds of dollars. Hundreds!"

Yeah, +1 on that idea. PDF would be really nice.

Not quite. He's saying that people who think Ruby is slow are often people who have no idea how to performance-tune it.

Well, more of the time it's because Ruby actually is, in fact, slow.

I though the implementations were slow or fast, not the languages.

Typically a language is considered slow or fast based on it's most popular implementation, sadly.

Agreed, but it is still an implementation issue, because one can eventually discover ways to optimize such cases without changing the language.

Ruby is not, in fact, slow. This myth has been debunked so many times that I'll just leave the googling to you as an exercise.

Yup. They're like any other tool. If you're not sure how to use and/or, then don't use them. Or, better yet, study up. Programming can benefit from nuance.

Due to the Global Interpreter Lock (GIL), your whole script is wrapped in one giant mutex. That means that you don't have code running in true parallel, so the data is not corrupted as it is in JRuby and Rubinius (which both implement real, true, parallel threads).

That doesn't explain it. The runtime execution could still be like this:

  thread #1:
    local a = x[i]
    a = a + 1
    context_switch()

  thread #2:
    local b = x[i]
    b = b + 1
    x[i] = b
    context_switch()

  thread #1:
    x[i] = a

resulting in a wrong (or merely unexpected) result.

Not sure why someone chose to downvote this to 0, but here's how the OP put it:

The global lock is a feature of MRI that basically wraps a big mutex around all of your code. That's right, even if you're using multiple threads on a multi-core CPU, if your code is running on MRI it will not run in parallel.

OP is wrong, MRI will release the GIL (and yield to other threads) on IO and after running a bit (which can yield convoy effect actually lowering the performances). C extensions can also release the GIL when not manipulating VM structures.

Technically the GIL is there to protect the VM's internal state, so its operational semantics are that it's taken and released for each bytecode instruction.

However the efficiency would stink (short of awesome automatic lock elision or merging), so GIL-based VMs usually have a higher threshold, either based on some sort of instructions count (which may or may not map 1:1 to bytecode instructions) or an internal "wall clock" timer. I think MRI's the latter but don't quote me on it.

Correct. Later on I say:

  There are some very specific caveats that MRI makes for concurrent IO. If you have one thread that's waiting on IO (ie. waiting for a response from the DB or a web request), MRI will allow another thread to run in parallel.

I guess it's a lot easier to try things like this than to update your business model. That might require thinking and work.

I think we'd need to see this research. Just in terms of avoiding drive-bys, working remotely is far more stable and efficient (ergo productive).