<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>fyfy18</author><text>&amp;gt; dependency pathing is a pain in most other languages&lt;p&gt;This has been a solved problem in the Ruby community for nearly a decade thanks to bundler. When I first started writing Ruby it had all the same problems as other languages, there were various attempts to solve it (similar to virtualenvs) but nothing really worked properly. Then bundler came along, and even from early releases it had pretty much figured it out.&lt;p&gt;The way it works is by having a human generated manifest file with a list of libraries you think you need (Gemfile) and the tool will then fetch those libraries (they can be installed in a vendor directory or globally for the specific Ruby version). You don&amp;#x27;t need to specify versions or deps (but can if required), as when the tool runs it will generate another manifest file (Gemfile.lock) which lists the versions of all libraries and their dependencies. Both files should be committed, so when you coworker checks out the project they know they have the exact same versions as you. There&amp;#x27;s another command to list outdated libraries, and to upgrade all or a specific library later.&lt;p&gt;The tooling checks the versions of libraries on every execution (unlike npm or yarn) and spits out an error if your local versions don&amp;#x27;t match the manifest. It automatically creates wrappers around binaries so you don&amp;#x27;t need to prefix commands from other tooling. There&amp;#x27;s built in support for installation in a deployment environment, so you don&amp;#x27;t install testing libraries there.&lt;p&gt;Together with tools like rvm&amp;#x2F;rbenv, it makes managing multiple Ruby versions and multiple projects, just work.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.cloudcity.io&amp;#x2F;blog&amp;#x2F;2015&amp;#x2F;07&amp;#x2F;10&amp;#x2F;how-bundler-works-a-history-of-ruby-dependency-management&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.cloudcity.io&amp;#x2F;blog&amp;#x2F;2015&amp;#x2F;07&amp;#x2F;10&amp;#x2F;how-bundler-works-a...&lt;/a&gt;</text><parent_chain><item><author>kortex</author><text>When I first got into go, a few of the Go Opinions kinda rubbed me the wrong way.&lt;p&gt;- I have to source GOPATH in my rc files? Annoying.&lt;p&gt;- File paths are network URI&amp;#x27;s? Ugly.&lt;p&gt;- I have to deal with every err != nil? Verbose.&lt;p&gt;But over time I&amp;#x27;ve grown to love go more than almost any language (python is still bae, especially with type hints, and even then, it&amp;#x27;s close).&lt;p&gt;- dependency pathing is a pain in most other languages. Singular source of truth is great (I&amp;#x27;ve had virtualenvs leak and cmake do bizarre things when multiple libs are on the file tree)&lt;p&gt;- host&amp;#x2F;paths are file&amp;#x2F;paths. I love this pattern now. It&amp;#x27;s just so obvious and natural.&lt;p&gt;- ok the err != nil still drives me nuts. But it drives me to write things in a way where I don&amp;#x27;t need to deal with errors as much. Reduces fractal complexity and paths through the code. It also forces &amp;quot;the buck stops here&amp;quot; sort of pattern where you have some atrium which is resiliant and is where most errors bubble up to</text></item></parent_chain></comment><story><title>Go&apos;s Tooling Is an Undervalued Technology</title><url>https://nullprogram.com/blog/2020/01/21/</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>gtycomb</author><text>I am an average Go programmer, so I may not be deep into Go as you might be. However the mention of GOPATH catches my eye. All my issues with GOPATH went away for me when I started using the Go Modules: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.golang.org&amp;#x2F;using-go-modules&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.golang.org&amp;#x2F;using-go-modules&lt;/a&gt;. Also Go&amp;#x27;s approach to err is one the reasons I started gravitating to Go -- my old Go code is more readable because of the verbose (error as strings in my code) and hence easier to maintain. Go is a surprisingly practical language for distributed, system oriented, undertakings I&amp;#x27;d say</text><parent_chain><item><author>kortex</author><text>When I first got into go, a few of the Go Opinions kinda rubbed me the wrong way.&lt;p&gt;- I have to source GOPATH in my rc files? Annoying.&lt;p&gt;- File paths are network URI&amp;#x27;s? Ugly.&lt;p&gt;- I have to deal with every err != nil? Verbose.&lt;p&gt;But over time I&amp;#x27;ve grown to love go more than almost any language (python is still bae, especially with type hints, and even then, it&amp;#x27;s close).&lt;p&gt;- dependency pathing is a pain in most other languages. Singular source of truth is great (I&amp;#x27;ve had virtualenvs leak and cmake do bizarre things when multiple libs are on the file tree)&lt;p&gt;- host&amp;#x2F;paths are file&amp;#x2F;paths. I love this pattern now. It&amp;#x27;s just so obvious and natural.&lt;p&gt;- ok the err != nil still drives me nuts. But it drives me to write things in a way where I don&amp;#x27;t need to deal with errors as much. Reduces fractal complexity and paths through the code. It also forces &amp;quot;the buck stops here&amp;quot; sort of pattern where you have some atrium which is resiliant and is where most errors bubble up to</text></item></parent_chain></comment><story><title>Go&apos;s Tooling Is an Undervalued Technology</title><url>https://nullprogram.com/blog/2020/01/21/</url></story>