<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>nemo1618</author><text>I actually don&amp;#x27;t think this is true, which is kind of nuts. Programming languages generally fall into two categories:&lt;p&gt;1) They were either designed by one or two eccentrics, and thus contain a few great guiding principles and many questionable ideas, which invariably come back to bite large projects; or,&lt;p&gt;2) They were designed by a committee who tried to make the Final Universal Language that would solve every possible problem, resulting in a kitchen-sink mess of a language with a 400-page specification that no one reads.&lt;p&gt;Most mainstream languages made &lt;i&gt;some&lt;/i&gt; attempt to serve software-at-scale; for example, OO used to be the obvious thing that would make software more maintainable, so most languages support it at least in part. But if you look at a language like C++, it&amp;#x27;s obvious that many of its features were added simply because they were cool or increased expressiveness (e.g. operator overloading) without regard for long-term maintainability. Even things as mundane as &amp;quot;implicit &amp;#x27;this&amp;#x27;&amp;quot; are &lt;i&gt;clearly&lt;/i&gt; harmful to readability, with specious benefit.&lt;p&gt;AFAIK, Go is the only language that really takes engineering seriously: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;talks.golang.org&amp;#x2F;2012&amp;#x2F;splash.article&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;talks.golang.org&amp;#x2F;2012&amp;#x2F;splash.article&lt;/a&gt;
If there are similar articles for other mainstream languages, I&amp;#x27;m certainly curious to read them and see how they hold up today!</text><parent_chain><item><author>gameswithgo</author><text>&amp;gt;Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans.&lt;p&gt;So have all languages, with wildly different philosophies about how to do that.  We collectively just don&amp;#x27;t have any idea what we are doing. Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.</text></item><item><author>Laremere</author><text>It seems reasonable to argue the exact opposite:  (edit: for clarification, I think this argument is roughly equal in strength to the parent.  My bias is definitely showing, but my main point is that knowing which will be true is hard.)&lt;p&gt;Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans.  It mostly remixes what has proven to work into a cohesive package.  It&amp;#x27;s only as large as it absolutely needs to be (so new devs can learn it quickly), and has a strong focus on developer UX (gofmt, build speed, godoc).&lt;p&gt;Rust on the other hand is a far more ambitious language.  It&amp;#x27;s trying to statically solve many types of problems which are typically solved through testing and experience.  Using Rust productively requires much more Rust specific learning.  With how Rust is changing and having multiple approaches  to things as the language is defined, long living code bases are going to accrue different methodologies from whatever was popular when each component was written.&lt;p&gt;I think in 10 years a few experienced devs will do to Rust what Go did to C:  Take the bits that obviously worked well, add a few ideas from other languages to soften some rough corners, and present it is a smaller, easy to use package.  Though I also in general hope old languages are being replaced by new languages, as that must happen if as an industry we are getting better at building software.  But also because I&amp;#x27;m making a programming language and I have to believe I&amp;#x27;ve found room for improvement for that to be a good idea.</text></item><item><author>brundolf</author><text>I think there&amp;#x27;s a lot of truth to this, but I&amp;#x27;m going to make an additional suggestion that I&amp;#x27;ll readily admit is biased by my own feelings:&lt;p&gt;I think Go is in a honeymoon phase and people will hate it in 10 years; I think Rust will continue to be liked even when it&amp;#x27;s a legacy language (perhaps no language can continue being &lt;i&gt;loved&lt;/i&gt; once it becomes &amp;quot;brown&amp;quot;, but I think Rust will be a lot less dreaded than others).&lt;p&gt;Go, like Ruby (mentioned at the end of the article), is optimized for &lt;i&gt;building&lt;/i&gt;. You can do things quickly and easily with minimal ceremony. Some people love that. But that&amp;#x27;s exactly the trait that&amp;#x27;s starting to weigh on Ruby, and it&amp;#x27;s exactly the trait that has put PHP and Perl in the &amp;quot;dread&amp;quot; category over time (remember when people were in love with those?).&lt;p&gt;Rust on the other hand is optimized for &lt;i&gt;maintaining&lt;/i&gt; (it&amp;#x27;s right there in the name: software should be allowed to become old and &amp;quot;collect rust&amp;quot;). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can&amp;#x27;t do - you even know whether it&amp;#x27;s allowed to mutate an object you&amp;#x27;re passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }.&lt;p&gt;This kind of forethought is what makes a language that survives the honeymoon phase.</text></item></parent_chain></comment><story><title>Green vs. Brown Programming Languages</title><url>https://earthly.dev/blog/brown-green-language/</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>bccdee</author><text>&amp;gt; Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.&lt;p&gt;This is what happened with Python. It provided a distinct productivity advantage over C &amp;amp; C++, and now no one writes web apps in C++ anymore. Granted, it&amp;#x27;s not just Python anymore, but newer languages learned from Python&amp;#x27;s success.</text><parent_chain><item><author>gameswithgo</author><text>&amp;gt;Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans.&lt;p&gt;So have all languages, with wildly different philosophies about how to do that.  We collectively just don&amp;#x27;t have any idea what we are doing. Clearly nobody has stumbled on a big win or one particular language would start dominating the industry due to the productivity bump.</text></item><item><author>Laremere</author><text>It seems reasonable to argue the exact opposite:  (edit: for clarification, I think this argument is roughly equal in strength to the parent.  My bias is definitely showing, but my main point is that knowing which will be true is hard.)&lt;p&gt;Go was built explicitly to solve the real everyday problems of working in a large code base, largely driven directly by experience of several industry titans.  It mostly remixes what has proven to work into a cohesive package.  It&amp;#x27;s only as large as it absolutely needs to be (so new devs can learn it quickly), and has a strong focus on developer UX (gofmt, build speed, godoc).&lt;p&gt;Rust on the other hand is a far more ambitious language.  It&amp;#x27;s trying to statically solve many types of problems which are typically solved through testing and experience.  Using Rust productively requires much more Rust specific learning.  With how Rust is changing and having multiple approaches  to things as the language is defined, long living code bases are going to accrue different methodologies from whatever was popular when each component was written.&lt;p&gt;I think in 10 years a few experienced devs will do to Rust what Go did to C:  Take the bits that obviously worked well, add a few ideas from other languages to soften some rough corners, and present it is a smaller, easy to use package.  Though I also in general hope old languages are being replaced by new languages, as that must happen if as an industry we are getting better at building software.  But also because I&amp;#x27;m making a programming language and I have to believe I&amp;#x27;ve found room for improvement for that to be a good idea.</text></item><item><author>brundolf</author><text>I think there&amp;#x27;s a lot of truth to this, but I&amp;#x27;m going to make an additional suggestion that I&amp;#x27;ll readily admit is biased by my own feelings:&lt;p&gt;I think Go is in a honeymoon phase and people will hate it in 10 years; I think Rust will continue to be liked even when it&amp;#x27;s a legacy language (perhaps no language can continue being &lt;i&gt;loved&lt;/i&gt; once it becomes &amp;quot;brown&amp;quot;, but I think Rust will be a lot less dreaded than others).&lt;p&gt;Go, like Ruby (mentioned at the end of the article), is optimized for &lt;i&gt;building&lt;/i&gt;. You can do things quickly and easily with minimal ceremony. Some people love that. But that&amp;#x27;s exactly the trait that&amp;#x27;s starting to weigh on Ruby, and it&amp;#x27;s exactly the trait that has put PHP and Perl in the &amp;quot;dread&amp;quot; category over time (remember when people were in love with those?).&lt;p&gt;Rust on the other hand is optimized for &lt;i&gt;maintaining&lt;/i&gt; (it&amp;#x27;s right there in the name: software should be allowed to become old and &amp;quot;collect rust&amp;quot;). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can&amp;#x27;t do - you even know whether it&amp;#x27;s allowed to mutate an object you&amp;#x27;re passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }.&lt;p&gt;This kind of forethought is what makes a language that survives the honeymoon phase.</text></item></parent_chain></comment><story><title>Green vs. Brown Programming Languages</title><url>https://earthly.dev/blog/brown-green-language/</url></story>