A corollary is that SQLite is as ubiquitous to structured storage as JavaScript is to programming and it too lacks the exact decimal representation available as DECIMAL(precision, scale) in other SQL engines.
These are not fatal flaws, IMO, just gaps in need of attention.
JS is already very popular in finance, decimal types aren’t always needed for monetary values, floats are often fine (or computations can be done on the backend).
We usually store the values as longs and apply the decimal marker only when showing to the user. Floats are fine when it's just long to float. But any operation between two floats is a mistake.
Not for financial modelling which is the bulk of work in the front office. Everything is calculated as floats for performance reasons, no model is accurate enough for floating point error to matter.
Decimal shouldn't be part of the interpreter. Even Python doesn't do that.
JS needs operator overloading so that it can have decimals, rationals, ndarrays, automatic differentiation, etc. Unfortunately operator overloading is a dirty word for most of the webblubs who use JS. I've given up hope of that ever changing.
Yeah, operator overloading would be a nice welcome change, and in the end the interpreter already does something similar because of all the coercion rules... Considering how JavaScript works behind the curtain, it seems to me that it wouldn't be such a huge change to just do something like Python's __add__ magic method
JavaScript inherited the abysmal standard library support of Lisp language families and poor support for domain specific use cases of Java. The situation has been improving, but with the ”never break the backwards compatibility” of the web browsers on the driver seat, JavaScript will never be like Python or Julia for the data science use cases.
I don't think decimal is that big a deal for financial programming. When $0.01 accuracy matters, you just build your data structures around cents instead of dollars and get on with your life.
Right, but then you get "and what about tenths of a cent?". I've worked on projects where the necessary precision changed over time, and it's a lot easier to update your database columns to `DECIMAL(9,2)` to `DECIMAL(10,3)` than to update every place in your code where you're going from cents to mills.
Obviously, there's still significant testing to do to make sure that formerly correct code still rounds as expected, but if you're using a decimal structure like most BigDecimal ones, in memory you're already using arbitrary precision until storage anyway. Which I've done using stuff like decimal.js in JS, too, as it happens. But having it in core is the happy path for a lot of folks who don't already know that this is the way to go.
as I said before, V8 + dynamic language + better math support = perfect environment for many applications out there