3 ms·

"Fast" and "pure-Ruby" in one phrase puzzles me.

by myst 10y ago

blunte 10y ago
It's all relative. For processing one or a few documents at a time, on modern hardware it probably doesn't matter what language is used. Repeat the process on a million documents (do a million markdown docs exist in one place?), and Kramdown might not be considered "fast" compared to other options...
- busterarm 10y ago
  We're processing several thousand documents every time our site builds and performing multiple full-document regexp replacements, writing YML front matter and parsing HTML to Kramdown. Only takes a few seconds total.
  - blunte 10y ago
    Exactly. As long as it fits your situation, it's fast enough. My last company used Ruby a lot (and it's what got me hired there), but we hit so many cases where the data was so large that we were forced to use something else. My colleague would fall back to Java, but I used those times as excuses to learn Go. Where Ruby fits, it's wonderful. Where it just doesn't fit, all of its niceness is overshadowed by its scaling issues.
    - busterarm 10y ago
      I've done massive (billions of rows) ETL jobs in pure ruby (since 2.2.0) without Ruby being the bottleneck. A lot of performance problems I've seen went away when they fixed the garbage collection (especially of symbols). There's a small handful of others I saw resolved by using JRuby. I mean, if you need good threads, you probably shouldn't be on Ruby, but as far as I can tell its single-core performance is pretty okay compared to other scripting languages. It's still the absolute best (most features I need in the standard library, or easy to use libraries, and easiest to use) thing I've ever used for working with manipulating large quantities of text (save for maybe Perl, but ew). I've started using Elixir when I need concurrency, but Ruby is still the language I'm most likely to use for most classes of problem.

3 ms·

"Fast" and "pure-Ruby" in one phrase puzzles me.

by myst 10y ago

"Fast" and "pure-Ruby" in one phrase puzzles me.

blunte 10y ago
It's all relative. For processing one or a few documents at a time, on modern hardware it probably doesn't matter what language is used. Repeat the process on a million documents (do a million markdown docs exist in one place?), and Kramdown might not be considered "fast" compared to other options...
- busterarm 10y ago
  We're processing several thousand documents every time our site builds and performing multiple full-document regexp replacements, writing YML front matter and parsing HTML to Kramdown. Only takes a few seconds total.
  - blunte 10y ago
    Exactly. As long as it fits your situation, it's fast enough. My last company used Ruby a lot (and it's what got me hired there), but we hit so many cases where the data was so large that we were forced to use something else. My colleague would fall back to Java, but I used those times as excuses to learn Go. Where Ruby fits, it's wonderful. Where it just doesn't fit, all of its niceness is overshadowed by its scaling issues.
    - busterarm 10y ago
      I've done massive (billions of rows) ETL jobs in pure ruby (since 2.2.0) without Ruby being the bottleneck. A lot of performance problems I've seen went away when they fixed the garbage collection (especially of symbols). There's a small handful of others I saw resolved by using JRuby. I mean, if you need good threads, you probably shouldn't be on Ruby, but as far as I can tell its single-core performance is pretty okay compared to other scripting languages. It's still the absolute best (most features I need in the standard library, or easy to use libraries, and easiest to use) thing I've ever used for working with manipulating large quantities of text (save for maybe Perl, but ew). I've started using Elixir when I need concurrency, but Ruby is still the language I'm most likely to use for most classes of problem.