HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nix-rust
nix
Rust2014–2021
nix-rust / nix

nix

Rust friendly bindings to *nix APIs

Systems & InfrastructureLibraries & SDKs
Explore on GitHubRead Hacker News discussions
8Distinct people
8Mentions
0Explicit recommenders
3.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Rust friendly bindings to *nix APIs

GitHub

Where it is used

No documented product use has been verified yet.

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:56:07 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 year8 dated mentions

Observed mentions: 2014-09-16 05:13:52 UTC to 2021-11-26 16:00:10 UTC.

01232014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2021

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202

What Hacker News says

8 sources
woodruffw·Nov 26, 2021
This post fails to speak to me on two fronts: * The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various *nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code. The author unfortunately chose a particularly messy and bug-prone corner of the POSIX APIs to wrap, and ran into a correspondingly intensive review process. I've merged simpler wrappers[1][2] with no fuss. * Alacritty seems to work just fine. I switched to it about two months ago, after using nothing but (heavily customized) rxvt-unicode for a decade. Maybe it's because I don't use ligatures or images in my term
Read the rest
inals (I thought we were talking about non-"toy" functionality!), but I haven't found myself wanting for anything beyond what Alacritty already does. And the scrollback seems to work nicely. To summarize: where's the tragedy? [1]: https://github.com/nix-rust/nix/pull/1342 [2]: https://github.com/nix-rust/nix/pull/1331
In Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
jimrandomh·Feb 6, 2017
Happy to hear bindgen is getting attention; I didn't actually notice that when I looked through the roadmap. I didn't try the nix crate at the time, but looking at it just now - it doesn't solve the portability issue. It defines struct Termios in https://github.com/nix-rust/nix/blob/master/src/sys/termios.... , with something #ifdef-ish branching on operating system, but not on CPU architecture. On quick inspection, I think it's probably incorrect on x86-32, and this crate is definitely a major liability for portability.
In Rust's 2017 Roadmap
fiveop·Feb 23, 2016
There is the library 'libc' which is a collection of interfaces to (g)libc functions together with the necessary constants and structs [1]. There is the library 'nix-rust' [2], which aims to provide a wrapper of 'libc' in idomatic Rust. Unlike 'libc', 'nix-rust' does not have a consistent code quality and organization yet. However, Both are missing various bindings for various platforms. [1] https://github.com/rust-lang/libc [2] https://github.com/nix-rust/nix
In Rewrite Everything in Rust
geofft·Sep 22, 2015
This is confounding two separate issues: using the system call interface instead of the platform C library, and static vs. dynamic linking. It's an easy thing to confound, because (as the author states) on many platforms, including not only Solaris but also OS X, the only interface to the libc is dynamic linking. But you can certainly dynamically link to libc.so without dynamically linking to anything else, and without using dynamic linking within your own language community. (Rust takes roughly this approach.) There's one more subtler problem with the "defined to exist on POSIX" thing: strictly speaking, what's defined to exist is a C-language interface. Some interfaces may be defined to use macros, and some platforms may make things work when compiled through the C compiler but not through the dynamic-linker interface. One example that
Read the rest
I've run into recently, when binding things in Rust, is the cmsg API, which is primarily defined in terms of macros to walk a heterogeneous array, and has to be reimplemented in Rust (with platform-specific code): https://github.com/carllerche/nix-rust/pull/179. Another example is Android, which before 5.0 (Lollipop) exposed a handful of signal-handling functions as inline functions in a C-language header file, so they were not actually dynamically linkable: https://github.com/rust-lang/rust/commit/a8dbb92b. In both of these cases I would have loved to just #include the C header, but cross-language, that wasn't an option. It does seem that cgo has some ability to just #include the C header, as demonstrated here. I'd be curious to know if it's powerful enough to handle these two cases. (Also, the author is totally right in saying that this doesn't belong inline in random application code. If you find yourself writing code like this, it should end up in an abstraction library so that porters have a single place to look, and any application calling `tcsetattr` gains the portability benefits.)
In On Go, Portability, and System Interfaces
wycats·Sep 16, 2014
A few: * https://github.com/carllerche/hamcrest-rust - a (badly in need of more fleshing out) testing library * https://github.com/carllerche/nix-rust - bindings of Linux/OSX-specific APIs to Rust * https://github.com/carllerche/curl-rust - a binding of libcurl to Rust * https://github.com/carllerche/pidfile-rust - a library for using a pidfile for mutual exclusion across processes * https://github.com/carllerche/mio - a low-level IO library that attempts to implement an epoll-like interface across multiple platforms
In The Road to Rust 1.0

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.