Announcing Rust 1.27.2 • Hacker News Board

Re: Announcing Rust 1.27.2

#11

Post by pcwalton » Fri, Jul 20, 2018, 6:28 PM UTC

blackrock wrote: post #5

Sample Code: ======================= fn transmute_lifetime (t: &'a (T,)) -> &'b T { match (&t, ()) { ((t,), ()) => t, } } ======================= I thought Obfuscated-C was hard to read. Then C++ with all its templates. Now, I'm thinking Rust has taken the prize.

Nobody would ever write that code in practice, for multiple reasons:

- Every reference has a different explicit lifetime—one input, one output—which would rarely ever show up in real code.

- There is a tuple with 1 element, which I have never seen in the wild.

- It's matching against `()`, the void type, which is never done because it's useless.

Re: Announcing Rust 1.27.2

#12

Post by ljklkjaaaammbb » Fri, Jul 20, 2018, 6:30 PM UTC

blackrock wrote: post #5

Sample Code: ======================= fn transmute_lifetime (t: &'a (T,)) -> &'b T { match (&t, ()) { ((t,), ()) => t, } } ======================= I thought Obfuscated-C was hard to read. Then C++ with all its templates. Now, I'm thinking Rust has taken the prize.

Inflammatory nonsense.

Re: Announcing Rust 1.27.2

#13

Post by [deleted] » Fri, Jul 20, 2018, 6:44 PM UTC

topspin wrote: post #7

asksobvqs wrote: post #2

Does anyone else here share a concern over numerous patches to the match ergonomics feature?

There have been 3 patch releases that include borrow checker fixes related to the match ergonomics work in the last 45 days. [1] https://blog.rust-lang.org/2018/06/05/Rust-1.26.2.html (June 5) [2] https://blog.rust-lang.org/2018/07/10/Rust-1.27.1.html (June 10) [3] https://blog.rust-lang.org/2018/07/20/Rust-1.27.2.html (July 20) The latest of these actually address your concern directly.

[deleted]

Re: Announcing Rust 1.27.2

#14

Post by ameixaseca » Fri, Jul 20, 2018, 6:54 PM UTC

blackrock wrote: post #5

Sample Code: ======================= fn transmute_lifetime (t: &'a (T,)) -> &'b T { match (&t, ()) { ((t,), ()) => t, } } ======================= I thought Obfuscated-C was hard to read. Then C++ with all its templates. Now, I'm thinking Rust has taken the prize.

Beauty lies on the eyes of the observer.

Also, there's nothing obfuscated here, and everything is explicit if you know the syntax.

The alternative is not caring and leaving everything for a GC and/or validating values with runtime checks instead. There are other languages which chose these approaches.

Re: Announcing Rust 1.27.2

#15

Post by webaholic » Fri, Jul 20, 2018, 7:08 PM UTC

TheDong wrote: post #9

blackrock wrote: post #5

Sample Code: ======================= fn transmute_lifetime (t: &'a (T,)) -> &'b T { match (&t, ()) { ((t,), ()) => t, } } ======================= I thought Obfuscated-C was hard to read. Then C++ with all its templates. Now, I'm thinking Rust has taken the prize.

If you're familiar with rust syntax, that function is readable: A function 'transmute_lifetime' that takes a tuple of generic type T with lifetime 'a and returns a T with lifetime 'b... And then the code itself, beyond the function signature, is trivial destructuring matching. If you're not familiar with the syntax of a language, of course it won't be easy to read. perl and bash can rapidly devolve into symbol salad…

and that is where the problem lies. All code is readable if you spend an hour or two. The point is that it is not lucid. You have to strain to understand such code. The issue is people thinking this code is acceptable.

Re: Announcing Rust 1.27.2

#16

Post by kibwen » Fri, Jul 20, 2018, 7:12 PM UTC

To reiterate what the OP suggests at the bottom, the new (in-progress) borrow checker (the one designed from the ground-up to support non-lexical lifetimes (NLL)) suffers from none of the match bugs that have inspired the recent slew of patch releases.

It does indeed appear as though the new match features were designed with the theoretical model of the borrow checker in mind, to which the new borrow checker hews much more strongly than the original (in conversations with Niko Matsakis he suggests that the new borrow checker is implemented in the fashion that he had wanted to implement the original one, but the other machinery in the compiler (e.g. a CFG-aware IR like MIR) wasn't ready at the time, and wouldn't be for some years). Obviously the degree to which the original borrow checker would be deficient in the face of the new match features wasn't fully understood, or else I expect that its stabilization would have been delayed. Fortunately, NLL-aware borrowck is enabled by default in nightly right now (or should be imminently: https://internals.rust-lang.org/t/possible-stabilizations-fo... ) and hopes to reach the stable channel within a few months. :)

Re: Announcing Rust 1.27.2

#17

Post by TheDong » Fri, Jul 20, 2018, 7:14 PM UTC

webaholic wrote: post #15

TheDong wrote: post #9

Earlier quoted context omitted.

If you're familiar with rust syntax, that function is readable: A function 'transmute_lifetime' that takes a tuple of generic type T with lifetime 'a and returns a T with lifetime 'b... And then the code itself, beyond the function signature, is trivial destructuring matching. If you're not familiar with the syntax of a language, of course it won't be easy to read. perl and bash can rapidly devolve into symbol salad…

and that is where the problem lies. All code is readable if you spend an hour or two. The point is that it is not lucid. You have to strain to understand such code. The issue is people thinking this code is acceptable.

It's not being presented as acceptable code for maintenance or other long-term usage.

It's being presented as a terse explanation of what the bug was and how it was triggered.

I didn't spend an hour or two understanding that code, I spent less than a minute because I already know rust.

I don't understand your point. The code served its purpose well: for the audience (rust users) it demonstrated the bug (lifetime unsafety in match ergonomics change).

If the audience were "people who don't know rust", then of course that code wouldn't be a good demonstration, but that's not who the audience for this post is.

Re: Announcing Rust 1.27.2

#18

Post by kibwen » Fri, Jul 20, 2018, 7:19 PM UTC

blackrock wrote: post #5

Sample Code: ======================= fn transmute_lifetime (t: &'a (T,)) -> &'b T { match (&t, ()) { ((t,), ()) => t, } } ======================= I thought Obfuscated-C was hard to read. Then C++ with all its templates. Now, I'm thinking Rust has taken the prize.

This is obfuscated code designed to exploit an obscure edge case in the compiler, and then minified for concision in the test case. :P

Re: Announcing Rust 1.27.2

#19

Post by antpls » Fri, Jul 20, 2018, 7:32 PM UTC

pluto9 wrote: post #8

bubaflub wrote: post #4

Earlier quoted context omitted.

There’s a whole section on the page with the header “Concern over numerous patches to the match ergonomics feature”. So if your question is literally, “Does anybody else...” then the answer is yes: “Users have expressed concern with the frequency of patch releases to fix bugs in the match ergonomics verification by the current borrow checker on a variety of Rust’s forums. ” If the question is more about being concern…

Check out the username. Troll/novelty account.

It's dumb, now the answer to the flagged comment doesn't make any sense without the parent message...

Re: Announcing Rust 1.27.2

#20

Post by matthewmacleod » Fri, Jul 20, 2018, 7:36 PM UTC

webaholic wrote: post #15

TheDong wrote: post #9

Earlier quoted context omitted.

If you're familiar with rust syntax, that function is readable: A function 'transmute_lifetime' that takes a tuple of generic type T with lifetime 'a and returns a T with lifetime 'b... And then the code itself, beyond the function signature, is trivial destructuring matching. If you're not familiar with the syntax of a language, of course it won't be easy to read. perl and bash can rapidly devolve into symbol salad…

and that is where the problem lies. All code is readable if you spend an hour or two. The point is that it is not lucid. You have to strain to understand such code. The issue is people thinking this code is acceptable.

Expressing complex concepts almost always requires complex expressions of intent!

I don’t really know Rust all that well beyond a few toy projects. But if you were familiar with core aspects of the syntax and semantics - lifetimes, generics, tuples and the void type in this case - then it’s not particularly complex. Add to the fact that it’s code you’re not actually going to see in practice and I don’t think it’s so bad!