<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>jdmichal</author><text>&amp;gt; If you have pointers, they sometimes have to start the life uninitialized (i.e. with a value of 0) hence nil pointers.&lt;p&gt;Maybe at the machine level. But there&amp;#x27;s nothing that stops a programming language a few levels above machine from requiring that every pointer be initialized with a reference.&lt;p&gt;&amp;gt; As you admit yourself, the proposed solutions don&amp;#x27;t actually get rid of anything. At best they can force you to handle nil value by wrapping it in some wrapper.&lt;p&gt;The entire point is that a large majority of APIs don&amp;#x27;t WANT to accept or handle NIL, but have to, because the default is to allow it. And in some languages, such as Java, the only way to extend the type system is with reference types, making it impossible to ever not have to handle NIL. By reversing this decision, it becomes possible to specify both allowance and disallowance of NIL-valued parameters. Why you would ever argue against such expression is beyond me.</text><parent_chain><item><author>kkowalczyk</author><text>Hoare didn&amp;#x27;t invent 0-valued pointer. It was there since the beginning of time. Or at least the beginning of the CPUs.&lt;p&gt;People talk about getting rid of nil like it&amp;#x27;s actually possible.&lt;p&gt;It&amp;#x27;s not.&lt;p&gt;If you have pointers, they sometimes have to start the life uninitialized (i.e. with a value of 0) hence nil pointers.&lt;p&gt;As you admit yourself, the proposed solutions don&amp;#x27;t actually get rid of anything. At best they can force you to handle nil value by wrapping it in some wrapper.&lt;p&gt;Guess what - if you have that kind of discipline, you can do the same in C++.&lt;p&gt;Why aren&amp;#x27;t people doing that?&lt;p&gt;Because it comes at a cost. There&amp;#x27;s a cost to the wrapper and when it comes down to it, you still have to write the code to handle the nil pointer whether you&amp;#x27;re using a wrapper or a raw pointer.&lt;p&gt;It just doesn&amp;#x27;t buy you much.&lt;p&gt;Finally, fixing crashes caused by referencing a null pointer is downright trivial. Spend a few weeks chasing a memory corruption caused by multi-threading and you&amp;#x27;ll come to a conclusion that fixing a null pointer crashes (which can be done just by looking at the crashing callstack most of the time) is not such a big deal after all.</text></item><item><author>nostrademons</author><text>My biggest beef with the Go typesystem is that they didn&amp;#x27;t get rid of nil.  Tony Hoare (the guy who invented null) has acknowledged they were his &amp;quot;billion dollar mistake&amp;quot; [1], common practice in Java and Haskell is moving away from them, and yet Go included them anyway - in a language that&amp;#x27;s supposed to be robust because you&amp;#x27;re supposed to handle every case.  The Maybe (or @Nullable) type is a much better idea, because it flips the default from &amp;quot;any variable may be null&amp;quot; to &amp;quot;only variables explicitly declared as such may be null&amp;quot;.&lt;p&gt;[1] &lt;a href=&quot;http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.infoq.com&amp;#x2F;presentations&amp;#x2F;Null-References-The-Billi...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Go’s Type System Is An Embarrassment</title><url>https://functionwhatwhat.com/go%E2%80%99s-type-system-is-an-embarrassment/</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>nostrademons</author><text>As others have pointed out, I&amp;#x27;m not talking about nil as the zero-valued pointer at the hardware level.  I&amp;#x27;m talking about nil as the additional member of every type in the language&amp;#x27;s typesystem.  A typesystem is an abstraction over the hardware, designed to catch programmer errors and facilitate communication among programmers.  There&amp;#x27;s no reason it has to admit every possible value that the hardware can support.&lt;p&gt;And people &lt;i&gt;are&lt;/i&gt; applying that sort of discipline - see the NullObject pattern in any OO language, or the @Nullable&amp;#x2F;@NotNull annotations in Java, or !Object types in Google Closure Compiler.  The thing is, they have to apply it manually to every type, because the type system assumes the default is nullable.  That makes it an inconvenience, which makes a number of programmers not bother.&lt;p&gt;I&amp;#x27;ll agree that null pointers are comparatively easy to track down compared to memory corruption caused by multi-threading.  Threads are a broken programming model too, and if you want a sane life working with them you&amp;#x27;ll apply a higher-level abstraction like CSP, producer-consumer queues, SEDA, data-dependency graphs, or transactions on top of them.</text><parent_chain><item><author>kkowalczyk</author><text>Hoare didn&amp;#x27;t invent 0-valued pointer. It was there since the beginning of time. Or at least the beginning of the CPUs.&lt;p&gt;People talk about getting rid of nil like it&amp;#x27;s actually possible.&lt;p&gt;It&amp;#x27;s not.&lt;p&gt;If you have pointers, they sometimes have to start the life uninitialized (i.e. with a value of 0) hence nil pointers.&lt;p&gt;As you admit yourself, the proposed solutions don&amp;#x27;t actually get rid of anything. At best they can force you to handle nil value by wrapping it in some wrapper.&lt;p&gt;Guess what - if you have that kind of discipline, you can do the same in C++.&lt;p&gt;Why aren&amp;#x27;t people doing that?&lt;p&gt;Because it comes at a cost. There&amp;#x27;s a cost to the wrapper and when it comes down to it, you still have to write the code to handle the nil pointer whether you&amp;#x27;re using a wrapper or a raw pointer.&lt;p&gt;It just doesn&amp;#x27;t buy you much.&lt;p&gt;Finally, fixing crashes caused by referencing a null pointer is downright trivial. Spend a few weeks chasing a memory corruption caused by multi-threading and you&amp;#x27;ll come to a conclusion that fixing a null pointer crashes (which can be done just by looking at the crashing callstack most of the time) is not such a big deal after all.</text></item><item><author>nostrademons</author><text>My biggest beef with the Go typesystem is that they didn&amp;#x27;t get rid of nil.  Tony Hoare (the guy who invented null) has acknowledged they were his &amp;quot;billion dollar mistake&amp;quot; [1], common practice in Java and Haskell is moving away from them, and yet Go included them anyway - in a language that&amp;#x27;s supposed to be robust because you&amp;#x27;re supposed to handle every case.  The Maybe (or @Nullable) type is a much better idea, because it flips the default from &amp;quot;any variable may be null&amp;quot; to &amp;quot;only variables explicitly declared as such may be null&amp;quot;.&lt;p&gt;[1] &lt;a href=&quot;http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.infoq.com&amp;#x2F;presentations&amp;#x2F;Null-References-The-Billi...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Go’s Type System Is An Embarrassment</title><url>https://functionwhatwhat.com/go%E2%80%99s-type-system-is-an-embarrassment/</url></story>