I remember setting up a new git CI build server many years ago, which at the time rather quickly started failing build pipelines in a nodejs css frontend build script, turns out there was something funky with the AMD processor's RDRAND. A motherboard BIOS flash update fixed it.
https://github.com/sass/libsass/issues/3151
In AMD's random number generator can't generate a 0?sass
libsass
C++2012–2026
sass / libsass · Archived
libsass
A C/C++ implementation of a Sass compiler
27Distinct people
27Mentions
0Explicit recommenders
4.3KGitHub stars
What to know before exploring
What it is
A C/C++ implementation of a Sass compiler
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2012-04-23 21:29:03 UTC to 2026-09-22 20:06:38 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 9 | 2 | 7 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
LibSass - Sass compiler written in C++
LibSass has reached its end of life.
It will no longer receive updates of any kind. Users should migrate to
Dart Sass at their earliest convenience.
Currently maintained by Marcel Greter (@mgreter) and Michael Mifsud (@xzyfer)
Originally created by Aaron Leung (@akhleung) and Hampton Catlin (@hcatlin)
Warning: LibSass is deprecated.
While it will continue to receive maintenance releases indefinitely, there are no
plans to add additional features or compatibility with any new CSS or Sass features.
Projects that still use it should move onto
Dart Sass.
LibSass is just a library!
If you want to use LibSass to compile Sass, you need an implementer. Some
implementations are only bindings into other programming languages. But most also
ship with a command line interface (CLI) you can use directly. There is also
SassC, which is the official lightweight
CLI tool built by the same people as LibSass.
Excerpt of Supported Implementations:
https://github.com/sass/node-sass (Node.js)
https://github.com/sass/perl-libsass (Perl)
https://github.com/sass/libsass-python (Python)
https://github.com/wellington/go-libsass (Go)
https://github.com/sass/sassc-ruby (Ruby)
https://github.com/sass/libsass-net (C#)
https://github.com/medialize/sass.js (JS)
https://github.com/bit3/jsass (Java)
https://github.com/scottdavis/sass.ex (Elixir)
https://github.com/Youimmi/sass_compiler (Elixir)
This list does not say anything about the quality of either the listed or not listed implementations!
The authors of the listed projects above are just known to work regularly together with LibSass developers.
About
LibSass is a C++ port of the original Ruby Sass CSS compiler with a C API.
We coded LibSass with portability and efficiency in mind. You can expect LibSass to be a lot
faster than Ruby Sass and on par or faster than the best alternative CSS compilers around.
Developing
As noted above, the LibSass repository does not contain any binaries or other way to execute
LibSass. Therefore, you need an implementer to develop LibSass. Easiest is to start with
the official SassC CLI wrapper. It is guaranteed to compile
with the latest code in LibSass master, since it is also used in the CI process. There is no
limitation here, as you may use any other LibSass implementer to test your LibSass branch!
Testing
Since LibSass is a pure library, tests are run through the Sass-Spec
project using the SassC CLI wrapper. To run the tests against LibSass while
developing, you can run ./script/spec. This will clone SassC and Sass-Spec under the project folder and
then run the Sass-Spec test suite. You may want to update the clones to ensure you have the latest version.
Note that the scripts in the ./script folder are mainly intended for our CI needs.
Building
To build LibSass you need GCC 4.7+ or Clang/LLVM. If your OS is older, you may need to upgrade
them first (or install clang as an alternative). On Windows, you need MinGW with GCC 4.7+ or VS 2013
Update 4+. It is also possible to build LibSass with Clang/LLVM on Windows with various build chains
and/or command line interpreters.
See the build docs for further instructions!
Compatibility
For all intents and purposes LibSass is fully compatible with the Sass language spec. Any known
differences can be found as open issues.
About Sass
Sass is a CSS pre-processor language to add on exciting, new, awesome features to CSS. Sass was
the first language of its kind and by far the most mature and up to date codebase.
Sass was originally conceived of by the co-creator of this library, Hampton Catlin (@hcatlin).
Most of the language has been the result of years of work by Natalie Weizenbaum (@nex3) and
Chris Eppstein (@chriseppstein).
For more information about Sass itself, please visit https://sass-lang.com
Initial development of LibSass by Aaron Leung and Hampton Catlin was supported by Moovweb.
Licensing
Our MIT license is designed to be as simple and liberal as possible.
Read the full README on GitHubWhat Hacker News says
27 sources"New Tech Is Just Recycled Old Tech"
Without quoting the entire paragraph, I'm not sure "C" has ever been the mainstream choice. At nearly every point in the history of C, there has been a "better" or more popular language. Be that jcl, cobol, fortran, visual basic, java, python, php, C#, etc.
C/C++ are systems programming languages, they are the underlying technology supporting all the business and application development. Even when I did less pure system programming, our applications were frequently split into a lower level/server/etc portion and the higher level user facing code. The former was written in a high perf compiled language, the user facing code was generally written in a higher level language.
And that is still true today, it takes very little google foo, to find project after project which decided they needed higher perf/m
Read the rest
ore efficiency and rewrote the core data handling in C. Even in cases where C/C++ weren't the obvious choices (https://github.com/sass/libsass).
And yes, sometimes one ends up picking a chain of subpar languages and rotating them du-jour. But in that direction you get trapped on both some language everyone hates (facebook/php anyone? although to be fair facebook has made php one of the better choices these days) So much so, that if I were to start another mobile application, I would probably use one of the C++ based toolkits. Because those are the only choices that provide good cross platform UI's that are performant. For everything else I would probably just write a web application with decent local storage caching/etc.
So, its probably an unpopular opinion, but as a senior developer, I think the ability to make unpopular choices, particularly when it comes to language and toolkits is one of my strongest attributes. Rarely will you find me picking something like react-native (or electron) for mobile apps because i've yet to see a case were the benefits actually outweighed the negatives. Similarly for native toolkits tied to a particular platform because i've yet to work anywhere that could legitimately afford to double (or worse) their engineering efforts by writing the same application multiple times.
Browsers depend on tons of 20-year-old C libraries.
At the moment, the top link from the Twitter account you gave above is this one from November 6:
https://twitter.com/LazyFishBarrel/status/119228101802954342...
It reports a total of 37 issues in:
- freetype2 (C lib, 20+ years old)
- usrsctp (C lib, age unknown)
- libexif (C lib, age unknown)
- libxslt (C lib, 20+ years old)
- imagemagick (C lib, 20+ years old)
- mruby (C)
- php (C)
- openSSL (C, 20+ years old)
- curl (C lib, 20+ years old)
- ffmpeg (C lib, 18 years old)
- ghostscript (C lib, 30 years old)
- irssi (C, 20 years old)
In that list were also Skia and libsass, two projects actually written in C++.
In Sass, the issue is a nullptr issue:
https://github.com/sass/libsass/issues/3001
In Skia the bug was in intrinsics code:
https://skia.googlesource.com/ski
Read the rest
a/+/0f55db539032a23b52897ae...
Of course that's a single data point, but it shows what I think is a reasonable argument: most of the issues indeed happen in (old) C code, for well-known reasons (no standard string, array or collection support, no RAII), but because C++ supports those things by default it largely avoids those issues.
It's worth noting that libsass's source map support is still ironing out bugs (i.e. https://github.com/sass/libsass/pull/1463), though it seems that the compilation itself is relatively solid. My team finds that the time saved in compilation for a Flask app is worth source maps sometimes not working. Your mileage may vary, though.
In Office UI FabricYou can use LibSass which is written in C++, to avoid the Ruby dependencies. https://github.com/sass/libsass
In What’s New in Bootstrap 4Ruby's not required. The article doesn't mention Ruby but it mentions libsass (why Ruby is no longer required):
"This is great because Sass tends to be more favorable by front-end developers. It also compiles faster thanks to Libsass."
https://github.com/sass/libsass
In What’s New in Bootstrap 4Here: https://github.com/sass/libsass#contribution-agreement
I think it's unfortunate. While I'm comfortable with assigning copyright to nonprofit organizations with a commitment to keep code free and enforce the license, I'm not comfortable assigning copyright to individual people.
In Bootstrap 4 alphaThere's no reason to use Ruby https://github.com/sass/libsass
In Bootstrap 4 alphaIt depends how you define bloat. If you define bloat strictly as number of dependencies, then sure, the Node ecosystem encourages more "bloat" than any other mainstream ecosystem.
But if you define bloat as "inclusion of features I'm not using," the Node ecosystem is lean and mean. If I only need 15 of the 250 functions that Lodash provides, I can include each of those 15 functions as an individual package. Yes, it increases disk space, because each dependency ships a package.json and a README and subdependencies aren't shared, but disk space is cheap. Decreasing the surface area of my library dependencies is worth it for my development happiness.
I think the criticism you want is "ultra-modular." You can make an argument that Node's proliferation of tiny, one-function packages is a maintenance burden and causes discoverability problems.
Read the rest
Personally, I disagree: any effort to move towards a world where you never have to write a line of code someone else already has is well worth it. And from an end-user perspective, it shouldn't matter at all. `npm install` on average takes no longer than `gem install` for me, despite NPM pulling in orders of magnitude more packages.
(Python might be bloated; have you ever looked at the complete stdlib? There are some horrifying pieces: urllib2, email, turtle (?!).)
P.S. Check out libsass [0], a re-implementation of Sass in C with [probably] bindings to your favorite programming language.
[0]: https://github.com/sass/libsass
Libsass 3.2.0 released. Biggest release to date
2 points · Open discussionLibsass 3.2 preview release is out
1 points · Open discussionIt's not quite there yet, but they've made a lot of progress in the last few months:
https://github.com/sass/libsass/wiki/The-LibSass-Compatibili...
https://github.com/sass/libsass/milestones/3.2
http://sass-compatibility.github.io/
It's at the point where I can use node-sass and Ruby Sass interchangeably for our (very large) Sass code base at my company, but we also don't rely very heavily on the newest features. Worth a try, anyway.
If node-sass doesn't work for you though, there's also a webpack loader for Ruby Sass: https://github.com/ddelbondio/ruby-sass-loader
In Show HN: Essential React, a minimal skeleton for building React apps using ES6ProTip: Hit the y key on any GitHub page with source code.
It'll instantly expand the URL to its canonical form, e.g.
https://github.com/sass/libsass/blob/master/parser.cpp#L29-L...
to
https://github.com/sass/libsass/blob/fca1f75a14fe5336c7b1a4b...
which stays valid indefinitely (unless the commit is deleted from the repo).
P.S. Hit the ? key for more keyboard awesomeness. :)
In Don't link to line numbers in GitHubLibsass 2.0 supports .sass syntax
1 points · Open discussionI haven't. I've never used SASS directly on the production server, I just run Compass on dev and push the compressed css to a cdn or media server.
You might want to look into the C implementation? https://github.com/hcatlin/libsass
In Show HN: Wagtail, our new Django CMSShowing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.