161–170 of 178 posts
Why is a filtered iterator a different type than an unfiltered iterator?
I recently found myself inserting &/*/ref/ref mut into match expressions before I'd even seen a compiler error. My first thought was "aha, look at how experienced I am with Rust now!" Followed immediately by "I can't wait until this isn't something you have to learn to be productive with the language." And now that day has come! Really exciting for me. I also need to go and find all of my impl Trait TODO comments and…
Earlier 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…
Why is a filtered iterator a different type than an unfiltered iterator?
This is hard to answer as a one-liner; do you know about monomorphic vs. polymorphic code and static/dynamic dispatching? Rust is, by default statically dispatched, so because the two kinds of iterators do different things, they have to be of different types.
One iterator simply returns the value and increments, and the other needs to apply the filter first and potentially advance several times.
Earlier quoted context omitted.
If the Rust ecosystem was up to snuff on the HTTP front, I'd be writing a lot more of it. At the moment, Go's HTTP implementation is just pretty much unbeatable. I'm confident it'll get there — and there's a ton of great work going on to get it there — but at the moment, it's still the Wild West. Go also hits the sweet spot for CLI apps, in my opinion. The error handling is obtrusive and annoying otherwise, but for c…
"up to snuff on the HTTP front" I think this is a pretty major piece as well. Go was introduced many years earlier, backed by Google marketing and had strong HTTP services as a day one feature; it was designed for probably the most popular use case by perhaps the most influential fount of new tech. Given all that has Go really done all that well? Has it gone much beyond network services and a couple other niches (Doc…
I don't think it was ever intended to be important in those terms, however. It was designed primarily to solve specific sets of problems at Google, but I don't think any sights were set on the C, Java or other related language worlds at large. From that perspective, I would argue that Go's actually been fairly successful.
I'd argue the Rust team is much more eager to be a real disrupter. I think in that sense, they're succeeding in ways and have not yet achieved success in others.
Earlier quoted context omitted.
If the Rust ecosystem was up to snuff on the HTTP front, I'd be writing a lot more of it. At the moment, Go's HTTP implementation is just pretty much unbeatable. I'm confident it'll get there — and there's a ton of great work going on to get it there — but at the moment, it's still the Wild West. Go also hits the sweet spot for CLI apps, in my opinion. The error handling is obtrusive and annoying otherwise, but for c…
Hyper 0.12 is right around the corner with the excellent h2 crate. We've been using the master branch on production the whole 2018 and it's super fast, stable and ergonomic.
Hooray, congrats to the rust contributors, once again. :) Personally, not a fan of the match change. But then I was already not a fan of autoderef in method calls.
The biggest negative I've seen is this: let example: (String, String, String) = ("ref".to_string(), "to".to_string(), "ref".to_string()); let example: (&str, &str, &str) = match &example { (ref1, to, ref2) => (ref1, to, ref2), }; Which might look confusing to people, it's converting from &(1,2) to (&1,&2)... but it's still type safe. Besides something like this, is there another reason to be worried about it? https:/…
For field access/method calls, autoderef is a bigger convenience because we don't have the C++ -> operator, but I think I'd have preferred a syntax change here over the current behavior.
Earlier quoted context omitted.
The biggest negative I've seen is this: let example: (String, String, String) = ("ref".to_string(), "to".to_string(), "ref".to_string()); let example: (&str, &str, &str) = match &example { (ref1, to, ref2) => (ref1, to, ref2), }; Which might look confusing to people, it's converting from &(1,2) to (&1,&2)... but it's still type safe. Besides something like this, is there another reason to be worried about it? https:/…
Reading (or even writing!) rust code, you can get increasingly far without knowing what level of indirection you're operating on. I don't enjoy that. I don't personally feel like the notational burden for explicitness is enormous. For field access/method calls, autoderef is a bigger convenience because we don't have the C++ -> operator, but I think I'd have preferred a syntax change here over the current behavior.
Deref coercion makes a &Box behave like a &T (removing a level of indirection). Default binding modes only make a &(T, U) behave like a (&T, &U).
I've idly wondered whether it would have been possible to replace deref coercions with something like this. Making Box behave like &T kinda works but loses you the ability to control `&T` vs `&mut T`, but maybe `x.y` where `x: &T` could "pass the reference on" giving you a `&U`.
Earlier quoted context omitted.
I'd say on the contrary. They chose it even while knowing they'll gonna need to hack generics. (Same in k8s, generics hacked together in a few different ways)
You're starting from the assumption that the Google developers took a clear-eyed decision on the merits, which I don't share.
The wonderful thing about Rust is that despite being fairly new and rare to get paid for working on it, it is still enticing( to most programmers I've met). The consistent effort to improve it is really paying off. I hope it gets to a place where it's `batteries included` like Python. There are some glaring holes in the stdlib I would like to see fixed sometime soon.
The argument for putting things in third-party "blessed" crates rather than the standard library is that it allows them not to have to follow the versioning guarantees of Rust itself. Given that the core team has stated that they don't plan to have a Rust 2.0, this means that there wouldn't _ever_ be any API-breaking changes for things added to the standard library; by having things like `regex` and `rand` be externa…
Cause it sounds like a strong commitment here.