Earlier quoted context omitted.
How is it much safer? Sounds like you don't know what you're talking about.
One could make an argument about data races, for example. Rust prevents them at compile time, Go does not. You could also make an argument about compile-time guarantees more generally. I'm not sure it's really a great argument, but you could make it. I think the parent's statement that it's only Go because it's made by Google is demonstrably false.
Rust 1.26 released
81–90 of 178 posts
Re: Rust 1.26 released
#82Earlier quoted context omitted.
One could make an argument about data races, for example. Rust prevents them at compile time, Go does not. You could also make an argument about compile-time guarantees more generally. I'm not sure it's really a great argument, but you could make it. I think the parent's statement that it's only Go because it's made by Google is demonstrably false.
One could make the same kind of argument with GC lang vs none GC ( RAII doesn't protect from everything ). OP said "much safer" Rust is not much safer than Go, maybe it is safer but definitely not "much safer"
Re: Rust 1.26 released
#83Earlier 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...
Re: Rust 1.26 released
#84Earlier quoted context omitted.
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?
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…
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 known at compile-time it must be dynamically dispatched.
Re: Rust 1.26 released
#85So, 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.
While I'm sure it won't mess anyone up, the range for the i128 is hard to interpret. It looks like -xxxxx - xxxxxx but with the extreme number of digits it looks like two negative numbers or a subtraction problem.
[edit: u128 -> i128]
Re: Rust 1.26 released
#86Earlier quoted context omitted.
Yeah, I can totally appreciate the perspective, but without a significant set of policy changes, I don't see either of these happening. We'll see!
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/
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 seems to be that there isn't an obvious, de facto choice for what crates to use. But I think that's a problem better solved by crates.io.
Re: Rust 1.26 released
#87So, 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.
Amazing work on this release! I've needed so many of these features in stable Rust, and I'm so excited to get to use these. I mean, just yesterday I had to do some weird stuff to a for loop in order to iterate over all u8s in a cleanish way. Lovely, lovely work. I'm especially excited to see how clever the ref/ref-mut `match` inferring is. If it's reliable, that's gonna remove quite a bit of friction for newcomers. S…
Re: Rust 1.26 released
#88So, 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.
Congrats on the release, I've been following Rust for a long time. While I'm sure it won't mess anyone up, the range for the i128 is hard to interpret. It looks like -xxxxx - xxxxxx but with the extreme number of digits it looks like two negative numbers or a subtraction problem. [edit: u128 -> i128]
Re: Rust 1.26 released
#89Earlier quoted context omitted.
How is it much safer? Sounds like you don't know what you're talking about.
It sounds like you have no idea about Rust.
Re: Rust 1.26 released
#90So yeah, 1.26 is the most substantial release since 1.0, but there's lots more goodies coming in the pipeline. :) It just so happened that all the initiatives from last year are preparing to land at approximately the same time. For example, coming up next in 1.27 is stable SIMD: https://github.com/rust-lang/rust/pull/49664 (though only for x86/x86_64 at first; more platforms and high-level crossplatform APIs are on t…
So yeah, 1.26 is the most substantial release since 1.0, but there's lots more goodies coming in the pipeline Will rust users get a break someday?
Rust threads are a special kind of obscene, I feel dirty after reading them.