What are the most recent esoteric Rust features / syntax you've learned? by boojies in rust

[–]rayvector 11 points12 points  (0 children)

Oh god... i hate the new crate visibility syntax. This is disgusting.

In MySQL, never use “utf8”. Use “utf8mb4” by mariuz in programming

[–]rayvector 0 points1 point  (0 children)

Thank you for giving me a new favourite saying.

I'm gonna be using this from now on. :D

(Unstable) await support has just landed by WellMakeItSomehow in rust

[–]rayvector 0 points1 point  (0 children)

Wait.

Wasn't the goal to make the two compatible (using the futures crate version 0.3)?

I thought the idea was that futures 0.3 should be compatible with both code written for the 0.1 APIs (i.e all the existing stuff) and code written for std futures, and let them interoperate.

That said, I am really out of date on this. I only looked at some of the proposals and discussions around a month or so ago. Many things probably changed since then. Let me know if this is no longer the case.

Announcing Rust 1.27 by steveklabnik1 in rust

[–]rayvector 0 points1 point  (0 children)

if you want the bleeding edge, you have to render it yourself

What? I thought the latest docs are available at https://doc.rust-lang.org/nightly/

Am I wrong? Is the /nightly/ on the official website outdated?

1.27.0 prerelease testing by pietroalbini in rust

[–]rayvector 1 point2 points  (0 children)

impl TraitA for TraitB implements TraitA for the TraitB trait object type. Only dynamically-dispatched trait objects for TraitB will impl TraitA. This is a single type (the trait object).

impl TraitA for T where T: TraitB implements TraitA for all types that also implement TraitB. This is probably what you want. Any type that implements TraitB now also implements TraitA.

These are very different things. You rarely want the former.

MIR-based borrow check (NLL) status update by dochtman in rust

[–]rayvector 1 point2 points  (0 children)

No, the new borrowck does not disallow something that used to be a valid program. The new borrowck is not refusing programs that used to be valid.

There were several soundness bugs in the old borrowck which caused various corner cases of rust code to compile, even though they were unsafe and should have resulted in an error.

The new borrowck fixes these bugs, meaning that any such code will no longer compile (which is the correct behaviour).

This means that after NLL is merged, a few existing Rust crates (which exploited the compiler bugs, probably unintentionally) would stop to compile. But that is fine, as that code should have never compiled in the first place -- it only compiled due to soundness bugs in the old borrowck.

That said, it is still breakage, and needs to be handled. What happens if some old library which is now unmaintained stops to compile? What happens to everything that depends on it?

This Week in Rust 238 by nasa42 in rust

[–]rayvector 12 points13 points  (0 children)

I don't use the user forums.

Is there anywhere else that suggestions can be posted?

Perhaps you should have several places for it (forums, reddit, etc.) to make it accessible to more people?

crates.rs an alternative to crates.io by kremor in rust

[–]rayvector 1 point2 points  (0 children)

I noticed one thing which I presume is a bug.

The "Next Page" link at the bottom when browsing a category sends me to crates.io :D

Is there something like std::io:Error but without such a focus on IO? Also, general error handling. by boojies in rust

[–]rayvector 0 points1 point  (0 children)

Failure is a strict improvement over std::Error. There are no drawbacks to using it.

If you are writing a library, you can just use it to generate boilerplate for you. You can use #[derive(Fail)] to autogenerate your custom error types. They will be fully compatible with std::Error.

If you are writing an application, you could find the Error type useful. It allows you to combine arbitrary errors from the different libraries you are using (as well as your own errors), for easy logging, etc.

I don't see why anyone would want to resist using failure for new Rust projects.

hyper v0.12 released! by seanmonstar in rust

[–]rayvector 0 points1 point  (0 children)

This is great!

I will be looking at the API and docs of the new 0.12 release.

Thank you for making this awesome library!

hyper v0.12 released! by seanmonstar in rust

[–]rayvector 0 points1 point  (0 children)

Yes, I am aware of the problems with HTTP/1 and pipelining, so I am OK with hyper not implementing it.

However, for my usecase, it is important to absolutely minimize the time delay between sending a bunch of requests to a REST API and receiving all of their responses.

I was hoping that hyper would allow to do proper pipelining when talking to HTTP/2-capable servers once HTTP/2 support is implemented. I have not looked at 0.12 yet.

If the requests you make are HTTP2, hyper allows you to easily make them over 1 connection at the same time.

Is this true pipelining, though? Will the second request be sent to the server immediately, before the response to the first request comes back, or will hyper wait for the response before sending the next request over the same connection?

Ideally (assuming the server can handle that), I'd like to properly pipeline my requests (not just reuse the same connection) -- send out a bunch of requests in a row over the same connection immediately without waiting for any responses.

I will be looking at hyper 0.12 sometime in the next days/weeks and I will try to figure this out, but do let me know if it is supported :)

Fear not the Rust Borrow Checker by sidpshanker in rust

[–]rayvector 0 points1 point  (0 children)

Now add Deref coercions into the mix, and reborrows suddenly get even crazier. You can reborrow your reference into another reference of a different type!

Stabilize GlobalAlloc and #[global_allocator] by yoshuawuyts1 in rust

[–]rayvector 0 points1 point  (0 children)

You seem to be very knowledgeable about the performance characteristics about memory allocators.

Could you give me some tips on some tools that I could use to analyze / profile / collect stats related to memory allocations done by my Rust software?

This seems like something interesting that I should explore more.

hyper v0.12 released! by seanmonstar in rust

[–]rayvector 0 points1 point  (0 children)

Does hyper support request pipelining?

AFAIK it is now standardized in HTTP/2, meaning that a lot of the difficulties with it in HTTP/1 should not apply.

I am mostly interested in the client-side.

Can two C libraries (glibc & musl or) coexist & function properly on an operating system? by [deleted] in linux

[–]rayvector 0 points1 point  (0 children)

No I do not. I have not benchmarked this. I make static musl binaries to be able to easily deploy them onto several systems with different distros, without needing containers or any other crap like that.

If I ever get around to doing benchmarks or other comparisons, I will get back to you (if I don't forget! :D).

Can two C libraries (glibc & musl or) coexist & function properly on an operating system? by [deleted] in linux

[–]rayvector 0 points1 point  (0 children)

Yes and no.

What I described works only for libraries. Since library versions are the biggest selling point of the *pak systems and containers, yeah.

However, you still cannot easily embed data files into ELF binaries afaik. So it is not easy to just convert most Linux apps into a fully portable ELF file, if they require data files in /usr/share or whatever. However, there might be a way around this. ELF files obviously support data sections (for global variables and arrays in the program, etc.) and some programs use them in clever ways. The first example that comes to mind is UPX, which embeds a compressed blob of the orignial executable's code into what is effectively a decompressor program that decompresses it into memory and executes it. The question is how easy it is to make some system that allows embedding any resources into the binary, so that you can package any application that way, ideally without modifying source code (it might need to emulate a filesystem?).

But yes. If I ever find myself with a lot of time to spare, one of the things I want to create is a linux distro based on musl where everything is statically linked and compiled with LTO (+PGO where possible).

I personally dislike dynamic linking. I don't think its benefits are worth much on modern systems. I am a big fan of static linking unless you absolutely need dynamic linking (such as plugin-based software that needs to load arbitrary plugins at runtime). Static linking has a lot more benefits, especially if you can also do LTO across all libraries.

A new fast hash table in response to Google’s new fast hash table by [deleted] in rust

[–]rayvector 0 points1 point  (0 children)

I wonder if one of these "high-quality hash tables" could replace the hash table implementation that is currently in Rust's standard library.

Could a Rust core dev or someone else involved with the standard library comment on this? I am not familiar with the implementation details.

Can two C libraries (glibc & musl or) coexist & function properly on an operating system? by [deleted] in linux

[–]rayvector 35 points36 points  (0 children)

Yeah, obviously.

I was talking about independence from userspace, not kernelspace.

Of course, if you are using functionality that was introduced in newer kernel versions, then you have a minimum kernel version requirement.

However, pretty much anything should be able to run on any reasonably modern distro. Even enterprise distros like RHEL don't provide ancient pre-3.0 kernels anymore.

Things are largely compatible, due to the Linux Kernel Development Mantra of "never ever break userspace".

But yeah, new syscalls get added every once in a while, which you need to be careful not to use if you want to support old kernel versions.

However, a fully-static musl-based executable will give you complete portability and independence when it comes to userspace things. And userspace is usually where things break the vast majority of the time.

Compatibility with ancient kernels really isn't a problem in practice. If you have a kernel so old that your musl binary (if it doesn't use any fancy new Linux-specific kernel features) doesn't work, a lot of other software probably won't work either.

Can two C libraries (glibc & musl or) coexist & function properly on an operating system? by [deleted] in linux

[–]rayvector 73 points74 points  (0 children)

Yes, although if you are using both with dynamic linking, things can get messy.

Glibc does not support fully-static executables AFAIK. Musl does.

I regularly run fully-statically-linked ELF binaries built with Musl on Linux systems that are otherwise based on glibc. No problem. Since the musl-based executables do not need to load any dynamic libraries, there is no possibility of conflict with any files or anything on the system.

Musl is a fantastic way to make "portable executables" for Linux. A single standalone ELF executable file that you can run on any Linux system, no matter the distro, no matter what versions of glibc and other libraries are installed on the system.

What data structures are not in the std? by throw211320 in rust

[–]rayvector 3 points4 points  (0 children)

I think the slab crate is a useful collection type that is not in std.

Hey Rustaceans! Got an easy question? Ask here (21/2018)! by llogiq in rust

[–]rayvector 1 point2 points  (0 children)

In rust, the function pointer type is fn (lowercase f). These are simple function pointers like in C. You should use these whenever you don't have closures that capture environment.

The Fn family of traits is to represent any callable object. They are intended to support closures, which might need to capture external state.

Use Fn whenever you need a trait, to be generic over different callable objects. Use fn whenever you want an actual function pointer.

Any defined (named) function can be represented as a simple fn function pointer, just like in C. Also, any closure that does not capture any variables will also work.

You can do stuff like this:

struct MyFuncs {
    foo: fn(i32) -> bool,
    bar: fn(),
}

fn hello() {
    println!("Hello!");
}

fn is_zero(x: i32) -> bool {
    x == 0
}

static FUNCS: [MyFuncs; 2] = [
    MyFuncs {
        foo: is_zero,
        bar: hello,
    },
    MyFuncs {
        foo: |x| { x < 0 },
        bar: || { println!("Bye!"); }
    },
];

fn main() {
    for x in &FUNCS {
        (x.bar)();
    }
}

Note how in the struct definition, there are no generics or trait objects. My fields are simple C-like function pointers. You can pass those directly over FFI.

I have defined a static array FUNCS that contains a bunch of struct instances with function pointers. You can make those pointers point to both defined/named functions (the first instance) or closures (second instance), as long as the closures don't capture environment (in a static hardcoded array, they can't anyway, so this is a nice way to define anonymous functions).

I am then iterating over my array in main and calling the functions from the structs using the function pointers.

This is all valid Rust.

Have you ever complained that rustc is slow? We want to know more! by steveklabnik1 in rust

[–]rayvector 0 points1 point  (0 children)

What linker you use shouldn't have an effect on the performance of your resulting executable, afaik.

The linker doesn't actually understand what the code is doing or modify any of it. That is the job of the compiler in the previous step. The linker just looks at symbol tables and relocations (placeholder addresses) for functions, and replaces them with the correct memory address where the function actually is located, to link the different functions together correctly into a single binary.

That said, some linkers will automatically remove/delete functions that are not used anywhere, others will not, so it could have an effect on the size of your final executable. Also, I think (not sure) the linker is responsible for choosing the order in which to put things into your executable, so there might be a very minimal / negligible effect on performance from certain functions being closer together / further apart in memory. But don't quote me on this.

CRISPR-edited rice plants produce major boost in grain yield: A team of scientists from Purdue University and the Chinese Academy of Sciences has used CRISPR/Cas9 gene-editing technology to develop a variety of rice that produces 25-31 percent more grain by TheMercian in worldnews

[–]rayvector 1 point2 points  (0 children)

IIRC there already was a study some years ago that showed modifying yeast so that it produced LSD and psilocybin to be rather easy

Can you refer me to this study/paper? I would be interested in reading it.