Cloudflare Makes Pingora Rust Framework Open-Source

[bacteriamanicure]

It is worse because it has a far worse syntax and the "unsafe" keyword (which should be the default in this particular case since you use it everywhere?).

I can't speak to the syntax because that's an opinion but what is not an opinion is that I have needed to use unsafe zero times. I don't need to explicitly write maybe unsafe code therefore I don't need to worry about accidentally writing maybe unsafe code.

The I-unsound label isn't exactly a "C feature parity" metric for two reasons:

1. LLVM Clang and GCC have unsoundness issues too... I just don't remember how to construct a URL to filter for the equivalent segments of their issue trackers. (i.e. It's not just a list of things that Rust has that the C compilers don't.) The class that show up in both Rust and C compilers are typically described as "miscompilations".
2. A lot of those are "In this edge case, the Rust compiler allows stuff that it should reject... stuff that C just accepts and says 'don't do that' in the language spec". (i.e. A lot of those are "Rust is X steps past C but we promised X+N steps" bugs to do with stuff that Rust promises to guarantee, while C promises best-effort catching of only if you use linter X or runtime sanitizer Y.)

It was a cheap jab whose premise was your second point. Rust fans (me) have one joke.

[jacob]

Blazingly 🔥 fast 🚀 memory vulnerabilities, written in 100% safe Rust. 🦀

https://github.com/Speykious/cve-rs

You realize that for all its tongue in cheek tone, this is actually an exploit of a known compiler bug (the "lifetime extension", documented and referenced in their source code), not a fundamental problem with the language. The chances of stumbling on it in real code are nil point nought because you need basically to build a multiple indirection where each indirection level has a different lifetime.

[jacob]

I checked it and there are 61 "unsafe" in the code.

This is NOT memory safe. It's a lie.
People should stop using that label this often. Just because something is written in Rust, doesn't make it memory safe. And this project is definitely NOT.

If you want memory safety, go to their github and open an issue and tell them to figure out how to do that without "unsafe".

Why don't you look at it then? It's used to call openssl through FFI, to deal with low-level libc APIs (file descriptors, GIDs etc.) and yes, they have the from_maybe_shared_unchecked hack to deliberately opt out of ensuring that HTTP headers are valid Unicode strings and treat them as raw byte buffers.

BTW unsafe Rust is still safer than C or C++.

[Volta]

Well thats a no true scotsman fallacy if I ever saw one.

Your not fooling anyone, just admit that no matter what software is written in Rust you will find some poor man's excuse to put it down.

I gave you example if you didn't notice. Another fanboy from rustacean's sect.

[Volta]

SurrealDB is however almost that level and it is already almost production grade (well it is stable for a while already) and is extremely rich in features..

Thanks, finally someone who has a clue. It seems they have to improve/implement few things for performance. Can't wait to see how it performs after that. Some fanboys may think I'm against Rust, but there are some questions I want to get answers for:

is it able to replace C? Many things needs to be taken into account: time to write the project, time to debug (Rust safety will probably be helpful here), ability/time to rewrite important parts of the large code base (I bet dealing with abstractions will be problematic?), state of dynamic linking. I wanted to see a large project, because even simple things in Rust are sometimes much more complicated:

use std::mem::{replace, swap};
impl<'a, T: 'a + Ord> AvlNode<T> {
fn rotate_right(&mut self) -> bool {
if self.left.is_none() {
return false;
}

// 1. Take nodes A and C
let left_node = self.left.as_mut().unwrap();
let left_right_tree = left_node.right.take();
let left_left_tree = left_node.left.take();

// 2. Link A node to left node
let mut new_right_tree = replace(&mut self.left, left_left_tree);
// 3. Swap B and D node value to avoid moving the root
swap(&mut self.value, &mut new_right_tree.as_mut().unwrap().value);
// 4. Take E node
let right_tree = self.right.take();

// 5. Link C and E nodes to swapped D node
let new_right_node = new_right_tree.as_mut().unwrap();
new_right_node.left = left_right_tree;
new_right_node.right = right_tree;
// 6. Link swapped D node to root right node
self.right = new_right_tree;

if let Some(node) = self.right.as_mut() {
node.update_height();
}

self.update_height();
true
}
}

C:

node * rotate_right(node *x)
{
node *y;
y=x->left;
x->left=y->right;
y->right=x;
x->ht=height(x);
y->ht=height(y);
return(y);
}

https://www.embedded.com/c-is-alive-and-well/

P.S. looking at the code syntax above, syntax is not an opinion. I wonder if its worth learning Rust and dealing with such syntax. I'd rather spent time on debugging and testing. However, time will show.

[ssokolow]

P.S. looking at the code syntax above, syntax is not an opinion. I wonder if its worth learning Rust and dealing with such syntax. I'd rather spent time on debugging and testing. However, time will show.

You're comparing apples and oranges. For example:

1. Your C code is missing an if (x.left == NULL) { return; } at the top.
2. Every .unwrap() in the Rust needs an assert() in the C to be even comparable.
3. Every .take() in the Rust needs an assignment of the source member to NULL in the C to guard against longjmp() rendering the inconsistent state observable.
4. std::mem::replace() in Rust is a single-expression shorthand for what would be a two-statement "copy the old value out and copy the new value in" dance in C.

TL;DR: The two pieces of code have different semantics. Your "simple" C code is simple because it's missing all the error-handling and "keep this consistent if an assert failure triggers stack unwinding" guards that are present in the Rust code. Of course it's going to be more compact if you're cutting it down like that.

...and, of course, Rust isn't a 1970s tinker-toy that requires you to reinvent basic data structures every time you start a new project. Writing correct data structures is actually more difficult than C makes it seem.

[mmstick]

I wanted to see a large project, because even simple things in Rust are sometimes much more complicated

This is a very poorly written adaptation to Rust. These are two entirely different implementations. Either the author is naive, or is misguiding you on purpose. Here's a doubly-linked list without any unsafe, reference counters, or unwraps.

https://github.com/orlp/slotmap/blob/master/examples/doubly_linked_list.rs

[Volta]

mmstick
ssokolow


Good points. It's not my code btw. Do you have any good source to learn Rust?

[marios]

Generally, people see it as "More reason to avoid C or C++, because I may want to be able to reuse what I've written when a future employer bids on a government contract".

Well, I would prefer getting fired to writing code for the US govt. We are not the same though, you might be fine working for genocidal warmongers and still enjoy a peaceful night sleep...

[marios]

You're comparing apples and oranges. For example:

1. Your C code is missing an if (x.left == NULL) { return; } at the top.
2. Every .unwrap() in the Rust needs an assert() in the C to be even comparable.
3. Every .take() in the Rust needs an assignment of the source member to NULL in the C to guard against longjmp() rendering the inconsistent state observable.
4. std::mem::replace() in Rust is a single-expression shorthand for what would be a two-statement "copy the old value out and copy the new value in" dance in C.

TL;DR: The two pieces of code have different semantics. Your "simple" C code is simple because it's missing all the error-handling and "keep this consistent if an assert failure triggers stack unwinding" guards that are present in the Rust code. Of course it's going to be more compact if you're cutting it down like that.

...and, of course, Rust isn't a 1970s tinker-toy that requires you to reinvent basic data structures every time you start a new project. Writing correct data structures is actually more difficult than C makes it seem.

I cannot answer because the checks needed differ based on the implementation and the context in which the function is used. For example if you know the node argument is guaranteed by the caller to be valid, no checks are needed. If you know by the implementation that the x->left and x->right are not NULL, the only check needed is if(x == NULL) return NULL;

About the meaning of the Rust statements provided, I have no idea what it does, since I don't now Rust. What I understand from what you said, is that it can do more stuff than a simple C equivalent. Even if it is true (it most likely is), is the extra stuff needed? I claim, usually no.

Finally, about your assert() claim, you should know that it should only be used for debugging. If you compile your code for release, you should define NDEBUG, which NOPs all the assert().