Earlier quoted context omitted.
Why is anyone in the world manually writing 10k lines of glue code? You don't need TS or JS, you need.. a computer.
Please, elaborate.
Codegen?
Deno will stop using TypeScript
151–160 of 359 posts
Re: Deno will stop using TypeScript
#152I'm a little shocked at some of the outcry in this thread. People are making it sound like they're switching from Rust to Ruby or extolling the virtues of types: TypeScript does absolutely nothing for you at runtime. There are no types, there are no type checks, its all the same guarantees as good ol' JavaScript. You still can't trust function parameters to be what they say. It's a Babel configuration with inline doc annotations.
If people are serious about types, then why isn't more front-end moving over to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even. TypeScript has convinced people they're getting the benefits of (strong?) types when they're just populating the auto-complete in VS Code.
Re: Deno will stop using TypeScript
#153Earlier quoted context omitted.
and you wait a minute for the tests to run every time you commit a change
You could arrange to have a program write those tests for you based on your description of the project's data model. Oh wait...
You know what, that would already be better than most type systems.
Firstly, they'd be written in the same language that you are coding in, not a weird, half baked type language, that adds visual noise to your code.
Secondly, they'd have much more power to define meaningful and useful behaviour rather than being restricted to talk about correct behaviour via types.
Thirdly, they'd run when you wanted the tests to run, and you could tier different tests to run at different times, so they aren't all slowing you down while you're doing fast iteration.
I used to like types, but then I realised that what matters is how quickly you see the bug. Seeing it in your code editor is brilliant, but if it's slower in time than hitting control S and seeing the actual app in the other pane auto reload, and fail or not, then it's worse.
These days I look on the idea that you know the exact types of all data your program will interact with at the time you write your code as the same sort of mistake that we made when we thought we understood the deep inheritance hierarchies of the real world.
Re: Deno will stop using TypeScript
#154Due respect, these are issues with how the Deno team uses Typescript, not with the language itself. > TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process Umm, you can compile single files, and serve them individually. It's no different from bundling (e.g. with webpack) Javascript. > The Typescript structure that they’re using in the source file…
Your main point seems to be that these problems aren’t the language’s fault. But I don’t see the Deno team claiming that to be the case. There’s nothing wrong with choosing a language that works with how your team likes to develop software, and rejecting a language that doesn’t work well for your team. Doesn’t need to be anyone’s “fault.”
Re: Deno will stop using TypeScript
#155It seems it might be an issue with their development abilities or problem-solving motivation: 1. It seems that they write a ".d.ts" file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them "it was too much overhead and complexity when we attempted it before", which caused them to give up, a very dubious course of action. 2.…
> 2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead. Interested to know how you're actually supposed to do this. I don't do much web development, but the few times I've had to dive into our typescrip…
It's a relatively new thing
https://www.typescriptlang.org/docs/handbook/release-notes/t...
Re: Deno will stop using TypeScript
#156Earlier quoted context omitted.
Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have th…
> Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. How many times has six-months-hence you cursed you for this attitude? Be honest.
Never. This is why we write small functions that, as much as possible, depend only on their inputs and avoid mutation. Code becomes simple to reason about. You don't need to worry when composing these small pieces like you do when passing mutable objects, using out variables, etc.
Re: Deno will stop using TypeScript
#157Why such a large, important project would want to drop static types is beyond me. > TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just…
Most of the project is and will still be written in Rust, a statically typed language, so saying that the "project" will drop static types is an overstatement. Based on the design document where the devs talk about this, the TS code in question is about 10k lines of glue code between Rust & userland JS/TS.
If compilation times are a problem with typescript I do not see how Rust will help.
Re: Deno will stop using TypeScript
#158Earlier quoted context omitted.
Most of the project is and will still be written in Rust, a statically typed language, so saying that the "project" will drop static types is an overstatement. Based on the design document where the devs talk about this, the TS code in question is about 10k lines of glue code between Rust & userland JS/TS.
10K is a lot of code. As a maintainer of a popular 3k LOC typescript library, even at 1k LOC you start running into frequent type-related bugs with JavaScript
Working on half a million LOC TypeScript codebase. All strict flags up, low-2-digit team size. We don't really run into many problems. TypeScript is not perfect, but developer happiness and productivity have definitely increased since we adopted it, and defect rates have dropped significantly --while increasing the size of the team & working on more features.
Re: Deno will stop using TypeScript
#159Earlier quoted context omitted.
Certainly you didn't go through the entire pro con list of Node over other languages and go "it must be developer laziness!" Easy to reason about, great performance for most cases, simple to debug and write code for, a plethora of libraries, easy to ship, no need to have different teams for backend/frontend, and minimal tooling needed.
The only really unique thing JS is bringing to the table is that it also has a privileged position in the front end. Your list of benefits it provides boils down to stuff multiple large languages all have, and the one thing that means you can learn just JS. GP comment was presented somewhat snarkily, but I'm not sure they're all that wrong.
Sure other languages have some pieces of the puzzle - python has tons of libraries and is easy to understand, golang has great performance and is easy to write, etc.
But I have yet to find a language that has the same set of features except JS. If you want to offer up an alternative, please do so.
Re: Deno will stop using TypeScript
#160Earlier quoted context omitted.
Let's say you have a method that takes a thing : function doSomething(thing) { ... } How many different possible representations of a 'thing' do you have? A json object? A class object with behaviors? A database id? Some sort of natural key like a SKU? A URL? Is it a metric or imperial thing? You need integration-level tests around every method call to ensure that caller and callee agree what kind of 'thing' represen…
I never throw inputs of random types to my functions. Actually that could be a good idea, some fuzzying at the public API level could catch some bugs and attacks. But not at unit test level. If a function expects an integer argument I test it with integer values. That in Node, Ruby, Python and Elixir. I never saw anybody doing something different. Well, if we wanted to enforce types we could use any static typed lang…
The inputs shouldn’t be “random”, but the idea is that you should provide an input distribution that’s roughly representative of your expected distribution of real-world values (+ some perturbation to find edge cases).
As for frameworks in the languages you listed...
Ruby and Python: https://github.com/HypothesisWorks/hypothesis
Elixir and Erlang: https://github.com/proper-testing/proper
Node and JS: https://jsverify.github.io/
As for real world use-cases, imagine you’re writing a program that accepts timestamps as input and has to implement branching, requirements-defined business logic based off of them. When you’re writing your unit tests you can use the requirements to select timestamps that are “known good” and “known bad”, but it’s hard to explore this state space on your own.
Same thing goes for handling unexpected inputs to certain functions. You probably don’t want to check _every_ type of input for _every_ dynamic function, but it might make sense to make sure that certain “entry points” to your program fail in the expected manner when they get poorly typed input.