There are also a lot of Rust haters, and people unwilling to change.
From the Cloudflare blog:
>> We chose Rust as the language of the project because it can do what C can do in a memory safe way without compromising performance.
So in their opinion language choice matters. I'm not a Rust hipster, but I do believe in the promises the language makes. Assuming they didn't write any unsafe Rust it's pretty much assured that the new proxy contains ZERO bugs of certain types. See what I did there? I made a (contingent) assertion about the non-existence for entire classes of bugs in a code-base I have not seen, based on the language it is written in. So from that point of view Language does matter.
Look at the original title:
"How we built Pingora, the proxy that connects Cloudflare to the Internet"
And look what's being reported "rust-written", it's not the case with any other languages, and that's why some people are against it, because fanboyism takes over rational decisions
Nobody mention the language for the countless new AI/ML based projects
It didn't seem to hurt the language much.
People who’ve been here a while remember when “written in Go” was appended to everything. When “we decided to rewrite X in Go” would show up every other week. The new thing is going to get attention from people who haven’t used it but are interested.
In a few years we’ll have new accounts complaining that there are too many articles about Carbon or whatever is new then.
Go's approach to massive parallelism, Erlang and the supervisor/actor model, Rust and it's borrow-checker. These are all milestones in programming language development. There's a reason for the hype.
So someone saying “oh $language is great, it worked really well for me” is clearly upsetting you. I thought “$vaccine has boosted my chances of survival with minimal side effects” might have upset you as well.
Having "written in Rust" needlessly slapped on to HN, reddit, and other content farm post titles doesn't make me feel like I'm being forced to learn it. It gives the Rust community more of a MLM vibe with the need of the hype crew to talk it up to validate their decision to use it and they're trying to sell me something.
[1] https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...
I’m sorry you feel that way. You shouldn’t feel like you’re being forced to learn anything.
That said the MLM interpretation is the least charitable one possible. A bunch of people excited about a new technology need not have malicious intent when they’re taking about it. Maybe they’re just excited.
Again I request, please don’t assume that mistakes happen out of malice. There was no deceit in what I did.
Suppose I made this mistake on purpose. What advantage could I possibly have gotten from it? Nothing. My only purpose here was to have a discussion in good faith.
If you’re going into conversations assuming bad faith and deceit and ulterior motives of strangers, don’t be surprised if your biases are confirmed.
Agreed, which is why I explicitly stated that I don't feel like I'm being forced to learn it. You might be making the wrong assumption given the other person's blatantly deceitful replies.
Posts that are editorialized, shilling, ad/spam, or any of the other class of HN doesn't want you to do that type of posts, regardless of if it's about Rust should have the community call it out in comments.
To be clear, I don't hate the Rust language. It has a few features that I find appealing and there are posts about Rust that I feel worth worth the read. The cult like evangelizing and editorializing is what I dislike and makes some, including me, not want to engage with Rust's community.
Strange decision-making strategy, indeed.
It's a phase.
"Written in Rust"
"I use Arch btw"
"Googler. Opinions are my own."
And I'm pretty sure Haskell had a situation like this a while ago.
This too shall pass.
When commenting employer this is legally responsible and also a disclosure of your biases.
I just have to learn now not to look in the comment section, which is not only off-topic but actually arguing why even this topic exists.
Language choice can influence how fast or slow you get there, and also the level of certainty you have. Again, Rust guarantees certain bugs and race conditions do not exist, so in a sense we START from there and never have to worry about "getting there".
You’re begging the question.
And assuming that the libraries you depend on also don't have any `unsafe` bugs. This is something people seem to forget when discussing rust. And "the unsafe is well tested" sounds similar to "this legacy C code is well tested". I like rust the language but have consistently negative experiences with evangelists.
Here are some other things that make rust a good choice for developing low level systems:
- Zero cost abstractions like in C++
- A strong type system (and lifetime annotations built into the language, less need for the grind tools)
- In general a stricter language than C++ with far less legacy options
- Newer language with a de facto package manager and build system
There's a lot to like about rust without just saying it's "safer" which is highly nuanced and people seemingly never actually go into the details. I've had many negative votes for even suggesting than C is currently a better choice for Linux Kernel development compared to Rust. People will just say "Rust is safer" and that's the end of the conversation...
The safety is also conditional on rustc not having bugs, and your computer working correctly. But you don't get to pretend those are as risky as some large random, less used C code.
I mean the guy used clojure, a functional lispy language with emphasis on immutability. It's as "change embracing" as it gets in webdev when phrases like LAMP stack, MEAN stack are the norm.
For example, I worked with one CDN company where the engineers decided that injecting random NULL bytes into the TCP stream of an HTTP request was perfectly valid. They obviously are in fact idiots.
This is similar to how AWS can always claim 5-9s of uptime. They decide what counts as downtime. Even when large portions of us-east-1 are broken, they have 5-9s of uptime.
One time I got back a response to an http request that I could just not parse. It rendered fine in my text editor, but the code I was trying to parse it with was returning a nonsensical error. Fortunately (?) I had the response saved to a file, so I didn't have to keep hitting the server as I tried to figure out how to parse it.
Eventually I broke out a hex editor, and realized something had inserted a null byte in between every other byte of text. Unfortunately I couldn't get the server (third party) to reproduce this behavior.
I believe it was a nearly entirely ascii CSV file, and I might not have checked any non-ascii characters to see how the pattern held.
You definitely won't be the first person who got given UTF-16 and went "Ah, some fool added NUL bytes in between all my ASCII", I worked with a really excellent colleague, Cezary, a decade or more ago who made exactly this mistake on some data we were receiving.
Of course having never seen it I also can't rule out the documentation just being wrong.
Purely speculating here, but I imagine Nginx's choice to split across worker processes (with separate pools) instead of threads (with shared pools) had to do with a) avoiding memory errors due to sharing resources, b) reducing extra (defensive) locks, and/or c) reducing the blast-radius of crashes
All of which Rust helped the team not to have to worry about, enabling more sharing of resources, which solved their main bottleneck
Of course the OP's JVM solution would be memory-safe too (helping with (a)), but then that comes with other costs
Remember Cloudbleed? That was caused by a memory safety issue in a parser written in C++.
re: jvm -- you may be able to get that sort of throughput, but I also have to wonder what the latency distribution looks like, and how much control you wind up having over it. Yielding control to a GC in a latency sensitive application isn't an easy give.
I remember that.
Sometimes people being vocal about something being good is because it really is good. The iPhone was definitely like that. Rust is too. I would imagine the "it's just Rust hipsters" comments will die out in a few years when Rust is more popular than C++.
Most of your comment is substantive, but your opening sabotages meaningful discussion. HN guidelines:
> Be kind. Don't be snarky. Please don't sneer, including at the rest of the community.
> please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
> Eschew flamebait. Avoid unrelated controversies, generic tangents, and internet tropes.
Yeah, this is always the big takeaway in this sort of story — Really good general purpose solutions can often be outperformed by much simpler special-purpose implementations.
The thing I'm interested in from the article is what they did to replace their lua runtime. It was used for request processing and WAF rules. Is it now baked directly into Rust? If a new WAF rule comes out do they have to recompile their entire proxy? The dynamic nature of Lua and Nginx was very powerful - I wonder how they changed that or what they replaced it with.
They engaged in a rewrite, and they chose a modern language. These are orthogonal.
Even in academia, one sees a prevailing view that language choice is picking a brand of toilet seat. Others see language as one of the central questions of our evolving identity as a species. There are those in the middle, just trying to get work done, considering their language choices but not seeing that as fashion.
"hipsters" certainly tips one's hand.
I'm not a Rust user, but this is clearly false. Proof: an implementation of any large program will be faster, less buggy, more maintainable, and take less total development time in C than in assembly. Therefore, language choice does matter.
Now, that isn't to say that Rust is uniquely better than any other language out there (which I strongly believe that it's not), just that language design differences do translate into meaningful changes in the trade-space between correctness, performance, and development cost, and that's something you should be aware of even if BrainF fulfills all of your engineering constraints easily.
If you're being literal: I doubt you'd get much mileage out of (pure) Python.
> Clojure ... used ~4x fewer resources and managed to pass through 3-4x more traffic
Impressive. What was the use case, or what did it do differently than nginx, if I may ask?
That and have the architecture that fits exactly your need.
From the blog post:
> Since Pingora's inception we’ve served a few hundred trillion requests and have yet to crash due to our service code.
That would be hard to achieve in C or C++.
It sits in a corner collecting dust and reminding me of the fun times my pops and I built stuff together because I bought a saw-stop. Sure i could probably spend the next 2-3 decades safely using the old saw and never hurting myself - but why? I like my hands and fingers attached to my body - being careful will probably keep them in that state, but when I have stronger guarantees from the new gear, I'll use that instead - and recommend the same to others.
Netflix is serving TB/sec using Nginx just fine.