A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?
Rust 1.48
61–70 of 119 posts
Re: Rust 1.48
#62A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?
Maybe it was still downloading some required binaries in the background when you were trying it out?
Re: Rust 1.48
#63On the one hand it's not hugely thrilling for the headline features of a new release to be improvements to doc tooling and a stabilized trait impl but on the other hand it's good to see the language settling down and maturing.
The next two releases will be bigger. The 1.49 release will have a new tier 1 target (aarch64-unknown-linux-gnu) as well as apple silicon as a tier 2 target. The 1.50 release will have min const generics as well as stable backtraces. As the releases are every 6 weeks, an individual one might seem small. But over time they add up. Note though that I do consider the rustdoc improvements to be major. Previously I wasn't…
There have been releases where ARM (maybe I was using armv7 rather than aarch64 then, but I'm on aarch64 now) was totally broken, and now I know that won't happen on 1.49 or beyond.
Min const generics...I'm not sure I'll find much use for it until const_evaluatable_checked happens, but I'm glad to see progress.
Stable backtraces will mean I can stop using the deprecated failure crate without giving up my quality diagnostics.
Re: Rust 1.48
#64Earlier quoted context omitted.
const fns are not inherently evaluated at compile time, so that would be a misnomer.
Maybe `pure`. Then it is fairly straightforward to explain that the computation of `const` values must be `pure`.
It has its own challenges. Consider:
const fn foo(x: &mut i32) {
*x += 1;
}
would you consider this function pure? I don't think many would. Also, it may be pure given Rust's semantics, but it kinda goes against the intuitive, usual way people talk about purity, so that makes it hard.(This is not yet stable in Rust, but will be.)
Re: Rust 1.48
#65Earlier quoted context omitted.
Some things want an array of a specific size. If you have a function like https://doc.rust-lang.org/stable/std/primitive.u16.html#meth... pub const fn from_be_bytes(bytes: [u8; 2]) -> u16 you can't pass it a slice. This would let you pass a vector to this function. Now, because this wasn't possible previously, it means many things take a slice, and then check that the length is the length they expect, because that en…
TryInto is already implemented for slices in 1.47, so `let foo = u16::from_be_bytes(some_slice.try_into().unwrap());` would work before 1.48. This trait wasn't implemented for vectors though, so you would have to write `let foo = u16::from_be_bytes(some_vec.to_slice().try_into().unwrap());`. With new release you can drop `to_slice()` part. Nothing earth-shattering, but makes sense.
Re: Rust 1.48
#66On the one hand it's not hugely thrilling for the headline features of a new release to be improvements to doc tooling and a stabilized trait impl but on the other hand it's good to see the language settling down and maturing.
The next two releases will be bigger. The 1.49 release will have a new tier 1 target (aarch64-unknown-linux-gnu) as well as apple silicon as a tier 2 target. The 1.50 release will have min const generics as well as stable backtraces. As the releases are every 6 weeks, an individual one might seem small. But over time they add up. Note though that I do consider the rustdoc improvements to be major. Previously I wasn't…
Re: Rust 1.48
#67A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?
Re: Rust 1.48
#68A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?
Re: Rust 1.48
#69A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?
Re: Rust 1.48
#70Earlier quoted context omitted.
steveklabnik is (of course) correct, but you also have to consider the performance cost of a dynamicaly sized slice versus a statically sized array. A situation I've encountered several times already is implementing statically sized FIFOs. At the moment in Rust I can't implement a type "FIFO of depth N" where is a generic, static parameter. My only choices are implementing "FIFO of depth n" where n is provided dynami…
You maybe could write something like this: pub struct Fifo > { and then back it with an array. I learned this trick from whitequark. (Though maybe if you want something other than a slice of bytes, this gets harder... I've used this trick for ringbuffers/mmio only, personally, so YMMV.) That being said real const generics will make this way nicer, eventually.