I can't imagine maintaining a large JS codebase without types now. For places where you really need dynamic typing the any type is there for you.
I certainly would never take a job in a pure JS shop.
I certainly would never take a job in a pure JS shop.
Could you please provide a list of these tradeoffs?
But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer.
As a second tradeoff, choosing JavaScript over TypeScript tend to make codebases less complect and more modular, at least in the teams I've been in who maintained codebases with both languages.
My experience with js-land is that choosing a typescript and make use of the @types packages is _the_ modern way of doing js dev. What you describe is basically do the same people did 15 years ago.
That is not a trade-off, but a refusal to re-evaluate the situation under changing conditions.
You've yet to provide even a single example.
As an aside, at least to me your posts are coming off as really combative in this thread. You might get more constructive responses if you adopted a more curious, open tone.
Edit: found this on page... 4 of HN? https://twitter.com/swyx/status/1350427690814251010 .
> type errors may be such a small proportion of your errors that a using a type checker isn't justifiable
This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is.
> As an aside, at least to me your posts are coming off as really combative in this thread
You are correct in this. Sorry. I will fix my comments to come off as less abrasive.
Oh super interesting! I wonder if the solution is like, tsc becomes a reference compiler. I'm pretty sure people would absolutely love a Rust implementation that was fast but a little behind. A lot easier to daydream about than to do though, haha.
> This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is.
Yeah and I do miss this in dynamic languages. Interfaces (and typed data structures) have great descriptive power just on their own. There are run time packages for this (prop-types, etc) but... run time is worse haha.
[citation needed]... My experience is the exact opposite. Javascript code bases I've worked with had crazy mega functions that would accept any arbitrary input and try to return something. Typescript code bases (in my experience) tend to be more modular because the interfaces between things are clearly defined. If you want to use code written by someone else, it's immediately obvious what structure your data needs to have to work with their code.
> But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer.
I mean, they are talking about having parts written in rust:
> Rust-based replacements. Once we have a more well-defined API, we may be able to swap out pieces into Rust-based alternatives for performance. This could look like creating NAPI modules written in Rust for Node.js, writing in Rust and compiling to WebAssembly, creating a standalone ESLint executable written in Rust that calls into the JavaScript portions, or other approaches.
That looks like an _extremely_ complex build system setup compared to using the Typescript. They are also planning to document the types anyway:
> ESM with type checking. I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS, but I do think rewriting from scratch allows us to write in ESM and also use tsc with JSDoc comments to type check the project. This includes publishing type definitions in the packages.
The only possible trade-off I can think of is that type checking with tsc + JSDoc results in a faster build than using typescript directly. Personally, I find it a bit odd to use tsc + JSDoc instead of TS, but hey, they can do what they want.
Like, you are theoretically correct, but practically the extra complexity of using Typescript over Javascript is running ‘npm install typescript’ after installing node. You certainly have less build tooling without tsc, but the benefit there is tiny.
There’s some mild reasons to go for pure JS, and a lot of absolutely gigantic reasons to go for Typescript (in my opinion).
Even Rust, which has a much stronger type system than TS, does not prevent all runtime errors. Types can prevent a certain class of bugs/errors, and that’s great, but zero runtime errors is overstating it by a wide margin.
Of course, everything is just tool. Its up to us to decide if we want to use it or not. What I don't understand is why wouldn't you use it. I totally understand if its fun to cobble together some webserver using only bash scripts. But if you're writing something as big, complex, and widely used as ESLint, I am very surprised if you don't choose something that is more performant and maintainable. It is almost irresponsible. I have plenty of fun side projects that should never ever be used in production because I know its really bad.
I never claimed that using Rust will magically make all your sort implementation correct. Of course this is an insane claim. But like I said, if you take any snippet of JavaScript, you actually cannot reason about it without looking at all the calls to that function, plus all the functions that calls to that. Given any variable S, what is its value? Who knows. I guess you just have to run this massive test suite that we wrote. There's WAY more possible incorrect JavaScript code than there are Rust.
I have written webservers in TypeScript and Rust. The moment I get something out of serde in Rust, I know for a fact this is a string. If the key doesn't exist, its None. In TypeScript, I don't have the same confidence. Did they wrote the correct validator? Wait did they add a default value? Does this interface match what we have? Oh its a string...but its actually Date. Wait...why does this bool keep returning false...(https://stackoverflow.com/questions/59046629/boolean-paramet...)
I could have written 1000s of unit tests...Or just use type and fail the "test" at compile time.
>there's anything wrong with working in language without static typing
Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.
> Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.
Frankly, I have a lot more confidence in something written in Python/Ruby/JS to not fail in a really dangerous way than I do something written in C. It's silly to pretend like all languages with types are equivalent, or that types are uniformly better for all use-cases.
Sure, the type systems in C/C++ will verify that you don't have type errors, but they can't verify that you don't have use-after-free errors, or out-of-bounds errors, or null pointer dereference errors, and so on. Even Java, which has an extensive and relatively modern type system, can't protect you from null pointer dereferences.
I never said "there's nothing wrong with working in a language without static typing for ANY PROJECT IN THE WORLD." Some projects need it, and some projects frankly don't. Linux, given its constraints, could not have been written in anything other than C. That's fine.
Very large projects in dynamic languages seem to eventually want type annotations, e.g. Dropbox (Python), Stripe (Ruby IIRC), and Facebook (PHP). But at the same time there are plenty of large, successful projects written in dynamic languages: GitLab (Ruby), Wordpress (PHP), much of emacs (Lisp), this very website (Lisp), Datomic (Clojure), CircleCI (Clojure). Sure, you can say that all of those projects should have been written in some statically typed language, but they have found success regardless, which is really the only metric that matters.
Besides, I’d imagine the deployed code would be minimized anyway regardless of whether TypeScript is used.
Which renders your formula meaningless.
- code formatter :: style
- type system :: tests
...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated.
All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
> - type system :: tests
This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API.
Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like:
"Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system."
My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?"
In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc.
---
> so suggesting data driven decision making such as benchmarking because you don't trust Big-O
The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion.
> quantifying typescript's benefits instead of actually thinking about them is a cop out
This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example:
int add(int a, int b) {
return a - b;
}
Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.
Im just too tired at this point to address the comment that having more types is somehow a burden on eng velocity while having more tests isn’t. In reality, you never have nearly as many tests as you ideally need, but you can add more types more easily and it will help people reason about your system much easier.
Speaking of which, tests are often way too verbose it hurts readability aka the ability to reason about your system
My point is that if you have tests, you probably don't need types, and since you really oughta have tests, the benefits of mainstream type systems are overstated. A lot of arguments in this thread are essentially "types have benefits you can't get anywhere else", but you can get them with tests. When it comes to verifying program correctness, tests are a super set of types' functionality.
> You can have less tests when you have more types.
Can you? In my dynamic language work the tests aren't doing type checks, usually there's some kind of validation library doing that. Generally the tests are doing work that types can't.
> There are type systems that requires an overhaul of the whole toolchain, but what we’re talking about typescript isn’t that.
I guess we can disagree about "overhaul", but IMO adding a compiler, new dependencies (types) and entirely new syntax to your toolchain qualifies. If that doesn't, what does?
> You can literally run plain js with jsdoc through tcs and make your comment provably accurate documentation
A few things foil this:
- using `any`
- using untyped libraries
- taking advantage of gradual typing
- unhelpful type soup
"Type soup" really bears expanding:
subscribeToMore(
options: {
document: DocumentNode,
variables?: TVariables,
updateQuery?: Function,
onError?: Function
}
) => () => void
Further, these types don't verify any behavior. They can't prove to you that `onError` is called when an error occurs. They can't prove to you that you will continue to receive data when it's updated. They can't prove to you that you subscribed to the specified document. On and on. There's a reason that high-reliability environments use tests, even though they're using strongly typed languages like Ada and Eiffel, and that's because type systems cannot fully specify a program's behavior.
[0]: https://www.apollographql.com/docs/react/api/react/hooks/#su...