Hacker News Reader

Comment by dlbucci | Hacker News Reader

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`...

EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with numbers or bigints. In that case, it's actually probably good that you can easily tell the difference using typeof, without requiring some hacky fix like `Array.isArray`.

It does mean that "don't mix numbers and bigints" is going to become very popular JS advice soon.

View on HN

To be fair, it really shouldn’t be conflated with ‘number’ - it isn’t the same thing, the behavior differs. And you can (and probably should) use small helper functions for these kinds of checks, pretty much for this kind of flexibility. Kind of curious what other libs (like lodash) will do.

If you're really going to do it right, that small function should also be published as npm package (isnumeric) that takes at least 2 other packages (isnumber and isbigint) as dependencies.

I’m super strongly against this concept actually, which you might gather from mention of lodash.

I think they were making a joke.

Obviously it was some degree of tongue-in-cheek, but I’m not really that amused, to be honest. It needs a leftpad reference or something.

I see I’ve struck a nerve of some kind so I’d just like to clarify that I am not sorry.

Anybody who thinks that's actually good (or even real) advice is going to write horrible code regardless, IMHO.

https://www.npmjs.com/browse/depended/is-number

That's horrifying, I thought the whole isNumber thing was a joke.

Do these guys assemble their application as hundreds (or thousands) of NPM packages containing single functions and then import them together? Because now I actually believe they are capable of it.

You might enjoy this as well: https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

And this: https://dev.to/leoat12/the-nodemodules-problem-29dc

I'm still holding out for an int type, I use a double about once a year but I'm completely insecure about using integer operations (e.g. div, mod, as an offset-based index) in javascript.

You can use w3c typed array stuff at least... though its obviously cumbersome.

Bitwise operators also coerce to integer, so they should roughly always be OK.

For code that actually needs bigints mixing numbers and bigints is just asking for horrible bugs like when a bunch of Twitter clients completely broke after 2^53 posts had been made.

By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint.

But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.

I don't know if that follows. I think it's reasonable to expect a piece of code that works with integer numbers to also work with bigints. But it's not really reasonable to expect it to work with anything that closely resembles a number. That sort of weak typing is much more problematic and should be avoided.

But I dunno, maybe it shouldn't be expected to work with bigints either. It's not a regular int, so I doubt people will start using these as array indices in for loops or what have you, so maybe it should be a different type...

But it's really not. Pretty major difference between floats and arbitrary precision, like how you'll get different arithmetic results passing in 42 vs 42n. Just like any language that doesn't let you mix float and integer operands. Also, what's even the return value?

You need to make a deliberate decision about your data, not deck the halls with just-in-case programming. The software you write will be much better for it.

Besides, even if you could justify a bunch of typeof checks and you were doing it everywhere, Javascript already has a way to spare you from repetitive code: a function.

Well, bigints are fine as array indices. However they are not interoperable with numbers in any type of arithmetic. I don't think it's reasonable to expect to use bigints in any place where one uses numbers.

"Regular int" is not a distinct type in javascript. There are now two numeric types: 64-bit floating point, and bigint.

Obligatory informational: JavaScript numbers are IEEE-754 standard. You get 53 bits of precision, but can still represent other numbers outside that range, and there are the usual issues relating to dealing with floats.

    Math.pow(2,53)
    // 9007199254740992
    Math.pow(2,53)+1
    // 9007199254740992
    Math.pow(2,53)+2
    // 9007199254740994
    0.1 + 0.2
    // 0.30000000000000004

> In an application, you have a canonical representation that you pass through your business logic.

Not if your code works with arbitrary inputs.

I have some collation sequences that I’ll need to tweak.

It seems to me that in applications where there is widespread use bigint, you would simply be doing `typeof a === 'bigint'`. And, in nearly all other applications, it would remain as simply `typeof a === 'number'`

That’s what we did for our financial and technical (science/math) backend services that use node.js. We just don’t use the built-in number/float libraries, instead using an abstraction library based on bignumber.js/decimal.js etc, consistently.

It may be a good thing, for historical/backward-compatibility reasons.

But there's no reason that fixed-size ints and IEEE floats can't be intermixed with arbitrary-size/precision numbers, even in a small language, such as Scheme:

https://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-...

Racket adds a bit more:

https://docs.racket-lang.org/reference/numbers.html

IIRC, Brendan Eich was aware of Scheme when he defined what's now known as JavaScript, but on a crazy-tight schedule, and JS wasn't intended to be an applications language.

You can't do arithmetic with numbers and bigints, so when would you ever accept a parameter that could either be a number or a bigint? The places that `typeof a === `number` || typeof a === 'bigint'` could be used seem rare to me.

What makes you think that, exactly?

The more I think about about it the less I like this new feature. They should have implemented BigInt as a class instead and rely on a transcoder to make algorithms easier to write.

Reply on news.ycombinator.com