<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>withoutboats3</author><text>These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern matching with boolean expressions has a lot of fraught issues around the scoping of the bindings declared in the pattern. This becomes especially complex when you consider the `||` operator. The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases.&lt;p&gt;&amp;gt; Pin didn&amp;#x27;t take much work to implement in the standard library. But its not a &amp;quot;lean&amp;quot; feature. It takes a massive cognitive burden to use - to say nothing of how complex code that uses it becomes. I&amp;#x27;d rather clean, simple, easy to read rust code and a complex borrow checker than a simple compiler and a horrible language.&lt;p&gt;Your commentary on Pin in this post is even more sophomoric than the rest of it and mostly either wrong or off the point. I find this quite frustrating, especially since I wrote detailed posts explaining Pin and its development just a few months ago.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;without.boats&amp;#x2F;blog&amp;#x2F;pin&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;without.boats&amp;#x2F;blog&amp;#x2F;pin&amp;#x2F;&lt;/a&gt;
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;without.boats&amp;#x2F;blog&amp;#x2F;pinned-places&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;without.boats&amp;#x2F;blog&amp;#x2F;pinned-places&amp;#x2F;&lt;/a&gt;</text><parent_chain><item><author>josephg</author><text>Author here. I hear what you&amp;#x27;re saying. But there&amp;#x27;s lots of times while using rust where the language supports feature X and feature Y, but the features can&amp;#x27;t be used together.&lt;p&gt;For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can&amp;#x27;t write a struct which contains a value returned via impl Trait - because you can&amp;#x27;t name the type.&lt;p&gt;Or, I can write &lt;i&gt;if a &amp;amp;&amp;amp; b&lt;/i&gt;. And I can write &lt;i&gt;if let Some(x) = x&lt;/i&gt;. But I can&amp;#x27;t combine those features together to write &lt;i&gt;if let Some(x) = x &amp;amp;&amp;amp; b&lt;/i&gt;.&lt;p&gt;I want things like this to be fixed. Do I want rust to be &amp;quot;bigger&amp;quot;? I mean, measured by the number of lines in the compiler, probably yeah? But measured from the point of view of &amp;quot;how complex is rust to learn and use&amp;quot;, feature holes make the language more complex. Fixing these problems would make the language simpler to learn and simpler to use, because developers don&amp;#x27;t have to remember as much stuff. You can just program the obvious way.&lt;p&gt;Pin didn&amp;#x27;t take much work to implement in the standard library. But its not a &amp;quot;lean&amp;quot; feature. It takes a massive cognitive burden to use - to say nothing of how complex code that uses it becomes. I&amp;#x27;d rather clean, simple, easy to read rust code and a complex borrow checker than a simple compiler and hard to use language.</text></item><item><author>gary17the</author><text>&amp;gt; The rust RFC process is a graveyard of good ideas.&lt;p&gt;I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to add new &amp;quot;features&amp;quot; to the PL, in order to prevent the &amp;quot;language surface&amp;quot; from being bloated, inconsistent and unpredictable.&lt;p&gt;I&amp;#x27;ve seen this happen before: I started out as a Swift fan, even though I have been working with Objective-C++ for years, considered it an awesome powerhouse and I did not really need a new PL for anything in particular in the world of iOS development. With time, Swift&amp;#x27;s insistence on introducing tons of new language &amp;quot;features&amp;quot; such as multiple, redundant function names, e.g., &amp;quot;isMultiple(of:)&amp;quot;, multiple rules for parsing curly braces at al. to make the SwiftUI declarative paradigm possible, multiple rules for reference and value types and mutability thereof, multiple shorthand notations such as argument names inside closures, etc. - all that made me just dump Swift altogether. I would have to focus on Swift development exclusively just to keep up, which I was not willing to do.&lt;p&gt;Good ideas are &amp;quot;dime a dozen&amp;quot;. Please keep Rust as lean as possible.</text></item></parent_chain></comment><story><title>Rewriting Rust</title><url>https://josephg.com/blog/rewriting-rust/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>valenterry</author><text>Yeah, I agree wholeheartedly with that. This is also what I really dislike in many languages.&lt;p&gt;You should have a look at Scala 3. Not saying that I&amp;#x27;m perfectly happy with the direction of the language - but Scala really got those foundations well and made it so that it has few features but they are very powerful and can be combined very well.&lt;p&gt;Rust took a lot of inspiration from Scala for a reason - but then Rust wants to achieve zero-cost abstraction and do high-performance, so it has to make compromises accordingly for good reasons. Some of those compromises affect the ergonomics of the language unfortunately.</text><parent_chain><item><author>josephg</author><text>Author here. I hear what you&amp;#x27;re saying. But there&amp;#x27;s lots of times while using rust where the language supports feature X and feature Y, but the features can&amp;#x27;t be used together.&lt;p&gt;For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can&amp;#x27;t write a struct which contains a value returned via impl Trait - because you can&amp;#x27;t name the type.&lt;p&gt;Or, I can write &lt;i&gt;if a &amp;amp;&amp;amp; b&lt;/i&gt;. And I can write &lt;i&gt;if let Some(x) = x&lt;/i&gt;. But I can&amp;#x27;t combine those features together to write &lt;i&gt;if let Some(x) = x &amp;amp;&amp;amp; b&lt;/i&gt;.&lt;p&gt;I want things like this to be fixed. Do I want rust to be &amp;quot;bigger&amp;quot;? I mean, measured by the number of lines in the compiler, probably yeah? But measured from the point of view of &amp;quot;how complex is rust to learn and use&amp;quot;, feature holes make the language more complex. Fixing these problems would make the language simpler to learn and simpler to use, because developers don&amp;#x27;t have to remember as much stuff. You can just program the obvious way.&lt;p&gt;Pin didn&amp;#x27;t take much work to implement in the standard library. But its not a &amp;quot;lean&amp;quot; feature. It takes a massive cognitive burden to use - to say nothing of how complex code that uses it becomes. I&amp;#x27;d rather clean, simple, easy to read rust code and a complex borrow checker than a simple compiler and hard to use language.</text></item><item><author>gary17the</author><text>&amp;gt; The rust RFC process is a graveyard of good ideas.&lt;p&gt;I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to add new &amp;quot;features&amp;quot; to the PL, in order to prevent the &amp;quot;language surface&amp;quot; from being bloated, inconsistent and unpredictable.&lt;p&gt;I&amp;#x27;ve seen this happen before: I started out as a Swift fan, even though I have been working with Objective-C++ for years, considered it an awesome powerhouse and I did not really need a new PL for anything in particular in the world of iOS development. With time, Swift&amp;#x27;s insistence on introducing tons of new language &amp;quot;features&amp;quot; such as multiple, redundant function names, e.g., &amp;quot;isMultiple(of:)&amp;quot;, multiple rules for parsing curly braces at al. to make the SwiftUI declarative paradigm possible, multiple rules for reference and value types and mutability thereof, multiple shorthand notations such as argument names inside closures, etc. - all that made me just dump Swift altogether. I would have to focus on Swift development exclusively just to keep up, which I was not willing to do.&lt;p&gt;Good ideas are &amp;quot;dime a dozen&amp;quot;. Please keep Rust as lean as possible.</text></item></parent_chain></comment><story><title>Rewriting Rust</title><url>https://josephg.com/blog/rewriting-rust/</url></story>