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.
Yes of course. If people don't want democracy anymore what would be a better way to end it than with a vote?
Also though, just because he wins doesn't mean he can actually deliver that promise. Most democracies have multiple layers of laws that would have to be passed after the election and would probably result in civil war without a super majority.
We park in an open team chat for hours at a time. And by open I mean its unscheduled, open for any dev and people just pop in and out as they desire. Someone is always screen sharing and we work on problems together, a new person can absorb or drive things, get realtime feedback. You can popout and just focus as needed, its casual.
Sort of like discord but its code instead of games.
Well you could if you have a line-unfeed. So by default it would do both but then in the uncommon case where you want overtype you could go back up.
A little late for that insight, if its even worthwhile, but typically I would optimize the common case by default and add features for doing advanced / uncommon things.
Where a schema applied runtime validation based on declarative syntax and which typescript could use to derive a `type` from