[HN Gopher] Deno 1.22
___________________________________________________________________
Deno 1.22
Author : 0xedb
Score : 123 points
Date : 2022-05-18 19:21 UTC (3 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| SaarRyan wrote:
| upupandup wrote:
| isn't this basically AWS Lambda Edge or Cloudflare Workers? how
| can I accomplish the following on AWS, DO, or Cloudflare? these
| alone wouldn't/cannot be enough for me to move away, especially
| as they are not too difficult to pull off AND most of my customer
| base is located in the US....so its nice that someone in
| Turkmenistan has low latency....but they aren't a target
| customer. Deploy JavaScript Globally
| Instant deployments Located in 32 regions worldwide
| Zero config, zero maintenance TypeScript, Wasm, ES
| Modules
| m00dy wrote:
| Lightning never strikes the same place twice
| lucacasonato wrote:
| Just to preemptively clear up some confusion: Deno is *not*
| removing type-checking.
|
| The only change is that type checking is now it's own subcommand:
| `deno check`, instead of happening as part of `deno run`.
|
| See last releases' blog post for the rationale:
| https://deno.com/blog/v1.21#deno-check-and-the-path-to-not-t...
| brundolf wrote:
| > either by running deno check, or by specifying the --check
| option on deno run
|
| deno check is very welcome, but I think I would have preferred
| a --nocheck option when running instead of a --check option
| lucacasonato wrote:
| That option already exists, and we found that most people we
| interviewed used it more often than the default.
| brundolf wrote:
| > we found that most people we interviewed used it more
| often than the default
|
| That's surprising/depressing, but kudos I guess for doing
| user research and listening to what the majority wants
| nicoburns wrote:
| > That's surprising/depressing
|
| Why? TypeScript type-checking is slow. Furthermore it's
| common when refactoring code that you break code in many
| places, but that you want to run the code you are
| actively working on and iterate on it (perhaps further
| changing the shared types in the process) before going
| through and fixing uses of that code everywhere.
|
| As long as you have CI process enforcing the type
| checking, there's no real disadvantage to this approach.
| brundolf wrote:
| I think there's something to be said for shepherding an
| entire ecosystem into good practices. If people have to
| go out of their way to get their code checked, a lot of
| code with type errors will probably make it into the
| world in practice.
|
| Before Deno this was more tolerable because the ecosystem
| was so messy to begin with; libraries that lacked types,
| APIs that were never designed with types in mind. But
| Deno is in many ways a fresh start, and given that
| opportunity I'd prefer it if we said "typed and passing
| code is the default, you have to go out of your way if
| you want to violate that convention". It's a shame to
| leave the door wide open for a slow-rot of type failures,
| especially when Deno already supports plain JS files for
| the cases where you _really_ need to skip writing types.
| AtNightWeCode wrote:
| So not only has the type checking been removed from basic
| usage. It is also a breaking change. Nice.
| msoad wrote:
| 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.
|
| I also love how Deno is nicely maturing. Can't wait to find a
| problem to solve with Deno!
| davedx wrote:
| It does however remove a reason to use deno in the first place,
| seems to me.
| donatj wrote:
| 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.
| eins1234 wrote:
| 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 wrote:
| 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)
| lucacasonato wrote:
| 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-t...
| donatj wrote:
| 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.
| ImprobableTruth wrote:
| The explanation isn't great, but the reasoning is that
| people will already have their IDE running TypeScript +
| type checking running on commit, so adding that onto the
| process just slows it down without much real gain.
|
| (This is of course assuming that most type errors are
| largely localized enough that your IDE will find them).
| lucacasonato wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| Vinnl wrote:
| The 'at runtime' part you cut off from that quote seems
| pretty relevant. Tests aren't run by default at runtime
| either.
| corrral wrote:
| It reads more like a case for caching, or for a much more
| capable bundler (that can include an "I am version XXXX
| and already checked this, it's good" note in the bundle).
| Certainly, it seems like it would have been safer to
| leave the default alone and add a "do-not-typecheck"
| flag.
| lucacasonato wrote:
| The unfortunate thing about TypeScript is that
| incremental type checks are still very slow, because any
| file can influence the type of any other file, without
| the other file knowing. It's a design issue, that is
| unfortunately very unlikely to be fixed at this point.
|
| Also, we already have a "do-not-typecheck" flag (`--no-
| check`), we were just seeing in real world usage that
| nearly everyone who uses Deno professionally would enable
| this flag for inner loop development, and leave type
| checking up to CI and their IDE. If 95% of your users use
| a flag that changes a default, then that changed value
| should probably be the default (resulting in a better
| experience for most people) :)
| corrral wrote:
| > The unfortunate thing about TypeScript is that
| incremental type checks are still very slow, because any
| file can influence the type of any other file, without
| the other file knowing. It's a design issue, that is
| unfortunately very unlikely to be fixed at this point.
|
| That makes sense, thanks.
|
| > Also, we already have a "do-not-typecheck" flag (`--no-
| check`), we were just seeing in real world usage that
| nearly everyone who uses Deno professionally would enable
| this flag for inner loop development, and leave type
| checking up to CI and their IDE. If 95% of your users use
| a flag that changes a default, then that changed value
| should probably be the default (resulting in a better
| experience for most people) :)
|
| I'm still not a big fan of changing defaults for commands
| that may e.g. be part of scripts, outside major version
| jumps, but I get the motivation if the no-check flag was
| in fact far more oft-used than the default behavior.
| lewisl9029 wrote:
| At Brex we tried to speed up the typecheck speed in CI by
| saving and reusing the build output from the incremental
| cache.
|
| It worked pretty well for the most part, and I would
| recommend looking into this for most teams since it's a
| pretty quick win. Most typecheck steps went from minutes
| to low-double-digit seconds (admittedly still slower than
| I would have hoped).
|
| But occasionally there would be gigantic spikes back to
| minutes for seemingly small changes that seem like they
| should have been incrementally check-able. I suspect
| these might have something to do with circular dependency
| chains, but didn't have bandwidth to dig deeper.
|
| I wish TypeScript's incremental checking mechanism and
| file formats was a bit better documented and less opaque,
| so people could better reason about and optimize
| typechecking performance, and possibly build support into
| other systems to perform & share some of the analysis
| they're already doing to avoid wasted work. That and to
| make it less of a giant blob for the entire codebase, and
| more of a set of files that are incrementally and
| individually update-able for better cache granularity and
| faster updates.
| lucacasonato wrote:
| Deno already automatically performs incremental type
| checking with a cache whenever possible. In most cases
| this is still _very_ slow though (double digit seconds).
| qudat wrote:
| 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.
| IshKebab wrote:
| 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 wrote:
| you can always use 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
| donatj wrote:
| > typings of a third-party library are wrong
|
| That's not noise. That is a bug.
| hehebdjwis wrote:
| Whatever you do don't peek at v8, or the c libraries it
| links, or the operating system underneath it all...
| qudat wrote:
| 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 wrote:
| [deleted]
| dgb23 wrote:
| 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 wrote:
| 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.
| zackees wrote:
| "Sorry we can't use numpy because one of the types in the
| api is mismatched."
| wk_end wrote:
| It'd be nice if I never had to use software with bugs in
| it but that's hardly realistic.
| cschep wrote:
| 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.
| dsherret wrote:
| 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.
| armchairhacker wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-18 23:01 UTC)