It's much better than the old competition in many ways, so there's that.
Maybe batteries included would be great (web UI similar to HAProxy but way-way better).
Instead of "Blazing Fast", just show a chart showing you are better per core than XYZ.
Instead of "fearless concurrency", show that you are better at utilizing system resources than XYZ.
i will add to the pile of cgi hosts in our CI for weird and borderline hostile php projects and report back.
I think the "web server" ecosystem in Rust is pretty mature by now, so you should probably state in what way your project is novel on the website.
Edit: OK, I realized that this is supposed to be an nginx/caddy replacement, so a complete, configurable web server/proxy. Maybe check out https://github.com/memorysafety/river or https://github.com/sozu-proxy/sozu
While there are standalone web servers in Rust, such as Static Web Server and binserve, they primarily focus on serving static files rather than providing general-purpose web hosting capabilities. My goal is to create a more versatile web server that can handle a wider range of web hosting applications.
Edit: or https://github.com/memorysafety/river
Edit 2: or https://github.com/sozu-proxy/sozu
https://github.com/flosse/rust-web-framework-comparison
How does Ferron distinguish itself from these? I didn't get that from skimming the landing page.
And that’s not even counting all the webservers included as part of their backend frameworks in Python, node.js, Java, etc.
web servers written in unsafe languages are really the minority but those that do exist are largely so heavily battle tested that a rewrite would likely introduce new sources of bugs (eg Apache and nginx).
If there’s one domain that’s seen a lot of competition for security, it’s been web servers.
Anybody have any suggestions beyond the one under discussion?
I clicked through the first few and they talk about building applications with them. That is explicitly what I excluded.
It does mean that you end up with per-app binaries, which is either a pro or a con depending on the use case.
I love auto TLS and caddyfiles are easy to understand. Modularity is important and templates can be very useful. Serving files and using caddy as reverse proxy are the most common uses I make of it in production, but I also use caddy in dev and it's a boon. Ease of config means my team can easily pick up my work and continue from there, even if they are not as proficient with the tool.
I don't love caddyfile directive ordering: sometimes my colleagues are confused because directives have an implicit order that is not obvious: instead of reordering directives, I'd rather have a warning/error message saying "this config doesn't make sense because you cannot do this and that", or just follow the order used in the config file + warnings.
I use it a lot to prototype and mock APIs during development, e.g. to have endpoints returning html pages or json documents: static files and templates are useful for this and I wouldn't consider something without this feature, though go templates aren't that great and/or caddy docs are a bit lacking (e.g. a simple loop over 0,1,2,3... Is not obvious!)
I don't find caddy great (or I don't know how to use it) to debug things when they are not working as expected. I often find myself replacing parts of the infra with netcat so that I can inspect what is going on. It would be great to have a "debug endpoint", like a webpage I could connect to and inspect all the traffic like MITM proxy, it would be awesome. Being able to inject myself in a route and manually change headers, responses, requests etc, it would be fantastic and a great help in debugging issues. Also, being able to start this "inspection mode" while in production would be nice, without having to restart the server (something is off -> I ssh-port-forward to the server host -> connect my browser to the server and inspect the errors -> find the issue and fix the config).
Management of certs could be improved in some edge cases. For example, I'd be happy if it was easier to manage certs in a private subnet. For example, say host A could acquire certs for my domain example.com with DNS challenge, then a host B, not public facing but in a subnet with A, could ask A to manage its certificates and still have valid https (letsencrypt provided certs) inside the network.
I agree with the implicit ordering of marchers in caddy.
This holds in general, not only for this project in particular.
I'd MUCH rather a hobby web server be written in rust than C++ or C. I'm not touching the latter with a ten foot pole.
Memory-safe is nice compared to Nginx, but pretty moot when comparing to Caddy. OTOH, perhaps this could aim for better/comparable performance to Nginx (and better than Caddy) whilst being memory safe? It’s still quite a niche use case though.
From the main landing page. Possibly the benchmarks are slightly better, but until Nginx is added it’s hard to say how significant that bump is.
Why does the front page benchmark not include nginx?
2) Where's nginx in this graph? It feels very disingenuous. Esp when serving a default nginx page
- Since this is Hacker News, it's likely meant to showcase it to other Rust engineers, or attract contributors
- It signals that it is close to C/C++ speeds, but is more memory-safe than C/C++ servers
- It shows pride in being able to overcome the borrow checker, which can sometimes be difficult (Rust is more of a language + small formal proof of memory safety, than just a language)
For example, there's a popular Python app that used to take 1-2 seconds just to display the help message. It's a little better these days, and I'd use it anyway there's no alternative, but there's no way a Rust version of it would be that slow to start.