[deleted]
Rust 1.26 released
101–110 of 178 posts
Re: Rust 1.26 released
#102Earlier quoted context omitted.
The guarantee of `impl Trait` is that if I want to call a trait method on the returned object, e.g. for iterators if I want to call `foo(0).next()`, then the function pointer will always be in the same place on the object in memory (static dispatch). By contrast, if I returned a boxed trait, then calling the trait method requires a dynamic lookup to find the method on the boxed object, and then jumping to that functi…
I think your explanation of static and dynamic dispatch is either wrong, or incredibly confusing. The offset of the function pointers is always statically known for a given trait/interface type, it's just the actual vtable instance that may not be known, ie. the concrete type implementing that trait/interface. A statically known vtable instance that can be inlined/monomorphized is static dispatch, and if it's not kno…
I don't understand what's so confusing about it. GP says
"calling the trait method requires a dynamic lookup to find the method on the boxed object"
It sounds like all you want to say is
"calling the trait method requires a dynamic lookup to find [the vtable instance, which is then used to find] the method on the boxed object"
Re: Rust 1.26 released
#103So, so, so much stuff in this release! The next few are shaping up to be similar. Very exciting times! As always, happy to answer questions, provide context, etc.
In this example: fn foo(x: i32) -> Box > { let iter = vec![1, 2, 3] .into_iter() .map(|x| x + 1); if x % 2 == 0 { Box::new(iter.filter(|x| x % 2 == 0)) } else { Box::new(iter) } } Why is it that I can't return `impl Iterator `? Doesn't the `Filter` type implement `Iterator` for the same associated type?
I'll take a stab at explaining this in the way that I finally started grokking the issue (coming from the land of Java).
In Rust (most languages), by default the compiler needs to set aside space on the stack for each return value. So it needs a constantly known size (and shape) to create the slot on the stack. You need to flip to dynamic dispatch, ie a pointer to an object (Java's default), that will be placed on the stack as a reference to the unknown size/shape of the thing at the end of the pointer when the size/shape is unknown. A pointer always has a constant size on the stack.
In this example, `impl Trait` is just saying I want the compiler to figure out the size/shape of the thing being returned for me, and allocate that to the stack at the call site of the function. What this means is that even with `impl Trait` you must return a thing that has the same size/shape.
Steve's answer mentions a common pattern used to create constant size/shape by using an enum for the wrapper type to return two different types on the stack from the function. The only other option is to put something with unknown size behind a pointer, ie Box or &Trait, and thus pay the expense of dynamic dispatch.
Re: Rust 1.26 released
#104Earlier quoted context omitted.
Needing to use two separate third-party crates (lazy_static and maplit) to have a global constant-initialized hash table is the one that surprised me recently.
maplit is purely a convenience macro, so you shouldn't have actually needed it. Once `const fn` is a thing, lazy_static should be used a lot less too. Incidentally you might like the phf crate, depending on your needs.
Sure, maplit's hashmap! is just a convenience macro, but then so is vec!. Hashtables are a pretty fundamental data type and they deserve to be easy to write constant initializers for, just like vectors.
'const fn' seems like a red herring -- I don't want to write const functions, because I don't want to write code to initialize data structures at all. I want to write representations of data structures...
Re: Rust 1.26 released
#105I really wonder why is Golang so popular today when Rust is just killing it?
Aside from the head start, I believe Go legitimately hits a sweet spot for developers wanting a language that's relatively easy to use yet also fast and fully compiled. Rust on the other hand is targeted more towards developers that want C-like low-level control along with safety against shooting themselves in the foot. The former audience is probably larger than the latter. But popularity isn't everything (JavaScrip…
> C-like low-level control along with safety against shooting themselves in the foot
Yep, checking in. I want to write libraries that work on Windows, Linux, OSx, iOS, and Android that expose a C api but without having to write any C.
I know a bit of C, but not enough to feel like I can effectively use it to build the things I can build with Rust.
Re: Rust 1.26 released
#106Earlier quoted context omitted.
Every language I’m aware of has different syntax for inclusive vs exclusive range; making it situational would be quite confusing, I’d imagine.
Go deliberately left that out.[1] Probably a good decision. [1] https://groups.google.com/forum/#!msg/golang-nuts/7J8FY07dkW...
Huh, given the context of loop ranges over integers, when I saw the EWD link in that thread, I guessed it would be the "Why numbering should start at zero" one. Instead, the one linked ("On the cruelty of really teaching computing science") is about 10x longer, and it was an interesting glimpse into his philosophy.
Re: Rust 1.26 released
#107Earlier quoted context omitted.
maplit is purely a convenience macro, so you shouldn't have actually needed it. Once `const fn` is a thing, lazy_static should be used a lot less too. Incidentally you might like the phf crate, depending on your needs.
Sure, maplit's hashmap! is just a convenience macro, but then so is vec!. Hashtables are a pretty fundamental data type and they deserve to be easy to write constant initializers for, just like vectors. 'const fn' seems like a red herring -- I don't want to write const functions, because I don't want to write code to initialize data structures at all. I want to write representations of data structures...
Sure, I think it's a useful crate. But it's certainly not "Need[ed] ... to have a global constant-initialized hash table" that's all.
const fn isn't a red herring; you won't be writing const fns, you'll be using them to do the actual initialization. If maplit would use them internally, for example.
Re: Rust 1.26 released
#108Earlier quoted context omitted.
Maybe after the community chooses a few “winners” the Rust devs could promote them as being “suggested” packages? Also, some suggested metapackages/bundles wouldn’t hurt for newbies, like a set of crates for developing command line tools, for example. Something like this: https://marketplace.visualstudio.com/
Why choose a winner? What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate? Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach? To be honest, all I see are downsides to having a huge std lib. The benefit s…
I tend to agree, but I also think that there's a little bit of nuance here. For one thing, I have definitely enjoyed using a large standard library...when I didn't have access to cargo or tools of similar quality.
My impression is that many of those who are asking for Rust's stdlib to grow are also/actually asking "please make it really easy for me to use these APIs that I care about," to which I would respond "it's OK, code can be easy to reuse even if it's not in the stdlib," "try cargo," and "crates.io needs to continue improving on discoverability."
EDIT: also, hi!
Re: Rust 1.26 released
#109Earlier quoted context omitted.
Aside from the head start, I believe Go legitimately hits a sweet spot for developers wanting a language that's relatively easy to use yet also fast and fully compiled. Rust on the other hand is targeted more towards developers that want C-like low-level control along with safety against shooting themselves in the foot. The former audience is probably larger than the latter. But popularity isn't everything (JavaScrip…
> C-like low-level control along with safety against shooting themselves in the foot Yep, checking in. I want to write libraries that work on Windows, Linux, OSx, iOS, and Android that expose a C api but without having to write any C. I know a bit of C, but not enough to feel like I can effectively use it to build the things I can build with Rust.
> I know a bit of C, but not enough to feel like I can effectively use it
I love what the Foreward [1] in the Rust Book has to say about this:
"Traditionally, this realm of programming is seen as arcane, accessible only to a select few who have devoted the necessary years learning to avoid its infamous pitfalls. And even those who practice it do so with caution, lest their code be open to exploits, crashes, or corruption.
Rust breaks down these barriers by eliminating the old pitfalls and providing a friendly, polished set of tools to help you along the way."
[1] https://doc.rust-lang.org/book/second-edition/foreword.html
Re: Rust 1.26 released
#110Earlier quoted context omitted.
Why choose a winner? What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate? Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach? To be honest, all I see are downsides to having a huge std lib. The benefit s…
I tend to agree, but I also think that there's a little bit of nuance here. For one thing, I have definitely enjoyed using a large standard library...when I didn't have access to cargo or tools of similar quality. My impression is that many of those who are asking for Rust's stdlib to grow are also/actually asking "please make it really easy for me to use these APIs that I care about," to which I would respond "it's…
Hiiii.
I think we're likely on the same page. The desire to make writing an HTTP server that much easier by providing a quick-to-use solution is entirely reasonable.
I just don't believe the solution is some 'sanctioned', permanent addition to std.
Better to be solved in crates.io.