ntp-parser
rfcs
| ntp-parser | rfcs | |
|---|---|---|
| 1 | 692 | |
| 19 | 6,259 | |
| - | 0.4% | |
| 0.0 | 9.1 | |
| almost 4 years ago | 12 days ago | |
| Rust | Markdown | |
| Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ntp-parser
-
Hey Rustaceans! Got an easy question? Ask here (9/2021)!
Well nom does list out examples on the readme page, though many are probably for older versions of nom. I clicked through a couple and it looks like ntp is up to date with nom 6.0. The last full parser I wrote using nom was in v4.0 days, which was more macro-oriented than current nom. Since what you pass nom is slices of data, you will basically be reading from a file into a buffer, and calling your parsing functions on that. If it returns an error indicating it is incomplete, just read in another chunk of data into your buffer and try again.
rfcs
- Rust in 2025: Targeting foundational software
- Writing a Good Design Document
-
Demoting i686-PC-windows-gnu to Tier 2
> Interestingly, Windows on ARM hasn't made it up to Tier 1 yet.
An RFC for that has been submitted recently: https://github.com/rust-lang/rfcs/pull/3817
-
Writing into Uninitialized Buffers in Rust
This is already discussed for Rust: https://github.com/rust-lang/rfcs/pull/3605. TL;DR: it's not as easy as it looks to just add "freeze."
- RFC – Rust extended standard library
-
Rust Dependencies Scare Me
Some people _do_ care about this (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810). However, for some reason (culture, I guess?) there isn't much momentum yet to change the status quo.
Actually, a proposal for exactly this was published yesterday: https://github.com/rust-lang/rfcs/pull/3810
It's unfortunate that the response so far hasn't been very positive
- RFC: Rust Extended Standard Library
-
Rust to C compiler – 95.9% test pass rate, odd platforms
> > no dynamic linking
> There is.
Eh, I'm a Rust fan, and I hate the dynamic linking situation too.
I genuinely cannot see how Rust would be able to scale to something usable for all system applications the way it is now. Is every graphical application supposed to duplicate and statically link the entire set of GNOME/GTK or KDE/Qt libraries it needs? The system would become ginormous.
The only shared library support we have now is either using the C ABI, which would make for a horrible way to use Rust dependencies, or by pinning an exact version of the Rust compiler, which makes developing for the system almost impossible.
Hopefully we'll get something with #[export] [1] and extern "crabi" [2], but until then Rust won't be able to replace many things C and C++ are used for.
[1] https://github.com/rust-lang/rfcs/pull/3435
[2] https://github.com/rust-lang/rfcs/pull/3470
-
Traits in Rust Explained: From Usage to Internal Mechanics
As you can see, all trait methods are stored in sequence without any distinction between which method belongs to which trait. This is why upcasting is not possible. There's an ongoing RFC—RFC 2765—tracking this issue. Instead of discussing the solution proposed by the RFC here, we’ll introduce a more general workaround by adding an AsBase trait:
What are some alternatives?
alexandrie - An alternative crate registry, implemented in Rust.
polonius - Defines the Rust borrow checker.
rust-ffi-omnibus - A collection of examples of using code written in Rust from other languages
rust - Empowering everyone to build reliable and efficient software.
minimax-rs - A generic implementation of Negamax in Rust.
Rust-for-Linux - Adding support for the Rust language to the Linux kernel.