No, I don't think there really is. But to be execute is even more clear that it's just... executing the code, whereas I could maybe understand someone being confused that run implied some level of type checking.
This is misleading. It is not transpiling TS in JS, it is transpiling a subset of TS into JS. If my normal TS code can not be "executed" by Node, then it is not executing TS per definition but something else. If you are good with Node supporting and "executing" only a subset of TS and lacking useful features, that's fine. But don't tell people it is executing TypeScript. That's like me saying my rudimentary C++ compiler supports C++ while in reality only supporting 50%. People would be pissed if they figure it out once they try to run it on their codebase.
In my experience (albeit from about 4 years ago) having some kind of private package with pipenv (or even plain pip) was really annoying. We went the route of a private repo on Github rather than a private package repository, which maybe set us up for exactly that annoyance.
As someone curious about learning more about type systems, would you mind elaborating on 1.? I'm assuming you mean the formal definition of "sound", not just as a synonym for "sensible". Sound typing is often something handwaved away as not being particulary consequential in practice; what benefits have you seen there?
From the official website:
> Dart enforces a sound type system. This means you can't write code where a variable's value differs from its static type.
I know you didn't ask me but I think that not ensuring soudness is a feature because it allows the type system to wrap something that could work without it. Would you like unit tests if removing them would break your code? Maybe it's not a fair comparison, or maybe it is...
Not who you are replying to, but I started learning HTML/CSS right when HTML5 and CSS3 had just come out, so I do have somewhat of a soft spot for these
reply