8 ms·

Deno getting out of type-checking for the most part is a good thing. Most projects depend on CI for production type checking and editor for local type checking.

• davedx 4y ago
  It does however remove a reason to use deno in the first place, seems to me.
• donatj 4y ago
  I have the opposite reaction. I feel like it's a huge mistake, and that it type checking everything was akin to a compiler telling you program won't work and instead just crashing at runtime. It's a step in the absolute wrong direction. Shouldn't matter if it's a dependency that's broken, or my code, if it's broken it's broken regardless of who wrote it. Failing at runtime instead of start time because of a bad dependency is a bad behavior.
  • qudat 4y ago
    Because typescript is optional typing and some libraries don't maintain their own typings, there's a non-zero chance that the typings of a third-party library are wrong. In this case the error is noise and not indicative of a runtime error. This is the frustrating part with using a mixed typed ecosystem.
    • donatj 4y ago
      > typings of a third-party library are wrong That's not noise. That is a bug.
      • dgb23 4y ago
        It's a TS "bug", not a Deno "bug" though. TS doesn't have a sound type system. It has type annotations on steroids.
        • donatj 4y ago
          It's neither. It's a bug in the library you're trying to use. The library you're trying to use is broken and you shouldn't use it until the problem is fixed.
          • wk_end 4y ago
            It'd be nice if I never had to use software with bugs in it but that's hardly realistic.
          • zackees 4y ago
            “Sorry we can’t use numpy because one of the types in the api is mismatched.”
      • cschep 4y ago
        Causing a bunch of pain for the user because of a theoretical thing that should be true doesn't help that thing become more true. I feel like we as a people (programmers) fall for this trap too often. Incentives have to be aligned so perfectly for this kind of thing to work.
      • qudat 4y ago
        It's a typing "bug" in code you don't control. In some cases that's enough to not use the library and sometimes it isn't. That's a value judgement based on the developers using the library.
        • SemanticStrengh 4y ago
        • deleted 4y ago
          [deleted]
      • hehebdjwis 4y ago
        Whatever you do don’t peek at v8, or the c libraries it links, or the operating system underneath it all…
    • IshKebab 4y ago
      Ok but it should be an opt-in workaround for dependencies' bugs. Tell me if a dependency has an issue, and then let me decide if I want to ignore it. Don't just ignore them all - for one they'll never get fixed.
    • SemanticStrengh 4y ago
      you can always use https://github.com/ds300/patch-package https://github.com/ds300/patch-package there is no excuse for mediocrity, of course you can use any, that just should not be the default behaviour
  • lucacasonato 4y ago
    Did you read the rationale explained in last releases' blog post[0]? [0]: https://deno.com/blog/v1.21#deno-check-and-the-path-to-not-type-checking-by-default https://deno.com/blog/v1.21#deno-check-and-the-path-to-not-t...
    • donatj 4y ago
      I did. There's no actual reason given. Some rambling about JavaScripts future runtime checked types, which don't fix the problem static type checking fixes. It entirely misses the point.
      • lucacasonato 4y ago
        Well you seem to be asserting we are removing type checking, which we are not. We are just moving around when the tooling does the type checking (now in it's own step, rather than at runtime). Code is still being type checked, just not by default at runtime anymore. You can also just do `deno run --check=all main.ts` to check at runtime by the way. The functionality isn't even being removed, it's just moved around and some defaults are being changed :)
        • IshKebab 4y ago
          > Code is still being type checked, just not by default That's a pretty big caveat. In most cases "not by default" means "hardly ever". I feel like the change would go over better if you were more honest about the only real reason to do this - speed. If you just said "type checking is too slow for `deno run`. We'd like to have it type check then but upon reflection we think the speed cost is worse than the cost of moving type checking to a non-default command." That's very reasonable. "We don't think types should be checked by default" is just pretty crazy IMO. Also, don't you cache the output so it's only slow on the first run?
          • jcheng 4y ago
            I think that is exactly what they said? > Up to now, deno run has always automatically performed type checking on the code it was about to run, just before running it. This can sometimes be a nice user experience, but more often than not it is not what you want. The reason for this is often that type checking is really slow: it is often by far the single largest factor impacting the startup performance of your application.
  • dsherret 4y ago
    Type checking still occurs for `deno test`, which is what's mostly used for development. `deno run` won't have it by default because usually you run programs that are already type checked, but if you want it you will be able to add the `--check` flag (ex. `deno run --check main.ts`). There's a huge performance overhead to run type checking, so the changes are for it to only be run for development/bundling workflows and be opt-in otherwise.
  • eins1234 4y ago
    Disagree wholeheartedly. One of the under-appreciated superpowers of gradually typed systems like TypeScript is the ability to ignore errors in parts of the codebase I don't care about right now, and focus on exercising the runtime behavior of the code paths I'm currently working on, because I can always have a working program that can be executed (and possibly crash at runtime) regardless of what the static analysis tells me is wrong with it. Without this, large scale changes tend to become extremely painful all-or-nothing affairs that have to be applied codebase wide at every iteration, and I only find out the change doesn't work the way I expected at runtime after I've already done all the work applying it to everything across the board, and have to repeat the whole process over and over again.
    • woojoo666 4y ago
      I'm fine with providing developers an option to disable checks, as they already had previously with the nochecks option. But why make it the default? If you chose to use typescript over javascript, then you clearly care about type correctness, so why stop caring when it comes to your dependencies? As far as I'm aware, there's no other typed language that let's you do that. I don't see Rust developers complaining that they can't use broken dependencies. If you really wanted to import a broken dependency, at least with typescript you can compile the dependency to plain javascript which will remove all types (and thus all type errors as well). But to disable type checks by default for a typed language seems a bit odd. And to be clear, this is still an "all-or-nothing" approach. When you disable checks, it's "nothing". Deno will still compile even if there are type errors in your own code. (At least that's what I'm assuming, I haven't tested the nochecks option yet. Please correct me if I'm wrong)
  • armchairhacker 4y ago
    I have a custom esbuild configuration which separates typechecking and code generation. The separate code-generation combined with esbuild means that I can hit “Debug” and my app builds and starts up almost instantly. The type-checking is done as a commit hook, so if there are any type errors they will be fixed once im done working on whatever small change. Any dependency which doesn’t have valid types probably has bigger issues, but during active development, active-file type-checking is usually enough.