These are chat archives for rust-lang/rust

13th
Nov 2017
Michael Sloan
@mgsloan
Nov 13 2017 03:59
@matklad What languages are you comparing to? To me rust seems to build things quite quickly
Michael Sloan
@mgsloan
Nov 13 2017 04:08
I am typically using GHC, though. Compile times for large projects are definitely annoying. However, interactive development is actually pretty good, the interpreter for the REPL is quite fast, particularly because it still uses the compiled versions of all the dependencies
Aleksey Kladov
@matklad
Nov 13 2017 07:14
@mgsloan I've worked a lot with Python and Kotlin, and there dev cycle is quicker.
Michael Sloan
@mgsloan
Nov 13 2017 07:15
I see, well that certainly makes sense, because python is an interpreted language and the JVM uses JIT, so it's effectively interpreted as well
So comparing it to the full code generation and linking that rust is doing is a bit apples 'n oranges
Rust should probably have an interpreter that "just works" to load up your project, though. I haven't tried rusti, though, maybe it's good enough
Aleksey Kladov
@matklad
Nov 13 2017 07:17
Yep, but turnaround time is one reason why I might pick JVM over C++/Rust :)
Michael Sloan
@mgsloan
Nov 13 2017 07:23
Certainly true
Sander Maijers
@sanmai-NL
Nov 13 2017 10:15
Hi all, a question
Hmm, I find the new Rust Reference a bit hard to navigate, alas ..
Sander Maijers
@sanmai-NL
Nov 13 2017 10:21
What is the cost (1) of constructing a struct with fields that are references, and calling an inherent method on it that reads all those fields and constructs a new value based on that vs.
(2) calling a function that takes all the references directly and constructs a new value based on that?
Suppose the number of fields in more than say 16
If there is some material I can read on this that would be great. I know I can try to benchmark but I would like to learn some general background first
Note, for the new value the code will have to clone the struct fields/in-parameters eventually.
red75prime
@red75prime
Nov 13 2017 10:30
No difference at all, probably. In one case parameters are in contiguous block of memory (structure), in other case parameters are in contiguous block of memory (stack).
Sander Maijers
@sanmai-NL
Nov 13 2017 10:31
Alright. I'm creating a benchmark for it to confirm..
Aleksey Kladov
@matklad
Nov 13 2017 10:32
Another metric to look at is stack usage: I expect the first variant would be more efficient here (If the function is not inlined and recursive)
For programmers sanity, I think having 16 parameters is also suboptimal :)
Sander Maijers
@sanmai-NL
Nov 13 2017 10:33
The thing is, the same struct will be reinitialized on every call to the inherent method f', since a small number of fields will have to be updated across calls, whereas only the corresponding in-parameters would change if I supply them directly to the function f.
@matklad: interesting, what makes you think the stack usage would be lower?
I suppose I could mutate struct fields instead of using the functional update syntax, to prevent the unchanged fields from being copied too?
BTW, if the struct contains 16 references then a corresponding function signature actually looks friendlier due to all the lifetime params :P
Sander Maijers
@sanmai-NL
Nov 13 2017 11:14
I ran a benchmark, it seems the functional record update has very little impact. :)
John-John Tedro
@udoprog
Nov 13 2017 12:00
Could I get someones take on this: https://github.com/rust-lang/rust/blob/master/src/librustc_data_structures/fx.rs#L20 - My first impression is that it seems a bit brittle and and relies on some overloading behavior with type aliases. But, it's a convenient way to define a constructor that is imported with the aliased type when it otherwise wouldn't be possible.
Using a newtype would be annoying because there's no good way of delegating methods.
Sherab Giovannini
@Shaddy
Nov 13 2017 15:48
Why does Rust include dependences over VCRUNTIME140 under Windows? I mean, I know we need an allocator and an exception handler but is it really necessary?
Sander Maijers
@sanmai-NL
Nov 13 2017 16:00
What is the most efficient way to turn &[std::string::String]into&[&str]?
red75prime
@red75prime
Nov 13 2017 16:43
If you need &[&str], you need to allocate: let str_vec: Vec<&str> = string_slice.iter().map(String::as_str).collect(); let str_slice = &str_vec[..];
David Harvey-Macaulay
@alteous
Nov 13 2017 16:44
Is there a way of retrieving the type of a let binding? I want to do something like this:
trait Family {
    type Foo;
}

impl Family for i32 { type Foo = u32; }

fn main() {
    let x = 123;
    let y = <x as Family>::Foo::default();
}
The compiler complains that x is not a type.
red75prime
@red75prime
Nov 13 2017 16:54
David Harvey-Macaulay
@alteous
Nov 13 2017 17:05
@red75prime Not really what I was looking for but thanks.
I'm not sure this can be done is stable Rust. Oh well.
red75prime
@red75prime
Nov 13 2017 17:06
replace println with let y = foo(&x);
red75prime
@red75prime
Nov 13 2017 17:28
Input to foo: &123i32 output <i32 as Family>::Foo::default(). I can't see what's missing.
David Harvey-Macaulay
@alteous
Nov 13 2017 17:32
@red75prime You're working with the type T instead of the let binding x.
Essentially what I'm looking for is <type_of!(x) as Family>::Foo but I don't think that exists.
Judson Lester
@nyarly
Nov 13 2017 21:15
 wrong number of type arguments: expected at least 1, found 0
||    |
|| 45 | fn authorized_get(client: hyper::client::Client,
||    |                           ^^^^^^^^^^^^^^^^^^^^^ expected at least 1 type argument
Huh? hyper::client::Client is struct.