3 ms·

> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there's no r

> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there'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's explicit minimalist philosophy.

usrusr 8y ago
It's like building in special handling for a string type, exactly one instead of a catalog of library options. I'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 "minimalism" 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's also a form of minimalism, but not the one chosen by Go. 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.
- dtech 8y ago
  > I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type Scala uses Java's String exactly, but does define a few extra methods using its extension method functionality (called implicit class in Scala) Templates like s"This is a string with a $variable", are part of the language, but `s` is a stdlib feature. xxx"First $a $b Second" will be translated by the compiler to new StringContext(Array("First ", " ", " Second")).xxx(a, b) The standard library defines `StringContext.s`, but there's no restriction. Several SQL Libraries for example define `StringContext.sql`, to allow you to safely and type-checked embed SQL queries directly inside the code.
joppy 8y ago
Arrays, slices, hashtables, and channels are not supported natively by the processor, but Go still has them as primitives. Why not also add a number type which behaves in a sane, easy-to-understand, useful way?
CydeWeys 8y ago
This argument falls flat for me. Classes aren't supported natively by processors either, yet any number of OOP languages use them. It's generally nice when you can do simple things with the language'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'll all be the same. If commonly used data types like rationals, hashes, maps, strings, etc., aren't defined in the stdlib, then there'll be any number of different libraries to use them, and you'll have to potentially re-learn a lot of different unnecessary things when working on different codebases.
- passwd 8y ago
  Yes, standard library. I understood the poster above you to suggest they shouldn't be a part of language by that's used by default, for sure though it would be convenient to have centralized implementation.
  - makapuf 8y ago
    Exactly. Having a rational datatype as easily usable as float would make it easier to use as a default when you don't really need floats but just non integers. Which is often the case if you think about it. Automatic simplifications, literals (12.345122 is a rational, as well as 22/7)
aoeusnth1 8y ago
"X isn't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it" is a general-purpose argument to cherry pick which primitives you support and which ones you don't. Surely this isn't your actual reason you choose to oppose Rationals / BigIntegers as primitives while accepting hashmaps and arrays?
shakna 8y ago
Scheme has an explicit minimalist philosophy, so much so that when R6RS was released with too many conveniences it fractured the language and community. Now there's two specs, R7RS-small and R7RS-big, and they're far less popular than R5RS. Rationals are also the default number type. Lists are the base type used throughout Scheme, and can be used to implement arrays and hashmaps and whatnot, so Scheme doesn't really need them, you can just use a library. ... That didn't stop the committee adding types to the spec. Like records, promises and other complex types. What is useful and necessary to a language isn't defined by what the processor can natively do, or we'd only use registers, not arrays. And it isn't defined by a overbearing attitude towards one or more philosophies.

usrusr 8y ago

It's like building in special handling for a string type, exactly one instead of a catalog of library options. I'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 "minimalism" 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's also a form of minimalism, but not the one chosen by Go. 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.

dtech 8y ago
> I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type Scala uses Java's String exactly, but does define a few extra methods using its extension method functionality (called implicit class in Scala) Templates like s"This is a string with a $variable", are part of the language, but `s` is a stdlib feature. xxx"First $a $b Second" will be translated by the compiler to new StringContext(Array("First ", " ", " Second")).xxx(a, b) The standard library defines `StringContext.s`, but there's no restriction. Several SQL Libraries for example define `StringContext.sql`, to allow you to safely and type-checked embed SQL queries directly inside the code.

joppy 8y ago

Arrays, slices, hashtables, and channels are not supported natively by the processor, but Go still has them as primitives. Why not also add a number type which behaves in a sane, easy-to-understand, useful way?

CydeWeys 8y ago

This argument falls flat for me. Classes aren't supported natively by processors either, yet any number of OOP languages use them. It's generally nice when you can do simple things with the language'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'll all be the same. If commonly used data types like rationals, hashes, maps, strings, etc., aren't defined in the stdlib, then there'll be any number of different libraries to use them, and you'll have to potentially re-learn a lot of different unnecessary things when working on different codebases.

passwd 8y ago
Yes, standard library. I understood the poster above you to suggest they shouldn't be a part of language by that's used by default, for sure though it would be convenient to have centralized implementation.
- makapuf 8y ago
  Exactly. Having a rational datatype as easily usable as float would make it easier to use as a default when you don't really need floats but just non integers. Which is often the case if you think about it. Automatic simplifications, literals (12.345122 is a rational, as well as 22/7)

aoeusnth1 8y ago

"X isn't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it" is a general-purpose argument to cherry pick which primitives you support and which ones you don't. Surely this isn't your actual reason you choose to oppose Rationals / BigIntegers as primitives while accepting hashmaps and arrays?

shakna 8y ago

Scheme has an explicit minimalist philosophy, so much so that when R6RS was released with too many conveniences it fractured the language and community. Now there's two specs, R7RS-small and R7RS-big, and they're far less popular than R5RS. Rationals are also the default number type. Lists are the base type used throughout Scheme, and can be used to implement arrays and hashmaps and whatnot, so Scheme doesn't really need them, you can just use a library. ... That didn't stop the committee adding types to the spec. Like records, promises and other complex types. What is useful and necessary to a language isn't defined by what the processor can natively do, or we'd only use registers, not arrays. And it isn't defined by a overbearing attitude towards one or more philosophies.