6 ms·

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend de

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one, e.g. in the browser console. Develop the language instead of tons of incompatible tools.

nephy 2y ago
I literally use BigInt on the backend every single day at work lol.
3np 2y ago
This stood out to me as well. Proper decimal type would be my #1 missing language feature, seconded by a standardized runtime implementation of the same.
xscott 2y ago
That part caught my attention too. It reminds me of the discussion to remove complex numbers from Go. Funny enough, compiler writers can't even imagine why you would want BigInt or Complex, because those aren't useful for writing compilers.
- Kwpolska 2y ago
  The problem with Google compiler developers is that they will do a search of the google3 repository, find no uses (because Google doesn’t do any advanced math, for example) and declare the language feature to be useless.
  - Timwi 2y ago
    Which is ironic because I use Google Sheets a lot and occasionally run into problems when it doesn't support BigInt calculations. Sheets is the best excuse Google has for keeping BigInt support in the language.
    - Kwpolska 2y ago
      Excel does not support BigInt either, so Google has no reason to implement it in their cheap imitation.
- em-bee 2y ago
  one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast. in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.
  - xscott 2y ago
    I used LPC a long time ago on an LP Mud, so Pike has always had a fond spot in the back of my mind, even if I don't use it now. However, that works for int and bigint, but Number (double precision) can represent numbers that BigInt can not, and BigInt can represent numbers which Number can not. There isn't a graceful way to automatically promote/degrade one to the other in all cases, and a silent conversion will do the wrong thing in many cases.
    - em-bee 2y ago
      heh, yeah, that's where i started too. i don't know how or even if LPC did it, but in pike the transition really is seamless. give it a try. as a naive user i can't even tell the difference (you can see it though if you compare typeof(1) vs typeof(20000000000000000000) (i hope that number is big enough))
  - the-smug-one 2y ago
    That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower https://en.wikipedia.org/wiki/Numerical_tower
    - xscott 2y ago
      Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
- dboreham 2y ago
  That's a general problem: languages end up having features that are only useful for writing compilers, and vice versa.
SigmundA 2y ago
Would help if it worked with JSON by default.
- nephy 2y ago
  Yeah, it’s annoying, but the polyfill is like 3 lines.
davexunit 2y ago
Yeah it was really concerning to hear someone from Google saying that BigInt doesn't have a use case. It is both used and important!
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
styfle 2y ago
I used BigInt to implement xxhash recently.
CottonMcKnight 2y ago
Example: Sindre Sorhus' FNV library uses BigInt to support hashes up to 1024 bits. It's quite popular (for a hashing algorithm) on NPM, with 80k+ downloads / week. https://www.npmjs.com/package/@sindresorhus/fnv1a https://www.npmjs.com/package/@sindresorhus/fnv1a

nephy 2y ago

I literally use BigInt on the backend every single day at work lol.

3np 2y ago

This stood out to me as well. Proper decimal type would be my #1 missing language feature, seconded by a standardized runtime implementation of the same.

xscott 2y ago

That part caught my attention too. It reminds me of the discussion to remove complex numbers from Go. Funny enough, compiler writers can't even imagine why you would want BigInt or Complex, because those aren't useful for writing compilers.

Kwpolska 2y ago
The problem with Google compiler developers is that they will do a search of the google3 repository, find no uses (because Google doesn’t do any advanced math, for example) and declare the language feature to be useless.
- Timwi 2y ago
  Which is ironic because I use Google Sheets a lot and occasionally run into problems when it doesn't support BigInt calculations. Sheets is the best excuse Google has for keeping BigInt support in the language.
  - Kwpolska 2y ago
    Excel does not support BigInt either, so Google has no reason to implement it in their cheap imitation.
em-bee 2y ago
one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast. in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.
- xscott 2y ago
  I used LPC a long time ago on an LP Mud, so Pike has always had a fond spot in the back of my mind, even if I don't use it now. However, that works for int and bigint, but Number (double precision) can represent numbers that BigInt can not, and BigInt can represent numbers which Number can not. There isn't a graceful way to automatically promote/degrade one to the other in all cases, and a silent conversion will do the wrong thing in many cases.
  - em-bee 2y ago
    heh, yeah, that's where i started too. i don't know how or even if LPC did it, but in pike the transition really is seamless. give it a try. as a naive user i can't even tell the difference (you can see it though if you compare typeof(1) vs typeof(20000000000000000000) (i hope that number is big enough))
- the-smug-one 2y ago
  That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower https://en.wikipedia.org/wiki/Numerical_tower
  - xscott 2y ago
    Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
dboreham 2y ago
That's a general problem: languages end up having features that are only useful for writing compilers, and vice versa.

SigmundA 2y ago

Would help if it worked with JSON by default.

nephy 2y ago
Yeah, it’s annoying, but the polyfill is like 3 lines.

davexunit 2y ago

Yeah it was really concerning to hear someone from Google saying that BigInt doesn't have a use case. It is both used and important!

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

styfle 2y ago

I used BigInt to implement xxhash recently.

CottonMcKnight 2y ago

Example: Sindre Sorhus' FNV library uses BigInt to support hashes up to 1024 bits. It's quite popular (for a hashing algorithm) on NPM, with 80k+ downloads / week. https://www.npmjs.com/package/@sindresorhus/fnv1a https://www.npmjs.com/package/@sindresorhus/fnv1a