Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the examples given makes sense, since Symbol.specie messes with prototypical inheritance and is likely hard to secure as a result because that touches so much of JS as a whole.

BigInt failing to materialize I think has more to do with ergonomics around it, they’re a bit unwieldy and there aren’t able to be used with the built in Math object functions.

They also have zero JSON support out of the box which is a huge miss.

Honestly it should have been roadmapped to replace the built in Number type



Can't replace Number with BigInt as BigInt is orders of magnitude slower on certain operations. Try to do bitwise operations with BigInt, you'll see what I mean.


Hence roadmapped. You can’t today, certainly, it also can’t represent floating point numbers or be used with the Math object as noted.

But the idea is that it should have been proposed with a roadmap of what it would look like to have it eventually supplant Number


bigint cannot be replaced by regular number when working with arbitrarily large whole numbers. With regular numbers you will lose precision out of the range [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER]. If you try to implement such functionality via JS, it would be even much slower than the bigint native implementation. So, it's great to have such thing natively implemented.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: