This might help with cleanup: https://github.com/tc39/proposal-explicit-resource-managemen...
But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...
I've never really had a problem with it, but I isolate such resources behind a wrapper, which makes cleanup easy. I just create a little higher-order function:
function doSomethingThatNeedsCleanup(fn) {
const thing = createTheThing();
try {
return fn(thing);
}
finally {
cleanUpTheThing(thing);
}
}
That's not really an issue with the type system, that's just coincidence and bad luck.
The signature of parseInt is:
parseInt(string: string, radix?: number | undefined): number
fn(element: string, index?: number | undefined, array?: string[] | undefined): any
I'm not sure what you expect the type system to do here. It works just fine at catching an actual type error, such as this:
console.log([10, 10, 10].map(parseInt)
Argument of type '(string: string, radix?: number | undefined) => number' is not assignable to parameter of type '(value: number, index: number, array: number[]) => number'.
Types of parameters 'string' and 'value' are incompatible.
Type 'number' is not assignable to type 'string'.
If that were true I'd not mind quite as much... but actually, parseInt takes two parameters and map passes three.
Again, this isn’t a type system issue. It’s both an API design issue and a poor programming hygiene issue. (Don’t pass bare functions if you don’t know what the parameters are.)
I mean, map always passes them in, so in that sense they aren't optional. Mixing that with functions that take in optional parameters, but aren't usually called with them, gives you a ticking time bomb, IMO. And double that danger when the language's type system allows you to call a function with more parameters than it could ever take.
> Don’t pass bare functions if you don’t know what the parameters are.
This is exactly the kind of thing I want my programming language's type system to catch for me, if I'm working in a language with a static type system like TS.
And even in dynamic languages, this is exactly the kind of thing I want my programming language to catch for me at runtime. Python does, for example.
Stuff like this - while it might fit JS and TS and make sense to some - makes absolutely no sense to me, and is why I simply look to other languages to fit my needs.
>> Don’t pass bare functions if you don’t know what the parameters are.
> This is exactly the kind of thing I want my programming language's type system to catch for me, if I'm working in a language with a static type system like TS.
Hows your compiler supposed to know you don't know what the parameters are?
In TS you really can't (that's my point and why I prefer to avoid the language) because of JS and API baggage. But just about every other static language that I've worked in can complain for this kind of thing.
> Hows your compiler supposed to know you don't know what the parameters are?
Why does the compiler care about what I know? The compiler itself knows what the function's parameters are and it can tell me that something seems wrong because I'm asking it to call a function that maxes out at 2 parameters with 3 parameters.
TS does catch this kind of thing in a lot of places. It just intentionally decides not to do it for these kinds of callbacks because of the same JS and API baggage.
> But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...
I've found that the basic NodeJS or Python works for most problems I've chosen. Not even with strong typing.
One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness.
I think O'Caml is closer to my ideal but the ecosystem isn't quite there. Maybe all it needs is time.