AFAIK TypeScript's type system can do everything in OCaml -- it's extremely expressive -- but it's dis-similar in that it doesn't use the types to compile to native code. I view that as a downside because JITs are unpredictable and also huge.
It has early return/break. The syntax is pretty conventional, with the usual JS weirdness that everyone has to know.
> AFAIK TypeScript's type system can do everything in OCaml -- it's extremely expressive
Extremely expressive and unsound. And not just in a trivial "escape hatches exist but you should never use them" way - until you've been burned enough it's not at all obvious which operations are unsafe, and there are a lot of them.
I think if you're writing code from scratch, this doesn't really apply -- I'm talking about prototyping language implementations without any libraries at all, sorta like you would do with OCaml from a textbook (e.g. TAPL by Pierce)
(I'm aware of all the terrible experiences people have with TypeScript in the NPM ecosystem. But TypeScript is a big, mature tool and you can use it in more than 1 way.)
I just noticed the 'deno check' command I'm using turns strict mode on by default, so that's good.
All widely used gradual type systems are unsound because they have to interoperate with untyped code, and the dynamic checks to make it sound are too expensive.
But code written from scratch doesn't have that issue. I'd be interested in a counterexample -- is there a code snippet that passes the strict mode of the compiler, and doesn't interoperate with untyped code, but produces an unexpected runtime error?
I guess by "unexpected" I mean that, at runtime, an operation is performed on a value which is not allowed, and the program fails
---
I googled and found this -- https://effectivetypescript.com/2021/05/06/unsoundness/ -- not sure I agree with some points, e.g. array out of bounds isn't unsoundness! The OPERATION is legal, but the data isn't, which isn't something that any type system will tell you.
Similar to divide by zero -- a runtime error does not imply unsoundness.
Also, casts can produce unexpected runtime errors by definition -- that's why they are casts, and you have to opt in! Bad article.
> But code written from scratch doesn't have that issue. I'd be interested in a counterexample -- is there a code snippet that passes the strict mode of the compiler, and doesn't interoperate with untyped code, but produces an unexpected runtime error?
You'd think so, right? But no, typescript is deliberately unsound in ways that have nothing to do with gradual typing. Here are a few examples.
Signatures written in method syntax are bivariant, which is not correct
interface Unsound {
f(x: number | string): number
}
interface Unsound2 {
f(x: number): number
}
const a: Unsound2 = { f: (x: number) => x }
const b: Unsound = a
const c: number = b.f("not a number")
Type predicate results survive mutation
const hasA = (x: object): x is { a: unknown } => "a" in x
const deleteA = (x: { a: unknown }) => {
delete x.a
}
const unsound = (x: object) => {
if (hasA(x)) {
deleteA(x)
return x.a
} else {
return "no a"
}
}
Many stdlib types are incorrect. JSON stuff is particularly bad: JSON.parse and Body.json() both return `any`.
You can spread things that aren't objects
const unsound = <X,Y>(x: X, y: Y): X & Y => ({...x, ...y})
const bad: never = unsound(5, 4)
(And even for objects, `X & Y` is not the correct type when you have overlapping keys)
Anything with optional fields can be widened incorrectly
const unsound = <T extends { x: number }>(t: T): { x: number, y?: number } => t
const bad: number | undefined = unsound({ x: 5, y: "not a number" }).y
Assignment doesn't handle `readonly` properly
interface Readonly {
readonly x: number
}
interface Mutable {
x: number
}
const a: Readonly = Object.freeze({x: 5 })
const b: Mutable = a
b.x = 4
> The OPERATION is legal, but the data isn't, which isn't something that any type system will tell you.
There are some that will, though unfortunately none that are really production-ready yet.
Great examples, thanks!! I typed them all into the TypeScript playground.
I agree this is weird, and seems to follow from TypeScript's heritage as "trying to describe whatever dynamic JS does"
I mean that's probably why I didn't use it for >10 years (in addition to its JS heritage). But I did find that there is an interesting subset, at least for playing around.
I think the JSON.parse() issue is fundamental -- it's not clear what they could have done better, and static languages don't really do better. There is a fundamental problem there -- type systems are interior to a process, while data is exterior (https://www.oilshell.org/blog/2023/06/ysh-design.html)
> I think the JSON.parse() issue is fundamental -- it's not clear what they could have done better, and static languages don't really do better.
The best solution, IMO, is to give up on "no type-directed emit" (which harms the language in lots of other ways as well) and derive appropriate parsers at compile-time. Parsing malformed data should fail immediately, not just when you try to use the broken parts. This is a solved problem in C#, C++, Haskell, and no doubt many other languages.
Failing that, it should return an appropriate `JSON` type. Something along the lines of
type Field = string | number | boolean | null | JSON
type JSON = {[key in string]?: Field } | Field[]
Have you had a look at Coconut? I don't know if it'll push all your buttons but whenever I hear someone who's reasonably content with Python but wants more FP goodies I always think of it. https://github.com/evhub/coconut . It's basically a superset of Python3 that transpiles into Python3 and is compatible with MyPy. I don't think I'd code Python w/o it ever again assuming I had the choice. The biggest negative for me is that there's no IDE support for the language last I looked, though of course you can work with the transpiler output (plain Python) in your favorite Python IDE. It might be fun to play around with, I know that I really enjoyed it but then I got spoiled by the language+tooling of Scala3, but if you don't have that option ...
I actually want the imperative Python style, but with sum types. So it's more like "Rust with GC" I suppose.
I used to write in a functional style, and then I wrote Python for decades, and my brain flipped. Now I like imperative code :) I guess it's all the usual things about liking break / continue / early return, local mutation, flat code rather than nested code, etc.
I wanted to be a fan of TypeScript and get to use it daily on my job, but actual experience made me dislike the language. I think you already know the pain of external libraries (Express in my case) since you mentioned the ecosystem baggage, and the lack of pattern matching is another big minus for me.
Wish I had the capacity of time and energy to create this dream language of mine too.
Roc lang seems to be building up to what I desire. But we shall see. At the end of the day, picking one of the mainstream runtimes ids the safest bet. F# if we want to enjoy some fun but stay pragmatic.
Not just you, me too! In fact it’s why I went in deep on Reason when it arrived initially. Shame it never really got traction.