frawk VS rust

It does, just go to the "Benchmarks" link: https://github.com/ezrosent/frawk/blob/master/info/performan...

and frawk for good measure

frawk ["frawk" in aur] - a fancier awk with support for CSV files

https://github.com/ezrosent/frawk - awk like language in rust

Frawk: A fast, JITted, statically-typed AWK written in Rust\ (27 comments)

Interesting (and a bit surprising) that the cranelift backend keeps up with LLVM backend reasonably well, especially with parallelism enabled https://github.com/ezrosent/frawk/blob/master/info/performan...

In the example I noticed a PREPARE block in addition to the well known BEGIN and END blocks. After a few minutes of searching it appears to be frawk specific:

https://github.com/ezrosent/frawk/blob/master/info/paralleli...

"Because the repeated map references are both annoying to write and inefficient to execute, frawk has a PREPARE block which executes in the worker threads at the end of its input"

You may find the discussion on issue #53639 (Consider deprecation of UB-happy static mut) from about this point onwards to be illuminating. Specifically, the topic of ISRs and synchronisation on embedded systems is discussed, with alternatives, and it's stated that UnsafeCell is so fundamental that any non-zero-cost to it is considered a bug in the compiler:

That's why MutexGuard is not Send. See https://github.com/rust-lang/rust/issues/23465 from 2015.

There is a tracking issue to implement a lint for this in the compiler: https://github.com/rust-lang/rust/issues/83310

We're already implementing such a Callable trait in https://github.com/rust-lang/rust/pull/107123

Rust's approach is more inline with their philosophy of "taking as long as necessary to do it properly". (eg. linking with LLD is still a work in progress but it will improve LLD for everything LLD-based. rustc_codegen_gcc may not be as much of an independent implementation as gccrs, but the project is getting patches into libgccjit's AOT compilation API to improve it for everyone.)

Also, I'm waiting for the cg_clif rustup support to have a better idea of how to do this.

collect_into() is behind unstable feature iter_collect_into. It just calls extend() on the collection if you want the same behaviour on stable.

Rust is a relatively new programming language suitable for various software engineering challenges. People use Rust for low-level system engineering tasks but also to build high-level stuff, like web applications. From the Memgraph perspective, C/C++ is great but required deep knowledge about memory allocation and a lot of time to get the module implemented correctly. On the other hand, Python is excellent for prototyping stuff and shipping new capabilities with lightning speed, but performance is often a considerable bottleneck.

A very specific case on admittedly a toy project.

I was working on a card game simulator and I had a Vec of players. I needed to pull two players from that Vec and the first player would give a card to the second player. In my head I would grab both players via get_mut and then perform my operation. However, get_mut borrows the vec mutable and the compiler complained that I borrowed the Vec mutably two times.

It took me a bit to understand why the compiler complained, but then it clicked: It couldn't prove that get_mut wasn't returning the same item both times.

There were a few solutions. One was to borrow the first player, take a card, drop the &mut and then take the second player. At some point in the future I could use https://github.com/rust-lang/rust/issues/104642 to get_many_mut. I ended up with a pretty inefficient version of get_many_mut that fully traversed my iterator to get the two mut references (which works because traversing the iterator guarantees you won't see the same element twice) and it was fine for a collection of a half dozen players.

Anyway, there's a little example.

Anyway, it was a small thing but

> The language has no special support for them (beyond the try operator)

In the interest of full and strict accuracy: see the enum’s full definition at https://github.com/rust-lang/rust/blob/d610b0c514b9ccb0dad5d.... There are a few points of specialness about Option that you can’t use elsewhere:

• #[rustc_diagnostic_item = "Option"]: the compiler knows about Option for the purpose of improving its error messages. I’m not sure how this is used, and am not looking it up now.

• #[lang = "None"] and #[lang = "Some"]: lang items allow the compiler to hook things up, like knowing the + operator maps to the core::ops::Add trait. https://github.com/search?q=repo%3Arust-lang%2Frust+%28optio... suggests that these lang items are only being used by Clippy, to provide better diagnostics. So if you use your own Option type, you won’t get Clippy lints related to Option.

• I guess there are also the #[stable] attributes, which can’t be used outside the standard library. When talking about strict accuracy, I guess that counts!

Anyway: for practical purposes this is just minor diagnostics and documentation stuff, not actual functionality, about which there is nothing special.

Since you mentioned the try operator, might as well look at the trait implementations on Option too, https://doc.rust-lang.org/std/option/enum.Option.html#trait-.... There are a few things marked “This is a nightly-only experimental API.”, which you can implement yourself if you’re willing to take that stability risk; they’re all linked to try_trait_v2, which is what backs the try operator, `?`. Once it, or its successor, is stabilised, we’ll effectively be back to there being absolutely nothing special about Option, as you’ll be able to implement those traits for your own Option type as well.