Live data from Hacker News

Rust 1.48

blog.rust-lang.org

61–70 of 119 posts

Re: Rust 1.48

#61

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-analyzer gets better and better every week.

Re: Rust 1.48

#62

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?

Sounds a bit strange. I'm using rust-analyzer in combination with TabNine (which both have integrations in every major editor), and it's among the best completion I've encountered across languages (though there are some limitations when it comes to proc-macros).

Maybe it was still downloading some required binaries in the background when you were trying it out?

Re: Rust 1.48

#63
post #27
post #13

On 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…

I'm indeed excited about those!

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

#64

Earlier 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`.

Fun fact: Rust did use "pure" a very long time ago... https://news.ycombinator.com/item?id=24295941

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

#65
post #47

Earlier 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.

That doesn't work with non-copyable types.

Re: Rust 1.48

#66
post #27
post #13

On 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…

These may be major changes for devs, but for beginners who want to learn Rust without it changing under them all the time, these are not major changes anymore. Which is a great thing!

Re: Rust 1.48

#67

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?

As others have said, I'd be curious what plug in you use. The state of things is pretty good. I'm using the IntelliJ Rust plugin and love it. It also provides pretty good inline annotation of inferred types which I find to be a big time saver.

Re: Rust 1.48

#68

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?

CLion with the Rust plugin is pretty great.

Re: Rust 1.48

#69

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?

I use Kate, which is really bare bones, with a Rust LSP server and haven't had a problem with completion or highlighting.

Re: Rust 1.48

#70
post #36

Earlier 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.

I wasn't aware of this trick, thank you for that. I guess if I have to implement another FIFO before const generics land I'll have an opportunity to try it out...
Post reply on HN