521–530 of 570 posts
Earlier quoted context omitted.
Bun is pretty awesome. However, the node:crypto module still doesn't work 100%. So, I can't use it yet.
The parallel implementation they do uncovers a number of unexpected behaviors in the node implementation.
I just tried to sign some data with an RSA key, and the results differed in Node and Bun.
Earlier quoted context omitted.
This is true, but in other cases they added keywords in ways that could work with type stripping. For example, the `as` keyword for casts has existed for a long time, and type stripping could strip everything after the `as` keyword with a minimal grammar. When TypeScript added const declarations, they added it as `as const` so a type stripping could have still worked depending on how loosely it is implemented. I thin…
It can’t strip what’s after the as keyword without an up-to-date TS grammar, because `as` is an expression. The parser needs to know how to parse type expressions in order to know when the RHS of the `as` expression ends. Let’s say that typescript adds a new type operator “wobble T”. What does this desugar to? x as wobble T Without knowing about the new wobble syntax this would be parsed as `x as wobble; T` and desug…
Earlier quoted context omitted.
Even haskell will generate a runtime error for an out-of-bounds index main = putStrLn (["a", "b", "c"]!!4)
This is different. Neither flow, typescript, nor javascript generate a runtime error for an out of bounds index. It's explicitly allowed by the language. The result of the an OOB access of an array is specified to be `undefined`. The throw only happens later when the value is treated as the wrong type. I don't consider a runtime error to be a failure of the type system for OOB array access. But in javascript, it's ex…
This is like arguing that a null exception is fine because it's allowed by the language. If you get `undefined` when you expect another type, most future interaction are guaranteed to have JS throw because of the JS equivalent of a null pointer exception. They are technically different because a dynamic language runtime can prevent a total crash, but the effect on your web app is going to be essentially the same.
[1,2,3][4].toFixed(2)
Haskell has the ability to handle the error.
How do you recommend a compiler to detect out-of-bounds at compile time? It can certainly do this for our trivial example, but that example will also be immediately evident the first time you run the code too, so it's probably not worth the effort. What about the infinite number of more subtle variants?
Earlier quoted context omitted.
> In Python, I've even heard of people writing types in source code but never checking them This is my main approach. Type hints are wonderful for keeping code legible/sane without going into full static type enforcement which can become cumbersome for rapid development.
With this approach, do you still use Python's standard syntax for type hints? def mersenne(p: int): return 2**p - 1 Or, given there's no need for the type hints to be checker-friendly, do you make them more human-friendly, e.g: def mersenne(p: 'prime number'): return 2**p - 1
```
from typing import NewType
# Create a new type for some_prime SomePrime = NewType('SomePrime', int)
def process_prime(value: SomePrime) -> int: return value ```
However, this isn’t nearly as common as simply using a more descriptive argument name like “prime_number : int”
One of the big advantages to type hinting in Python is that it feeds the IDE a lot of information to increase auto-complete functionality, so you want to avoid things like p:”prime number”
Earlier quoted context omitted.
having written ocaml in production for a few years, i think soundness comes at a cost of dev ergonomics. at least with the type systems of today’s industry languages. it blows my mind weekly how ergonomic and flexible typescript’s type system is. it allows me to write great apis for my team mates. is it possible for the type checker to end up in an infinite loop or for a junior developer to abuse “as”? absolutely, bu…
Ocaml types are USED by the compiler to generate FAST code. TS types are IGNORED by the JIT to generate SLOW code. All the features that make Typescript more ergonomic for devs also allow it to generate slower JS code. AssemblyScript tries to be TS for WASM and it doesn't support huge swaths of TS because they output unusably slow garbage. I also suspect that more than a few Ocaml ergonomic issues are due to nominal…
it's mainly the lack of ad-hoc polymorphism that makes ocaml feel a bit clunky to me at times. but structural typing sure would be nice.
i used to avoid typescript because of similar soundness issues. but in the context of web dev this weird type system that evolved from adding types to javascript turned out to be so nice to use. it's bonkers because on paper it shouldn't be this nice haha.
Earlier quoted context omitted.
i tried that but had to revert to vitest, the native test runner feels incomplete atm.
What is missing for your use case or workflow?
i'm building a framework with minimal dependencies at https://www.plainweb.dev so i'm super excited about everything that node builds in (sqlite, typescript).
but there is a difference between supporting the bare minimum and actually making it nice to use day to day.
Earlier quoted context omitted.
This is a point in Flow's favour. However! Seven years ago or so, when TypeScript was quite young and seemed inferior to Flow in almost all respects, I chose Flow for a large project. Since then, I spent inordinate amounts of time updating our code for the latest breaking Flow version, until one came along that would have taken too long to update for, so we just stayed on that one. We migrated to TypeScript a little…
Turning on EVERY safety feature won't mitigate the unsoundness because the problem goes beyond stuff like `any`.
One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…
It's already the case for ECMAScript and I don't see why TypeScript should be treated differently when Node.js has to transpile it to JavaScript and among other things ensure that there are no regressions that would break existing code. Unlike Python typing it's not only type erasure: enums, namespaces, decorators, access modifiers, helper functions and so on need to be transformed into their JavaScript equivalent.
Earlier quoted context omitted.
Ocaml types are USED by the compiler to generate FAST code. TS types are IGNORED by the JIT to generate SLOW code. All the features that make Typescript more ergonomic for devs also allow it to generate slower JS code. AssemblyScript tries to be TS for WASM and it doesn't support huge swaths of TS because they output unusably slow garbage. I also suspect that more than a few Ocaml ergonomic issues are due to nominal…
for my use case (web dev) ts is fast enough. but i do miss the ocaml compile times! it's mainly the lack of ad-hoc polymorphism that makes ocaml feel a bit clunky to me at times. but structural typing sure would be nice. i used to avoid typescript because of similar soundness issues. but in the context of web dev this weird type system that evolved from adding types to javascript turned out to be so nice to use. it's…
As I wrote elsewhere in this thread, TS makes it incredibly easy to unintentionally make megamorphic functions that don’t have any inline cache and don’t get optimized at all. You think you’re writing efficient, DRY code, but it’s really just dog slow because you’ve neutered the JIT.
Earlier quoted context omitted.
This is different. Neither flow, typescript, nor javascript generate a runtime error for an out of bounds index. It's explicitly allowed by the language. The result of the an OOB access of an array is specified to be `undefined`. The throw only happens later when the value is treated as the wrong type. I don't consider a runtime error to be a failure of the type system for OOB array access. But in javascript, it's ex…
> It's explicitly allowed by the language. This is like arguing that a null exception is fine because it's allowed by the language. If you get `undefined` when you expect another type, most future interaction are guaranteed to have JS throw because of the JS equivalent of a null pointer exception. They are technically different because a dynamic language runtime can prevent a total crash, but the effect on your web a…
I wouldn't make the recommendation that they do at all. Full soundness is not my thing. But... if Flow wanted to do it, it would have to change the type of indexing into `(Element[])[number]` with a read from `Element` to `Element | undefined`.