Should i use the rust driver for surrealDB or is using the REST api viable.
Asking this since the rust driver has 2x the dependencies that one of my actix-web + diesel projecets have and the comptime is less than pleasant.
The rust driver seems to be in a very early stage so i just feel like implementing some helper functions for the REST api might be better, since i assume that it just returns JSO N (i think but correct me if am wrong) i could just use Serde to make stuff easier.
I work under Win 10 x64 and had several problems with the rust driver dependecies. So I wrote a lib which provides me all the Surreal functionality and uses the Surreal Api. I only use reqwest = "0.11.13" & anyhow="1" inside my Lib.
For the evaluation in my projects i use serde_json = "1.0.91".
Related
So i just started using rust, and started using the bellman crate.
I used the MimC example that was added to the bellman git account, and it seems like its calculating the parameters for the circuit each time you run the example. I want to use the example as a base for my code, and it seems redundant to calculate it each time for the same circuit so I waned to try and write params to the disk, and to check each time whether it exists or not for a specific circuit (so if it was already calculated, it will read it instead of calculating it).
Assuming params is a structure, I tried using serde and serde_json. but I keep on getting the following error:
^^^^^^^ the trait serde::ser::Serialize is not implemented for bellman::groth16::Parameters<pairing::bls12_381::Bls12>
any thoughts about how can I write it and read it later efficently?
thanks!
serde has a Serialize/Deserialize traits which should be derived/implemented in the crate where the types are defined. So usually it's a good idea to look at Cargo.toml (or documentation) for serde features, it's a pretty common practice to have it (and sometimes you need manually enable them). For the bellman crate however that doesn't seem to be implemented, so you need to workaround for "external" type (explanation). Serde particularly has a fairly good support of that, take a look at their doc. Simply, you need to provide a newtype to #[serde(with = "<here-your-newtype>")], which mimics the original one.
I'm currently in the progress of learning Rust. I'm mainly using The Rust Programming Language book and this nice reference which relates Rust features/syntax to C++ equivalents.
I'm having a hard time understanding where the core language stops and the standard library starts. I've encountered a lot of operators and/or traits which seems to have a special relationship with the compiler. For example, Rust has a trait (which from what I understand is like an interface) called Deref which let's a type implementing it be de-referenced using the * operator:
fn main() {
let x = 5;
let y = Box::new(x);
assert_eq!(5, x);
assert_eq!(5, *y);
}
Another example is the ? operator, which seems to depend on the Result and Option types.
Can code that uses those operators can be compiled without the standard library? And if not, what parts of the Rust language are depending on the standard library? Is it even possible to compile any Rust code without it?
The Rust standard library is in fact separated into three distinct crates:
core, which is the glue between the language and the standard library. All types, traits and functions required by the language are found in this crate. This includes operator traits (found in core::ops), the Future trait (used by async fn), and compiler intrinsics. The core crate does not have any dependencies, so you can always use it.
alloc, which contains types and traits related to or requiring dynamic memory allocation. This includes dynamically allocated types such as Box<T>, Vec<T> and String.
std, which contains the whole standard library, including things from core and alloc but also things with further requirements, such as file system access, networking, etc.
If your environment does not provide the functionality required by the std crate, you can choose to compile without it. If your environment also does not provide dynamic memory allocation, you can choose to compile without the alloc crate as well. This option is useful for targets such as embedded systems or writing operating systems, where you usually won't have all of the things that the standard library usually requires.
You can use the #![no_std] attribute in the root of your crate to tell the compiler to compile without the standard library (only core). Many libraries also usually support "no-std" compilation (e.g. base64 and futures), where functionality may be restricted but it will work when compiling without the std crate.
DISCLAIMER: This is likely not the answer you're looking for. Consider reading the other answers about no_std, if you're trying to solve a problem. I suggest you only read on, if you're interested in trivia about the inner workings of Rust.
If you really want full control over the environment you use, it is possible to use Rust without the core library using the no_core attribute.
If you decide to do so, you will run into some problems, because the compiler is integrated with some items defined in core.
This integration works by applying the #[lang = "..."] attribute to those items, making them so called "lang items".
If you use no_core, you'll have to define your own lang items for the parts of the language you'll actually use.
For more information I suggest the following blog posts, which go into more detail on the topic of lang items and no_core:
Rust Tidbits: What Is a Lang Item?
Oxidizing the technical interview
So yes, in theory it is possible to run Rust code without any sort of standard library and supplied types, but only if you then supply the required types yourself.
Also this is not stable and will likely never be stabilized and it is generally not a recommended way of using Rust.
When you're not using std, you rely on core, which is a subset of the std library which is always (?) available. This is what's called a no_std environment, which is commonly used for some types of "embedded" programming. You can find more about no_std in the Rust Embedded book, including some guidance on how to get started with no_std programming.
The API for reading scalar values seems to have been removed from the Cursor and Reader io traits. Is there a standard library replacement for these or do I have to write my own?
For example, it used to be possible to write:
let magic = try!(reader.read_be_u16());
This functionality is not in the standard library any more, but there are other libraries providing it.
byteorder is a popular one.
This is the serialize crate, and this is the rustc-serialize crate.
I'm getting deprecation warnings from the compiler when using the Encodable and Decodable traits from the serialize crate. The compiler tells me to use RustcEncodable and RustcDecodable from the rustc-serialize crate.
It seems like this just makes things less readable for the same functionality (apart from base64 encoding provided in rustc-serialize). What's the difference between these crates?
The serialize crate is an internal part of the standard Rust distribution. It won't be available in the Rust 1.0 stable/beta channels.
The rustc-serialize crate used to be serialize, but it was moved out to a separate repository and uploaded to crates.io so that it can evolve on its own.
This was done because the utility of rustc-serialize is enormous but it was not realistic to get it stabilized in time for Rust 1.0. Since the Rust distribution will prohibit unstable features on the stable channel, the only way to continue using the serialization infrastructure is to 1) stabilize what we have or 2) move it to crates.io, where the unstable restrictions don't apply.
rustc-serialize has a lot of known downsides, and it is being worked on, so stabilizing what was there really isn't an option.
But the Decodable/Encodable features require compiler support (because compiler plugins won't be stable either for Rust 1.0). As a stopgap measure, RustcDecodable/RustcEncodable were invented as a temporary measure for the rustc-serialize crate to use explicitly. It's a bit weird, but it leaves the Decodable/Encodable names available for a future backwards-compatible version of a serialize crate that is better than what we have now (perhaps this is what serde2 will become from the aforementioned link).
So for the time being, stick to use rustc-serialize and RustcDecodable/RustcEncodable.
(I apologize that I can't come up with a link to cite all of this. It's knowledge I've accrued over time from GitHub issues. Maybe there is an RFC that lays all of this out though. I can't remember.)
To expand on BurntSushi5's answer, as of the time of this writing, the Rust compiler in both Stable and Beta channels throws the following error when attempting to use vanilla serialize:
error: use of unstable library feature 'rustc_private': deprecated in favor of rustc-serialize on crates.io (see issue #27812)
--> src/main.rs:2:1
|
2 | extern crate serialize;
| ^^^^^^^^^^^^^^^^^^^^^^^
The linked Github issue is not very helpful. In short, use rustc-serialize.
I see that before Rust 1.0, there used to be functions like std::mem::from_be16 as well as core::mem::from_be16. The documentation for both modules claims that all of the byte swapping routines are deprecated, and indeed they were removed for Rust 1.0.
Is there anything built into Rust which can do the swap and is not deprecated or would I have to implement my own?
You want to use methods like i32::from_be.
For future reference if you run code with deprecated functions the recommended replacement should be shown by the compiler or alternatively view the source code of the function which should have something like this
#[deprecated = "use `i32::from_be` instead"]
Methods like u16::swap_bytes sound more relevant to the wording of the question.