<story><title>Go 2, here we come</title><url>https://blog.golang.org/go2-here-we-come</url></story><parent_chain><item><author>dmurray</author><text>&amp;gt; Why not introduce a primitive type &amp;quot;num&amp;quot; for arbitrary precision rational numbers instead?&lt;p&gt;Rationals aren&amp;#x27;t supported natively by processors, so there&amp;#x27;s no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go&amp;#x27;s explicit minimalist philosophy.</text></item><item><author>13415</author><text>Makes no sense to me to redefine existing integer types. Why not introduce a primitive type &amp;quot;num&amp;quot; for arbitrary precision rational numbers instead?&lt;p&gt;As a long-time Racket and Scheme user, I&amp;#x27;d say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithmetics.</text></item><item><author>joppy</author><text>I’m hoping that &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;golang&amp;#x2F;go&amp;#x2F;issues&amp;#x2F;19623&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;golang&amp;#x2F;go&amp;#x2F;issues&amp;#x2F;19623&lt;/a&gt; will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases.&lt;p&gt;It is bizarre to me that languages boasting built-in language-level data structures like lists, hashtables, etc are content to just leave us with the bare minimum support of &lt;i&gt;numbers&lt;/i&gt;, being basically whatever the hardware thinks a number is. The semantics of integers and fractions are perfect, and everybody already knows them. On the other hand, overflows in int32’s are weird, and if your idea of a fraction is a floating-point number, then you can never have something like (5&amp;#x2F;3)*6 evaluate to 10 exactly.&lt;p&gt;To be clear, I think fixed-width integers and floating-point numbers have their place, I just see no reason why they should be the default.</text></item></parent_chain><comment><author>CydeWeys</author><text>This argument falls flat for me.  Classes aren&amp;#x27;t supported natively by processors either, yet any number of OOP languages use them.&lt;p&gt;It&amp;#x27;s generally nice when you can do simple things with the language&amp;#x27;s built-in standard library.  I tend to prefer languages with more powerful standard libraries because it means that you can more easily move across codebases since they&amp;#x27;ll all be the same.  If commonly used data types like rationals, hashes, maps, strings, etc., aren&amp;#x27;t defined in the stdlib, then there&amp;#x27;ll be any number of different libraries to use them, and you&amp;#x27;ll have to potentially re-learn a lot of different unnecessary things when working on different codebases.</text></comment>
<story><title>Go 2, here we come</title><url>https://blog.golang.org/go2-here-we-come</url></story><parent_chain><item><author>dmurray</author><text>&amp;gt; Why not introduce a primitive type &amp;quot;num&amp;quot; for arbitrary precision rational numbers instead?&lt;p&gt;Rationals aren&amp;#x27;t supported natively by processors, so there&amp;#x27;s no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go&amp;#x27;s explicit minimalist philosophy.</text></item><item><author>13415</author><text>Makes no sense to me to redefine existing integer types. Why not introduce a primitive type &amp;quot;num&amp;quot; for arbitrary precision rational numbers instead?&lt;p&gt;As a long-time Racket and Scheme user, I&amp;#x27;d say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithmetics.</text></item><item><author>joppy</author><text>I’m hoping that &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;golang&amp;#x2F;go&amp;#x2F;issues&amp;#x2F;19623&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;golang&amp;#x2F;go&amp;#x2F;issues&amp;#x2F;19623&lt;/a&gt; will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases.&lt;p&gt;It is bizarre to me that languages boasting built-in language-level data structures like lists, hashtables, etc are content to just leave us with the bare minimum support of &lt;i&gt;numbers&lt;/i&gt;, being basically whatever the hardware thinks a number is. The semantics of integers and fractions are perfect, and everybody already knows them. On the other hand, overflows in int32’s are weird, and if your idea of a fraction is a floating-point number, then you can never have something like (5&amp;#x2F;3)*6 evaluate to 10 exactly.&lt;p&gt;To be clear, I think fixed-width integers and floating-point numbers have their place, I just see no reason why they should be the default.</text></item></parent_chain><comment><author>usrusr</author><text>It&amp;#x27;s like building in special handling for a string type, exactly one instead of a catalog of library options.&lt;p&gt;I&amp;#x27;d say that would fit in quite well with the brand of minimalism that Go is representing, keep the language simple and provide builtins where more convenience is needed. The opposite kind of &amp;quot;minimalism&amp;quot; would be providing tools to allow libraries to define what other languages can only support as special builtins. C++ and Scala went down that road, they minimize builtins by empowering libraries to replace them. That&amp;#x27;s also a form of minimalism, but not the one chosen by Go.&lt;p&gt;Tangent: now I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type it inherited from Java or if just reimplements those syntax extras in the standard library using implicits.</text></comment>