10 ms·

Deno 1.13 Release

134 points by 0xedb 5y ago

rektide 5y ago
Small thing but I dig the new --eval flag. To do something like this in node, I used to do: (echo 2+2; cat -) | node -i Which would generate some stdin via echo, then use cat to feed stdin to node. --eval 2+2 is a blissfully elegant upgrade to this. As a comment points out, node has a '-e' (and a -p which prints the evalled thing) but does not open a repl after. This shell receipt, like --eval, leaves the repl open.
- deleted 5y ago
  [deleted]
- johannes1234321 5y ago
  1) node has a -e option 2) why the cat? It just pipes the stuff through 3) you can use <<< to pipe something to stdin (`node <<< 1+1`)
  - codetrotter 5y ago
    They wanted to keep feeding stdin that’s why. Their 2+2 is just a placeholder for something bigger, which could even be several lines of input that they wanted to prepend, followed by manual input. In other words they are talking about initiating a REPL session with some initial input followed by manual input.
  - dsherret 5y ago
    Just to be clear, `deno eval "console.log(5)"` has existed for some time which is similar to `node -e "console.log(5)"`. In this case, the deno repl subcommand's --eval flag provides a cross-platform way to evaluate some setup code before launching into the REPL. This is useful if you alias the command in your shell's initialization file allowing you to easily launch a REPL with everything already setup to your liking. For example: $ alias add_repl='deno repl --eval "const add = (a, b) => a + b"' ... $ add_repl Deno 1.13 exit using ctrl+d or close() > add(1, 2) 3
  - lxe 5y ago
    Node's `-p` option will print the result of the evaluation. $ node -p 1+1 2
    - dsherret 5y ago
      The equivalent in Deno is: $ deno eval -p "1 + 1" 2
brundolf 5y ago
Is anybody using Deno at work? I feel like there was this rush of excitement when it first came out, and that's mellowed to a steady stream of updates and some sustained low-medium interest. It seems like everybody's following it from the sidelines, waiting to see what happens. That's my situation at least. I'd love a world where I can write everything in TypeScript with minimal building hassle, but I'm curious to what degree that's panning out in industry.
- zachlatta 5y ago
  We're using Deno for some small projects at Hack Club. We open source everything. Code for them should be somewhere in https://github.com/hackclub/hackclub https://github.com/hackclub/hackclub. In particular, we've been using it to replace some bash and Ruby scripts we had.
- nullspace 5y ago
  We are, in a limited fashion. Can't give too much details (mostly because I'm not directly working on it), but the ability to run in a constrained sandbox and the ability to easily do go style imports from github is seriously useful for our use case. Don't know how it's going to pan out, but from a high level deno seems to be very well designed. I'm looking forward to see the various niches in which people use it.
- tupac_speedrap 5y ago
  Not that I know of. TypeScript has had some major adoption over vanilla JavaScript over the past few years, I used it a bit when it was relatively new and now it is pretty common to see it advertised on job specs but I have never seen Deno once, maybe they use it in "ployglot" shops where everybody uses more esoteric languages but I haven't seen it advertised anywhere.
- eyelidlessness 5y ago
  I know at least one person on the Snowpack/Astro team has expressed[1] interest in dual Node/Deno support. I’m not currently advocating for supporting Deno on my professional projects. But this isn’t for lack of interest, it’s just lower priority than other changes I want to make first. I absolutely want to switch when I can justify it, if for no other reason than fast TypeScript ESM without a build/transformation step. 1: https://twitter.com/n_moore/status/1423672410486755332?s=21 https://twitter.com/n_moore/status/1423672410486755332?s=21 Edit: forgot link
qbasic_forever 5y ago
One little deno feature I didn't realize until digging in to play with it more was that it can 'compile' code and the V8 runtime into a single standalone executable. IMHO this is really nifty and feels very go-like in building tools with zero other dependencies. Obviously the V8 runtime adds a lot of size (seems like a hello world is 90MB or so in quick testing) but I like the potential for building tools that are easy to give to others to install and use. It seems great for internal use where you have analysts and such using a mish-mash of scripts and one-offs with lots of dependencies and little documentation or time to help people setup and use them. Just hook up your CI to spit out new executables and be done with walking people through how to troubleshoot their broken homebrew node, python, etc. environments.
- rektide 5y ago
  Personally I weap for the death of shared libraries. It's great developer convenience to statically bundle everything, and ever so manageable... But it makes me so sad thinking not just of the storage footprint of dozens of copies of the library floating around (be it v8 for deno, or chrome for electron), but the memory cost too of having that near-to duplicate library loaded multiple times too. And then there's the maintenance cost to the user, of needing to update each package independently to get updates. With something like the web, I as a user would far prefer having bleeding edge shared libraries/v8's/browsers underfoot, and carry the expectation that each app can load & run atop this most recent version. The trends have been very much in the other way. One of the main Go champions tout is it's static compilation, I think rust too. What are containers but entire static system images, as opposed to just having some static libraries? Part of me is willing to acknowledge that the larger footprints aren't that impactful, aren't really a problem, but it contravenes the deliberate & elegant simplicity that something like an OS distribution used to represent: I look at Debian as thousands of different pieces, all wonderfully integrated & interlinked, a cohesive system, that one ought to be able to bring additional projects onto to compile & extend. But our appetite for such has waned. The convenience for you & your users of just bundling everything you personally need to ship your stuff is quite high, at least when you're not updating dozens of oversized apps or running janky old versions because of this easy-to-get-started convenience.
floatboth 5y ago
const libSuffix = { darwin: "so", linux: "so", windows: "dll", }[Deno.build.os] oh no, what a bad example. Hope no one ever actually copies that… (it's bad because it unnecessarily limits the list of platforms to just three. great way to make BSD users hate you. just do: if (windows) "dll" else "so")
- bartlomieju 5y ago
  Thanks, I'll update the example
deleted 5y ago
[deleted]
russellbeattie 5y ago
Seriously, HN, is Deno going to hit the front page with every single point release??
- petercooper 5y ago
  You just reminded me of the Erlang flood of 2009 :-) https://news.ycombinator.com/item?id=512145 https://news.ycombinator.com/item?id=512145
  - russellbeattie 5y ago
    "Until I read this, I wondered about the sudden popularity of Erlang". Heh. Makes me wonder if I missed a similar post about Deno.
  - searchableguy 5y ago
    For those curious about how the page looked on that day: https://news.ycombinator.com/front?day=2009-03-11 https://news.ycombinator.com/front?day=2009-03-11
bartlomieju 5y ago
Bartek from deno.land here, happy to answer your questions should you have any. Deno 1.13 is one of the biggest releases to date - we're especially happy with stabilization of native HTTP server bindings. We plan to focus on squeezing the last bits of performance out of it in the coming weeks. Personally I'm most excited about type checking example code in Markdown files. It's critical to keep your documentation up to date and doing so for code blocks embedded in JSDoc comments or Markdown files was very challenging. With this release we got you covered - just run "deno test --doc" on your codebase.
- wuschel 5y ago
  Hi Bartek, thanks for jumping in. I am wondering whether one could forego Typescript and use one of the Ocaml/F# to JS converters for the frontend and backend code. Would it even make sense, and would it be convenient to use? How would one set up such a project?
  - sprkv5 5y ago
    +1 for Ocaml/F# and also the new ReScript. Would you be open to support these on Deno?
  - searchableguy 5y ago
    I think you might be interested in this open issue about public API for compiler. https://github.com/denoland/deno/issues/1739 https://github.com/denoland/deno/issues/1739
  - bartlomieju 5y ago
    If the tooling you're describing outputs JS sources there's nothing preventing you from using it. Currently there's no way to hook them up directly into Deno, so you'd have to resort to separate build step (via some kind of script, I presume this is just a matter of calling appropriate binary). If those tools help you write better code and you prefer to code in Ocaml/F# then it definitely makes sense, but of course this is personal preference. Drop by at our Discord server [0] to get some tips on how to set up such project. [0] https://discord.gg/deno https://discord.gg/deno
lxe 5y ago
I'm still not a fan of the async iterator API example for server handlers: for await (const conn of Deno.listen({ port: 4500 })) { (async () => { for await (const { respondWith } of Deno.serveHttp(conn)) { respondWith(new Response("Hello World")); } })(); } It's hard to reason, and ugly with that async iffe in the middle adding layers of nesting and bf-like `})();` junk. I think the event subscription API is much easier on the eyes and the mind.
- emptysea 5y ago
  I'm curious why the IIFE is even necessary in this case. There is already a top level await in the `for await` right? Looks fine IMHO once the IFFE is removed: for await (const conn of Deno.listen({ port: 4500 })) { for await (const { respondWith } of Deno.serveHttp(conn)) { respondWith(new Response("Hello World")); } } Edit: Oh is it so it runs in concurrently and avoids the synchronous handling?
  - maddyboo 5y ago
    Yes I think the IIFE is there to avoid the inner loop blocking the outer loop. I think it looks better with the IIFE factored out into its own function: async function serve(conn) { for await (const { respondWith } of Deno.serveHttp(conn)) { respondWith(new Response("Hello World")); } } for await (const conn of Deno.listen({ port: 4500 })) { serve(conn); }
holoduke 5y ago
Any reason why I would use this over expressjs?
FaisalAbid 5y ago
Is Deno production ready?
aitchnyu 5y ago
The example makes me ask, is there a current/planned function to compare two complex objects are value-equalm like lodash `_.isEqual`?
- reaktivo 5y ago
  You can find and equivalent to _.isEqual here https://deno.land/std@0.104.0/testing https://deno.land/std@0.104.0/testing

134 points by 0xedb 5y ago

Small thing but I dig the new --eval flag. To do something like this in node, I used to do: (echo 2+2; cat -) | node -i Which would generate some stdin via echo, then use cat to feed stdin to node. --eval 2+2 is a blissfully elegant upgrade to this. As a comment points out, node has a '-e' (and a -p which prints the evalled thing) but does not open a repl after. This shell receipt, like --eval, leaves the repl open.

deleted 5y ago
[deleted]
johannes1234321 5y ago
1) node has a -e option 2) why the cat? It just pipes the stuff through 3) you can use <<< to pipe something to stdin (`node <<< 1+1`)
- codetrotter 5y ago
  They wanted to keep feeding stdin that’s why. Their 2+2 is just a placeholder for something bigger, which could even be several lines of input that they wanted to prepend, followed by manual input. In other words they are talking about initiating a REPL session with some initial input followed by manual input.
- dsherret 5y ago
  Just to be clear, `deno eval "console.log(5)"` has existed for some time which is similar to `node -e "console.log(5)"`. In this case, the deno repl subcommand's --eval flag provides a cross-platform way to evaluate some setup code before launching into the REPL. This is useful if you alias the command in your shell's initialization file allowing you to easily launch a REPL with everything already setup to your liking. For example: $ alias add_repl='deno repl --eval "const add = (a, b) => a + b"' ... $ add_repl Deno 1.13 exit using ctrl+d or close() > add(1, 2) 3
- lxe 5y ago
  Node's `-p` option will print the result of the evaluation. $ node -p 1+1 2
  - dsherret 5y ago
    The equivalent in Deno is: $ deno eval -p "1 + 1" 2

brundolf 5y ago

Is anybody using Deno at work? I feel like there was this rush of excitement when it first came out, and that's mellowed to a steady stream of updates and some sustained low-medium interest. It seems like everybody's following it from the sidelines, waiting to see what happens. That's my situation at least. I'd love a world where I can write everything in TypeScript with minimal building hassle, but I'm curious to what degree that's panning out in industry.

zachlatta 5y ago
We're using Deno for some small projects at Hack Club. We open source everything. Code for them should be somewhere in https://github.com/hackclub/hackclub https://github.com/hackclub/hackclub. In particular, we've been using it to replace some bash and Ruby scripts we had.
nullspace 5y ago
We are, in a limited fashion. Can't give too much details (mostly because I'm not directly working on it), but the ability to run in a constrained sandbox and the ability to easily do go style imports from github is seriously useful for our use case. Don't know how it's going to pan out, but from a high level deno seems to be very well designed. I'm looking forward to see the various niches in which people use it.
tupac_speedrap 5y ago
Not that I know of. TypeScript has had some major adoption over vanilla JavaScript over the past few years, I used it a bit when it was relatively new and now it is pretty common to see it advertised on job specs but I have never seen Deno once, maybe they use it in "ployglot" shops where everybody uses more esoteric languages but I haven't seen it advertised anywhere.
eyelidlessness 5y ago
I know at least one person on the Snowpack/Astro team has expressed[1] interest in dual Node/Deno support. I’m not currently advocating for supporting Deno on my professional projects. But this isn’t for lack of interest, it’s just lower priority than other changes I want to make first. I absolutely want to switch when I can justify it, if for no other reason than fast TypeScript ESM without a build/transformation step. 1: https://twitter.com/n_moore/status/1423672410486755332?s=21 https://twitter.com/n_moore/status/1423672410486755332?s=21 Edit: forgot link

qbasic_forever 5y ago

One little deno feature I didn't realize until digging in to play with it more was that it can 'compile' code and the V8 runtime into a single standalone executable. IMHO this is really nifty and feels very go-like in building tools with zero other dependencies. Obviously the V8 runtime adds a lot of size (seems like a hello world is 90MB or so in quick testing) but I like the potential for building tools that are easy to give to others to install and use. It seems great for internal use where you have analysts and such using a mish-mash of scripts and one-offs with lots of dependencies and little documentation or time to help people setup and use them. Just hook up your CI to spit out new executables and be done with walking people through how to troubleshoot their broken homebrew node, python, etc. environments.

rektide 5y ago
Personally I weap for the death of shared libraries. It's great developer convenience to statically bundle everything, and ever so manageable... But it makes me so sad thinking not just of the storage footprint of dozens of copies of the library floating around (be it v8 for deno, or chrome for electron), but the memory cost too of having that near-to duplicate library loaded multiple times too. And then there's the maintenance cost to the user, of needing to update each package independently to get updates. With something like the web, I as a user would far prefer having bleeding edge shared libraries/v8's/browsers underfoot, and carry the expectation that each app can load & run atop this most recent version. The trends have been very much in the other way. One of the main Go champions tout is it's static compilation, I think rust too. What are containers but entire static system images, as opposed to just having some static libraries? Part of me is willing to acknowledge that the larger footprints aren't that impactful, aren't really a problem, but it contravenes the deliberate & elegant simplicity that something like an OS distribution used to represent: I look at Debian as thousands of different pieces, all wonderfully integrated & interlinked, a cohesive system, that one ought to be able to bring additional projects onto to compile & extend. But our appetite for such has waned. The convenience for you & your users of just bundling everything you personally need to ship your stuff is quite high, at least when you're not updating dozens of oversized apps or running janky old versions because of this easy-to-get-started convenience.

floatboth 5y ago

const libSuffix = { darwin: "so", linux: "so", windows: "dll", }[Deno.build.os] oh no, what a bad example. Hope no one ever actually copies that… (it's bad because it unnecessarily limits the list of platforms to just three. great way to make BSD users hate you. just do: if (windows) "dll" else "so")

bartlomieju 5y ago
Thanks, I'll update the example

deleted 5y ago

[deleted]

russellbeattie 5y ago

Seriously, HN, is Deno going to hit the front page with every single point release??

petercooper 5y ago
You just reminded me of the Erlang flood of 2009 :-) https://news.ycombinator.com/item?id=512145 https://news.ycombinator.com/item?id=512145
- russellbeattie 5y ago
  "Until I read this, I wondered about the sudden popularity of Erlang". Heh. Makes me wonder if I missed a similar post about Deno.
- searchableguy 5y ago
  For those curious about how the page looked on that day: https://news.ycombinator.com/front?day=2009-03-11 https://news.ycombinator.com/front?day=2009-03-11

bartlomieju 5y ago

Bartek from deno.land here, happy to answer your questions should you have any. Deno 1.13 is one of the biggest releases to date - we're especially happy with stabilization of native HTTP server bindings. We plan to focus on squeezing the last bits of performance out of it in the coming weeks. Personally I'm most excited about type checking example code in Markdown files. It's critical to keep your documentation up to date and doing so for code blocks embedded in JSDoc comments or Markdown files was very challenging. With this release we got you covered - just run "deno test --doc" on your codebase.

wuschel 5y ago
Hi Bartek, thanks for jumping in. I am wondering whether one could forego Typescript and use one of the Ocaml/F# to JS converters for the frontend and backend code. Would it even make sense, and would it be convenient to use? How would one set up such a project?
- sprkv5 5y ago
  +1 for Ocaml/F# and also the new ReScript. Would you be open to support these on Deno?
- searchableguy 5y ago
  I think you might be interested in this open issue about public API for compiler. https://github.com/denoland/deno/issues/1739 https://github.com/denoland/deno/issues/1739
- bartlomieju 5y ago
  If the tooling you're describing outputs JS sources there's nothing preventing you from using it. Currently there's no way to hook them up directly into Deno, so you'd have to resort to separate build step (via some kind of script, I presume this is just a matter of calling appropriate binary). If those tools help you write better code and you prefer to code in Ocaml/F# then it definitely makes sense, but of course this is personal preference. Drop by at our Discord server [0] to get some tips on how to set up such project. [0] https://discord.gg/deno https://discord.gg/deno

lxe 5y ago

I'm still not a fan of the async iterator API example for server handlers: for await (const conn of Deno.listen({ port: 4500 })) { (async () => { for await (const { respondWith } of Deno.serveHttp(conn)) { respondWith(new Response("Hello World")); } })(); } It's hard to reason, and ugly with that async iffe in the middle adding layers of nesting and bf-like `})();` junk. I think the event subscription API is much easier on the eyes and the mind.

emptysea 5y ago
I'm curious why the IIFE is even necessary in this case. There is already a top level await in the `for await` right? Looks fine IMHO once the IFFE is removed: for await (const conn of Deno.listen({ port: 4500 })) { for await (const { respondWith } of Deno.serveHttp(conn)) { respondWith(new Response("Hello World")); } } Edit: Oh is it so it runs in concurrently and avoids the synchronous handling?
- maddyboo 5y ago
  Yes I think the IIFE is there to avoid the inner loop blocking the outer loop. I think it looks better with the IIFE factored out into its own function: async function serve(conn) { for await (const { respondWith } of Deno.serveHttp(conn)) { respondWith(new Response("Hello World")); } } for await (const conn of Deno.listen({ port: 4500 })) { serve(conn); }

holoduke 5y ago

Any reason why I would use this over expressjs?

FaisalAbid 5y ago

Is Deno production ready?

aitchnyu 5y ago

The example makes me ask, is there a current/planned function to compare two complex objects are value-equalm like lodash `_.isEqual`?

reaktivo 5y ago
You can find and equivalent to _.isEqual here https://deno.land/std@0.104.0/testing https://deno.land/std@0.104.0/testing