Deno 1.0

@pockry 这就扯淡了，解释型语言凭什么和编译型语言比冷启动速度
而且这个玩意儿还要先把 ts 编译成 js，还不地 node 冷启动快
当然，如果这玩意儿能在部署前构建成 wasm 那还能快一点

第一感觉居然是...logo 很萌

@Vegetable 不用太敏感，我举例说明下包管理分离是常见做法。

Cargo 设计的不错也很强大，但没必要贬损 npm 与 pip 。

@hafuhafu 喜欢 Logo +1 2333

@xingjue 自己坐了高铁，然后抱怨高铁车太长，车上人多。自己坐了飞机，然后嫌弃飞的太高。既然只有三行代码，你完全可以步行啊。。。

@xingjue 可是事实是 php 在下滑,node 在上升

justjavac 早年风评 md 程序员...
但是老实说....实力还是比大部分人强....

@pockry @whileFalse
Deno 在部署的时候可以可以直接加 V8 cache，冷启动还是很快的。
关于 TypeScript 需要转译的问题，Deno 的官网上已经说了，“TSC must be ported to Rust”，现在虽然很慢，但未来换到 Rust 实现之后，速度会快很多的。

@youxiachai md 程序员是啥，搜了下没搜到，总不会是 markdown 吧

@cairnechen 就是 markdown .....这个属于当年的风评了...

@youxiachai

"justjavac 早年风评 md 程序员"

今年应该还是吧

实际上用 v8 做后端，最后是准备用 rust 做一个 typescript 的前端？

进一步了解可以看 Deno 中文手册，官方的由于 github 部分被墙而看不了。
https://ex.noerr.eu.org/t/671658

比较关心直接使用 URL 作为引用包的地址，打起字来会不会手疼，以及包的版本如何统一管理

@fanchangyong
第三方库放在 deps.ts 中，然后从 deps.ts 中引入到代码中，管理 deps.ts 就行
url 过长可以使用 import_maps，https://deno.land/manual/linking_to_external_code/import_maps

node 这个坑够大了，又开个新坑。与其用这玩意儿写后端，还不如直接用 rust 性能好, 后端性能这一块基本 pass 了。
写前端的话，node 还是够用的，所以为啥用 deno 呢，deno 类库生态都没有。这玩意儿早点凉凉是最好的了。

@liuguang #76 Deno 在设计上是为了替代 bash 和 python 在系统管理中的应用，和 Rust 场景不重合

注意 Deno 的作者同时精通 JavaScript Golang 和 Rust，但是他仍然认为需要这么一个属于程序员的"瑞士军刀"

至于生态，Node.js 里的模块抛掉技术债，经过现代化改造后都是 Deno 的生态

用 URL 来引入依赖很激进啊....最后感觉可能要 reinvent 包管理器

我自己做了一个翻译工具，叫 Breword, 专门用来翻译开源项目文档， 已经用它翻译了 redux, koa, node-mysql 等项目文档。

最近我已经把 Deno 的文档抓取了下来，欢迎一起来翻译：

https://www_breword_com/projects/5ebcb0f5ddcf37001b4c33eb

一段好的翻译，必须建立在对原文充分理解的基础上，所以，在翻译文档时，也是一个非常好的学习机会。

Breword 这个翻译工具支持自动监测文档更新，一旦源项目更新后，会在 Breword editor diff 出译文的差异，方便维护译文文档。所以，我们会持续将 deno 的中文文档维护下去。

期待你的参与。

为了卖衣服写了一个代码库，难道这就是有钱人的生活？