There is nothing that requires Sass and other Ruby programs to be endemic to Ruby world. The programming language it is implemented in is an implementation detail after all.
This is technically, and therefore the best kind of, correct, but in practical usage there's Ruby and JRuby and, uh...does it run in IronRuby?
I mean, libsass is a thing, but it's not nearly feature-complete. You end up bolting a Ruby thing into your pipeline somewhere, which is a bit of a drag depending on how you're used to doing things. (For me, I just let Play handle it, but if somebody hadn't made play-sass I probably wouldn't be using Sass at all.)
I am not a designer, and the only place I use sass is a bunch of static blogs, including my primary one. The command I run to compile my sass files is as follows:
find . -name '*.sass' | onchange -s make css
where onchange is a simple command I've written that watches filesystem for events on files from stdin and runs command when they occur, and make css is simply
sass --update _sass:dynamic/styles
So long as sass is in the $PATH, I'm good to go. I don't care how my sass files are translated to css files, I only care whether they get translated or not. In the last place I worked, they used guard for compiling less (sth. like sass) files and concatenating them, which was a frightening program with a huge configuration file, written in JSON. For concatenation, I'd do
See, when your abstractions are processes, everything is easy. It's like git, one simply does not need to know if git commit is a shell script or a C program. It is a process, you need to call it, and that's it.
edit: put in absent redirection into the last command line.
I mean, libsass is a thing, but it's not nearly feature-complete. You end up bolting a Ruby thing into your pipeline somewhere, which is a bit of a drag depending on how you're used to doing things. (For me, I just let Play handle it, but if somebody hadn't made play-sass I probably wouldn't be using Sass at all.)