There's a snag in making the correct choices of course.
What are correct choices now, turn into incorrect choices tomorrow.
Node/Npm is filled with incorrect choices right now that they're keeping around to keep backwards compatibility, and there's no way they're going to do a quick break à la Python 2 -> 3, instead we have a slow transition leaving us with:
- CommonJS instead of ESM
- No permission system
- Callback based APIs (Which have luckily been getting replaced with promise based APIs)
- No built-in node-version manager (e.g. nvm)
- etc...
But as the language evolves, we gain new capabilities that the runtime will take a really long time to adapt to. Looking ahead, these feature will likely change what we want in a runtime's APIs.
- Promise cancellation
- Better stream APIs
- Explicit Resource Management (the `using` keyword, like D's `scope(exit)` and Go's `defer`)
- Records and Tuples (to make certain data immutable)
What are correct choices now, turn into incorrect choices tomorrow.
Node/Npm is filled with incorrect choices right now that they're keeping around to keep backwards compatibility, and there's no way they're going to do a quick break à la Python 2 -> 3, instead we have a slow transition leaving us with:
- CommonJS instead of ESM
- No permission system
- Callback based APIs (Which have luckily been getting replaced with promise based APIs)
- No built-in node-version manager (e.g. nvm)
- etc...
But as the language evolves, we gain new capabilities that the runtime will take a really long time to adapt to. Looking ahead, these feature will likely change what we want in a runtime's APIs.
- Promise cancellation
- Better stream APIs
- Explicit Resource Management (the `using` keyword, like D's `scope(exit)` and Go's `defer`)
- Records and Tuples (to make certain data immutable)
- etc...