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 2 hours ago | parent | next [-]

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.

▲

fvdessen 2 hours ago | parent | next [-]

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 an hour ago \| parent [-]
		Here is an example 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.

▲

tredre3 an hour ago | parent | prev | next [-]

> 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

That is true, however did you actually do any research into nginx? Is it particularly prone to memory bugs?

I honestly don't know the answer but you seem to be coming from a place of C bad, therefore nginx super vulnerable?

In my experience with other web servers the vast majority of security bugs are string handling related (path/header injection), which your rewrite will not protect you from.

▲

ianm218 an hour ago | parent [-]

https://securityaffairs.com/192132/hacking/nginx-rift-an-18-...

The project was inspired by that. Also unlike most other projects, nginx is directly exposed to the internet often times which makes it more vulnerable than i.e. Redis/ Valkey or something that would be running within a companies network generally.

"C Bad" is a bit reductionist... but I think there is some truth to the take " Until you have the evidence, don’t bother with hypothetical notions that someone can write 10 million lines of C without ubiquitious memory-unsafety vulnerabilities – it’s just Flat Earth Theory for software engineers" [1]

NSA and other government orgs are also pushing people to stop using C [2] for important software.

[1]. https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... [2]. https://linuxsecurity.com/news/government/nsa-s-plea-stop-us...

	▲	uecker 33 minutes ago \| parent [-]
		I think the risks of a rewrite - especially when using AI - are far more problematic than memory safety. In the long run those C projects will be memory safe in the next five years using memory safe C implementations.

▲

jabwd 2 hours ago | parent | prev [-]

Buddy, I think it is time to not engage with these models for a bit, you seem to have lost your mind.

▲

ianm218 2 hours ago | parent [-]

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 2 hours ago \| parent \| next [-]
		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 27 minutes ago \| parent \| prev [-]
		nit: well-written C projects to legacy Rust

▲

jauntywundrkind 2 hours ago | parent | prev [-]

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.