4 ms·

I have been working on the same problem in other areas. My ultimate goal is to rewrite nginx in Rust passing as much as the upstream tests as possible while lev

by ianm218 4mo ago

I have been working on the same problem in other areas. My ultimate goal is to rewrite nginx in Rust passing as much as the upstream tests as possible while leveraging the strongest aspects of Ruts ecosystem - i.e. rustls (modern memory safe OpenSSL), Tokio (async runtime), h2 (http 2 impl) rather than implementing from scratch like the upstream. I started with Lua, then porting over Valkey, and now working on nginx. The reason was because I wanted to learn the ins and outs before taking on the most complex portion. [1]. https://github.com/ianm199/lua-rs/tree/main https://github.com/ianm199/lua-rs/tree/main Lua [2]. https://github.com/ianm199/valdr https://github.com/ianm199/valdr Valkey/ Redis [3]. https://github.com/ianm199/nginx-rs-port https://github.com/ianm199/nginx-rs-port nginx Happy to answer any questions on the approach! When I started a few weeks ago the harnesses on their own were not good enough to get very far without a "meta harness" of sorts but that is changing largely with Claude Workloads and Mythos. A lot of the work is developing some custom tooling to move these along faster.

jabwd 4mo ago
Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?
- ianm218 4mo ago
  Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world. But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance. For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops. Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.
  - jabwd 4mo ago
    Buddy, I think it is time to not engage with these models for a bit, you seem to have lost your mind.
    - ianm218 4mo ago
      We're literally in a thread on converting legacy C projects to idiomatic Rust? It seems many people are working on this same problem.
      - jabwd 4mo ago
        There are plenty of Rust based reverse proxies out there, why do you need to specifically rewrite nginx? You could also write a config adapter to Caddy, there are a billion options, but this is a wasted effort. The people who want to stick to their nginx configs won't use your project ever, and the people who actually care about security aren't going to use a vibe coded project. I have no idea why you are making me spell this out, I thought it was pretty obvious.
      - feelamee 4mo ago
        nit: well-written C projects to legacy Rust
  - fvdessen 4mo ago
    You mean you rewrote the nginx test suite with smaller leaner tests ? How did you bootstrap that ? How do you know the leaner tests are equivalent to the real ones ?
    - ianm218 4mo ago
      Here is an example https://github.com/ianm199/nginx-rs-port/blob/main/crates/nginx-rs/src/server/tokio_parity_kit.rs https://github.com/ianm199/nginx-rs-port/blob/main/crates/ng... Basically I use these "kits" to prove that the behavior is working as expected with mocked data/ interfaces and then only after these kits pass I'll run the real test suite files as confirmation. So these let you iterate a lot faster than the official test suite because it is very slow. These are bootstrapped from the real tests. The other commenter was being a bit dismissive but this is the kind of thing I'm taking away as a real useful pattern to do verification of behavior at scale.
- jauntywundrkind 4mo ago
  One very strong draw I feel, that's mentioned in this article: Rust's portability, it's ability to be compiled to wasm & run very well anywhere.
- bitwize 4mo ago
  Because C code in production is a ticking time bomb.

by ianm218 4mo ago

jabwd 4mo ago

Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?

ianm218 4mo ago
Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world. But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance. For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops. Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.
- jabwd 4mo ago
  Buddy, I think it is time to not engage with these models for a bit, you seem to have lost your mind.
  - ianm218 4mo ago
    We're literally in a thread on converting legacy C projects to idiomatic Rust? It seems many people are working on this same problem.
    - jabwd 4mo ago
      There are plenty of Rust based reverse proxies out there, why do you need to specifically rewrite nginx? You could also write a config adapter to Caddy, there are a billion options, but this is a wasted effort. The people who want to stick to their nginx configs won't use your project ever, and the people who actually care about security aren't going to use a vibe coded project. I have no idea why you are making me spell this out, I thought it was pretty obvious.
    - feelamee 4mo ago
      nit: well-written C projects to legacy Rust
- fvdessen 4mo ago
  You mean you rewrote the nginx test suite with smaller leaner tests ? How did you bootstrap that ? How do you know the leaner tests are equivalent to the real ones ?
  - ianm218 4mo ago
    Here is an example https://github.com/ianm199/nginx-rs-port/blob/main/crates/nginx-rs/src/server/tokio_parity_kit.rs https://github.com/ianm199/nginx-rs-port/blob/main/crates/ng... Basically I use these "kits" to prove that the behavior is working as expected with mocked data/ interfaces and then only after these kits pass I'll run the real test suite files as confirmation. So these let you iterate a lot faster than the official test suite because it is very slow. These are bootstrapped from the real tests. The other commenter was being a bit dismissive but this is the kind of thing I'm taking away as a real useful pattern to do verification of behavior at scale.
jauntywundrkind 4mo ago
One very strong draw I feel, that's mentioned in this article: Rust's portability, it's ability to be compiled to wasm & run very well anywhere.
bitwize 4mo ago
Because C code in production is a ticking time bomb.