It would be nice if the runtime validation was an ecmascript feature designed in such a way that typescript could infer the types for them automatically... Such as
schema Example { ... }
cosnt example: Example = new Example(unkonwnData)
Where a schema applied runtime validation based on declarative syntax and which typescript could use to derive a `type` from
I mostly agree, having every single type checked all the time like other static languages is not appropriate and probably not even a good idea but on the other hand it is also kind of annoying to have your validation code be divorced from your types totally.
For example suppose I have a web request coming in and I have essentially just a string of input coming in on the body. I have an expectation of what it needs to be but there is a step where it is of type `unknown` and I need to convert it into `IMyHandlerInput`. Just casting it is obviously a bad idea and so now I need to essentially use some kind of library such as ajv to do json schema or jtd validation, _then_ I can cast it into my interface.
This is all fine but it definitely feels redundant to me. It would be a cool _ecmascript_ feature to essentially support, not runtime types per-se but syntactic _validation_ which can also be used by typescript to derive types automatically.
This is totally hypothetical but I'm imagining something like this for example:
```ts
schema Example {
@min 0
id: number
@pattern /^\w+ \w+$/
name: string
@future
expiresAt: Date
}
const data: Example = new Example(JSON.parse(body))
```
Something that the JS runtime can use to allow developers to opt-in to extensible validation which can also be used by the typescript interpreter to essentially derive types.
It did still partially work but there was some friction with resolving types from ESM modules. For example in typescript+node if you're importing another module with esm you'd still have to import javascript like so:
```
import { Example } from "./example.js" // the actual file is example.ts
```
While in Deno you actually import the typescript file
```
import { Example } from "./example.ts"
```
That difference alone was enough to trip up the built-in typescript language tool and add friction.
Another thing is that Deno has a built in formatter / linter, you don't use a 3rd party tool like eslint, so having the ide just know how to do the linting and formatting is nice, the default typescript language plugin can't do that.
Also, Deno formats other file types including json, yaml and markdown.
I have nothing bad to say about the other two but Deno is pretty great, I'm hoping it topples node.js at least, it seems poised to do so. Really lookin forward to playing with deno deploy too.
Social science without social justice would probably just be science, with social justice it would not be science but political activism, bias and probably ultimately would lead to something more detrimental than what they're trying to prevent.
How it should be is accurate and truthful. The problem with trying to prevent "potential harms" is that the term is subjective and suppressing the truth for subjective reasons will cause a non-scientific result which can be even more harmful in the end.
Essentially it comes with a garbage collector which gets embedded into your binary as well as any other standard library calls you may need for fundamental features.
They don’t want the truth? Like teens get horny and start questioning about sex, but instead of treating it with the proper bodily function it is let’s ignore it and promote scare tactics that still to this day are effective.
God forbid you don’t want to have a unplanned pregnancy or worse.
