6 ms·

There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wron

There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds. [1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... First paragragh of that document: > Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.

snek 6y ago
Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.
- yawaramin 6y ago
  That passage didn't say anything about finding the document 'amusing'.
- dbnoch 6y ago
  I thought the "novice" programmer remark was a pretty cringe-worthy comment. The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".
  - Aeolun 6y ago
    I can sympathize with their issues. TS compiles are slow as fuck, and if I could find anything that was just as nice without the long compiles I’d switch in a heartbeat. But I don’t think I’d ever want to go back to plain Javascript.
    - rclayton 6y ago
      My sentiment as well.
    - 112 6y ago
      There are efforts to provide faster compilation times: - https://github.com/evanw/esbuild https://github.com/evanw/esbuild - awesome, I use it for most of my ts projects - https://swc-project.github.io/ https://swc-project.github.io/ - also awesome, but has some bugs
      - Aeolun 6y ago
        Esbuild is cool, but if it doesn’t check the types then using Typescript is a bit pointless in the first place. Guess a combination of esbuild during development, and tsc during commit would be the best of both worlds.
        satvikpendem 6y ago
        Not necessarily, TS issues are found in the editor which is where most of the use is. I don't test types only on compile but usually through VSCode itself.
      - 8lall0 6y ago
        Thumbs up for esbuild, it's awesome.
chmln 6y ago
That document is not particularly enlightening either. > we're removing the types from internal code and making it pure JS. this reduces complexity and helps us ship a faster product Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. But perhaps this is something beyond the simpleton comprehension of us novice programmers
- klodolph 6y ago
  > Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. My personal experience is that there’s a size threshold where static tying becomes more useful. Below this threshold, the problems solved by static types are still mostly tractable by humans and things like linters. The threshold is different for every program and set of developers. 10K lines is small enough IMO. > But perhaps this is something beyond the simpleton comprehension of us novice programmers That’s just flamebait, the comment is better without it.
  - tome 6y ago
    It was your GP who introduced the word "novice".
    - klodolph 6y ago
      It’s not the word, it’s the sentence.
- inimino 6y ago
  > That document is not particularly enlightening either. Here are some key words that many kibitzers here could benefit greatly from internalizing: > > The target audience is the 5 to 10 people who work on this particular internal system. > Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. Are you one of the people responsible for maintaining those 10KLOC? > But perhaps this is something beyond the simpleton comprehension of us novice programmers I believe Ryan Dahl would admit to having made more mistakes in large system design than most of us will ever have a chance to. Who knows, he may have picked up a thing or two along the way that most of us haven't. This could also just be an internal product decision that really doesn't affect anyone outside the core project team, while some of us here are projecting way too much onto it.
echelon 6y ago
> maybe much more so than novice programmers can appreciate Okay, unsubscribe. This is not the tone you use to interact with the community. This is brash, elitist hogwash.
spion 6y ago
I mean, the design doc is wrong. Instead of Object.defineProperty(HeaderImpl, "name", { value: "Header" }); you can just use export let Header = class Header { } to avoid creating a conflict between the header type declaration and this header implementation, since that way the type will be locally constrained to the class expression and only the variable gets out. > Who knows if this kicks Header out of some optimization path in V8 It doesn't. --- Forgive me for being suspicious of the whole thing because a couple of the rationalizations don't make sense, I'm sure there are some valid points raised there.

snek 6y ago

Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.

yawaramin 6y ago
That passage didn't say anything about finding the document 'amusing'.
dbnoch 6y ago
I thought the "novice" programmer remark was a pretty cringe-worthy comment. The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".
- Aeolun 6y ago
  I can sympathize with their issues. TS compiles are slow as fuck, and if I could find anything that was just as nice without the long compiles I’d switch in a heartbeat. But I don’t think I’d ever want to go back to plain Javascript.
  - rclayton 6y ago
    My sentiment as well.
  - 112 6y ago
    There are efforts to provide faster compilation times: - https://github.com/evanw/esbuild https://github.com/evanw/esbuild - awesome, I use it for most of my ts projects - https://swc-project.github.io/ https://swc-project.github.io/ - also awesome, but has some bugs
    - Aeolun 6y ago
      Esbuild is cool, but if it doesn’t check the types then using Typescript is a bit pointless in the first place. Guess a combination of esbuild during development, and tsc during commit would be the best of both worlds.
      - satvikpendem 6y ago
        Not necessarily, TS issues are found in the editor which is where most of the use is. I don't test types only on compile but usually through VSCode itself.
    - 8lall0 6y ago
      Thumbs up for esbuild, it's awesome.

chmln 6y ago

That document is not particularly enlightening either. > we're removing the types from internal code and making it pure JS. this reduces complexity and helps us ship a faster product Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. But perhaps this is something beyond the simpleton comprehension of us novice programmers

klodolph 6y ago
> Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. My personal experience is that there’s a size threshold where static tying becomes more useful. Below this threshold, the problems solved by static types are still mostly tractable by humans and things like linters. The threshold is different for every program and set of developers. 10K lines is small enough IMO. > But perhaps this is something beyond the simpleton comprehension of us novice programmers That’s just flamebait, the comment is better without it.
- tome 6y ago
  It was your GP who introduced the word "novice".
  - klodolph 6y ago
    It’s not the word, it’s the sentence.
inimino 6y ago
> That document is not particularly enlightening either. Here are some key words that many kibitzers here could benefit greatly from internalizing: > > The target audience is the 5 to 10 people who work on this particular internal system. > Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. Are you one of the people responsible for maintaining those 10KLOC? > But perhaps this is something beyond the simpleton comprehension of us novice programmers I believe Ryan Dahl would admit to having made more mistakes in large system design than most of us will ever have a chance to. Who knows, he may have picked up a thing or two along the way that most of us haven't. This could also just be an internal product decision that really doesn't affect anyone outside the core project team, while some of us here are projecting way too much onto it.

echelon 6y ago

> maybe much more so than novice programmers can appreciate Okay, unsubscribe. This is not the tone you use to interact with the community. This is brash, elitist hogwash.

spion 6y ago

I mean, the design doc is wrong. Instead of Object.defineProperty(HeaderImpl, "name", { value: "Header" }); you can just use export let Header = class Header { } to avoid creating a conflict between the header type declaration and this header implementation, since that way the type will be locally constrained to the class expression and only the variable gets out. > Who knows if this kicks Header out of some optimization path in V8 It doesn't. --- Forgive me for being suspicious of the whole thing because a couple of the rationalizations don't make sense, I'm sure there are some valid points raised there.