31 comments

[ 3.3 ms ] story [ 85.9 ms ] thread
Another "boring" release of Rust, which is exciting.
Aha, wait for the next one. It contains the 2021 edition!
The 2021 edition itself is pretty boring. It only contains a few tweaks compared to Rust 2018, which pioneered such features as Non-lexical lifetimes and Async programming.
Overall it is, but the more fine-grained closure captures and the enabling of array.into_iter are both pretty nice improvements.
This release contains array::map, which I consider an exciting feature!
On the face of it it seems weird to duplicate Iterator methods directly on array (which is iterable), but then it really is a special case because this version (thanks to const generics!) should be able to avoid an allocation, which to my understanding isn't possible with the Iterator version
Well arrays never allocate in the first place, but you'd need some sort of specialized iterator api that either:

- Handles the iterator not being the same size as the array you want to collect the iterator into and turns it into some sort of Result<[T; N], ArrayCollectError>.

- By itself knows the exact size of the iterator as part of the iterator type and thus can ensure via the type system that the iterator has exactly as many elements as the array needs.

> By itself knows the exact size of the iterator as part of the iterator type…

std::array::IntoIter<T, N> already satisfies that requirement. The result of mapping over a std::array::IntoIter<T, N> should be std::iter::Map<array::IntoIter<T, N>, F>, which also has the number of elements at the type level and even inherits ExactSizeIterator from array::IntoIter. The problem, I think, is that ExactSizeIterator only says that the size is known at run time; there is no "ConstSizeIterator<N>" trait which would witness that the exact size is known at compile time. If there were then you could potentially collect the items from a ConstSizeIterator<N> (which could be implemented by array::IntoIter<T, N> and inherited by iter::Map<array::IntoIter<T, N>, F>) into an array of N elements without any runtime checks or allocation.

array.map is not inline, it consumes the array and returns another https://doc.rust-lang.org/std/primitive.array.html#method.ma...

But yes in the end this is all done in the stack

We could have an inline version of map (for arrays and Vec) if we had a way to assert that two types have the same size. This means we can reuse the buffer because all elements will fit.

This might be the wrong place to ask but does anyone know what’s the situation with fixing Range not implementing Copy? I ran into this the other day again and way annoyed.
(comment deleted)
Not sure why you were downvoted. I also wondered about that when I started with Rust. I'd love to see this at some point but I just started cloning ranges everywhere. As most of my ranges are simple (e.g. just a Range<usize>) the main downside I see is the additional clone calls.
> Anna Harren was a member of the community and contributor to Rust known for coining the term "Turbofish" to describe ::<> syntax. Anna recently passed away after living with cancer. Her contribution will forever be remembered and be part of the language, and we dedicate this release to her memory.

I don't even program in Rust myself and I've still heard of the term "Turbofish". Rest in peace, Anna

Rust in peace, Anna.
I now realise what the other meaning of this is. I sincerely apologise, Anna. I do wish that you rest in peace, knowing that you made long-lasting contributions to Rust.
Not sure who decided that everyone should suffer from the horrible turbofish operator (::<type>). C++ requires no such monstrosity.

If this operator had been introduced in a corporate language like Swiftlang, it would be the butt of jokes, but community languages like Rust can get away with this by using a cutesy name and everyone is simply too afraid to criticise Rust as they will be the target of intense group-hate.

Uh, maybe you genuinely don't realize this but you're replying to a comment remembering someone who passed away. Which is not the moment to start a syntax holy war.
This is the lamest title i ever read

Rust? what is that?

1.55.0 why is that worth mentioning

Is this an AD? or a news about an update?

Why not mention it's an update and is a release note?

or is Hacker News the place to release rust release notes so mentioning it would imply it is not

Fishy fishy, when i hold your tail, you start to stray away, or not, doesn't make sense anyways, does it?

I submitted the title, as is HN tradition, with the title of the article: "Announcing Rust 1.55.0". At some point in these last 55 releases, Hacker News decided to start cutting off the "Announcing." I don't know why. I haven't been bothered enough to email dang about it to ask, personally.
Zig 0.8.1 Release Notes - https://news.ycombinator.com/item?id=28442449

Julia 1.6 Highlights - https://news.ycombinator.com/item?id=26580926

Go 1.17 Release Notes - https://news.ycombinator.com/item?id=28201732

Why does Rust have special treatment on hackernews?

EDIT:

i can't reply to the guy who replied, why is that hackernews superOmegaAlphaModerators?

So here is my reply: @maleldil

The title was edited to convey an ideology, something that wasn't done for other languages

So one could ask certain questions about whether or not certain news get special treatment

"this news talk about X, let's edit title"

"this news is bad, let's edit title"

"this news is important to us, let's edit title"

"this news is lame, nobody will care, let's not bother with it"

When one has control about news, and edit what users submit, one can ask if that is a a website run by totalitarian regime, or not, or yes

How is this post any different from the ones you linked?
Because the "Announcing" got cut off from the title. That seems to be the entire gist of the complaint.
Titles in the form <Project> <Version> are overwhelmingly unexceptional and clear. And I only used "unexceptional" instead of "common" here as a shy attempt to restore the unbalance caused by the first sentence of your comment.
that's not the question

the question is why was it edited by a moderator for Rust, but not for every other languages i listed above?

if I understood correctly, the word "Announcing" gets automatically removed when submitting. You can then re-edit to re-introduce the word if you really want to keep it.
It wasn't edited by a moderator and our software doesn't know (or care) what language an article is about.

Could you please stop posting off-topic flamewar comments to HN?

Edit: since you've posted so many of these and we've already asked you 3 times to stop, I've banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.

> Faster, more correct float parsing

> The standard library's implementation of float parsing has been updated to use the Eisel-Lemire algorithm, which brings both speed improvements and improved correctness. In the past, certain edge cases failed to parse, and this has now been fixed.

> You can read more details on the new implementation in the pull request description: https://github.com/rust-lang/rust/pull/86761

There's some pretty big speed improvements there. 3x-10x in the most normal cases, 1600x on some edge cases, and stdlib is now capable of parsing the floats that it never used to be able to.