- 主题:rust和自动驾驶
哦,那是我看错了。
rustc有个feature(plugin)要删除,Simon表示servo最近没什么人搞了,即使给servo做迁移方案,servo也恐怕没什么人实际做迁移工作。如果只差servo就不用管servo了。
【 在 eGust 的大作中提到: 】
: 刚看了一下主 repo,最近一个 merge 是22小时之前,为啥说没人维护了?
:
--
FROM 117.147.20.*
clickhouse基本归到和elasticsearch一路了吧,
更不是正经RDBMS。
【 在 chaobill 的大作中提到: 】
: clickhouse 之类的呢
:
--
修改:cn62 FROM 175.42.43.*
FROM 175.42.43.*
有了 clickhouse, 现在是不是用 es 的少了一些?
【 在 cn62 (cn62) 的大作中提到: 】
: clickhouse基本归到和elasticsearch一路了吧,
: 更不是正经RDBMS。
--
FROM 47.243.39.*
不太清楚,国内就看到字节用clickhouse比较多。
【 在 hgoldfish 的大作中提到: 】
: 有了 clickhouse, 现在是不是用 es 的少了一些?
:
--
FROM 175.42.43.*
我说的前端工具链指的是swc那些, 把 babel webpack tsc 等等用 rust 重写, 速度可以提高两个数量级
【 在 eGust (十年) 的大作中提到: 】
: 我觉得是整体 cli/tui 工具都有被重写的趋势,常用 cli 工具几乎都有 rust 版
: 比如 ls - exa, grep - ripgrep,find - fd,sed - sd,cat - bat,tmux - zellij
: 前端工具的话,我只有 node version manager 用了 fnm。前两天还看到有 npm 的实现,反正我觉得蛋疼,就 rust 提升那点儿速度能节省0.1%的时间么
: ...................
--
FROM 123.120.160.*
这方面目前来看,esbuild 用做 dev-server,然后 bundle 走另外一个 pipeline 是正确的选择。
vite 就是这种,利用浏览器对 esm 的支持,只编译需要的文件。而 webpack/rollup 等等的 bundler 会把所有文件都分析一遍,不管用得着用不着。项目一旦大起来,这个复杂度不是换成 rust 就能降低的。
另外一方面,esbuild 做的事情也不是 swc 能替代得了的。作者明确表示过,整个设计都是以速度优先,能做的事情非常有限,也不支持 plugin。简单来说,除了类型擦除,几乎不做任何事。类型检查交给 ide/editor 解决,在 build 之前自己跑 tsc 去检查。
另外,微软最近有一个新提案,让 js 支持 type 语法。简单来说,ts 就是合法的 js,但类型相当于 jsdoc 的作用,js 引擎不做类型检查。如果通过了话,以后连类型擦除的工作都不用了,基本上 dev-server 就是做点儿加 metadata、解决一下 path aliases,我理解连 sourcemap 都不用生成了。
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我说的前端工具链指的是swc那些, 把 babel webpack tsc 等等用 rust 重写, 速度可以提高两个数量级
--
FROM 203.211.108.*
vite 是一个新思路的产物, 和工具链用不用 rust 改写这个话题没关系
esbuild 也是这个广义的重写 web 工具链的运动的一部分, 而且应该算是先驱, 只不过使用 go 写的. 作者说, 当时只是想要把 js 写的版本机械改写为更快的语言, 试过 rust, 但 rust 没有 GC, 很多 tsc 原有的数据结构根本没法实现, 太麻烦, 所以才改用 go 写了.
如你所言, 虽然有了 vite, 但是生产链路还是需要 bundle 的, tsc babel 这样的
transpiler 需求也一直存在. 哪怕微软成功把类型塞进了 tc39, es 的各版本之间的转换照样不可避免.
【 在 eGust (十年) 的大作中提到: 】
: 标 题: Re: rust和自动驾驶
: 发信站: 水木社区 (Tue Mar 29 12:42:53 2022), 站内
:
: 这方面目前来看,esbuild 用做 dev-server,然后 bundle 走另外一个 pipeline 是正确的选择。
:
: vite 就是这种,利用浏览器对 esm 的支持,只编译需要的文件。而 webpack/rollup 等等的 bundler 会把所有文件都分析一遍,不管用得着用不着。项目一旦大起来,这个复杂度不是换成 rust 就能降低的。
:
: 另外一方面,esbuild 做的事情也不是 swc 能替代得了的。作者明确表示过,整个设计都是以速度优先,能做的事情非常有限,也不支持 plugin。简单来说,除了类型擦除,几乎不做任何事。类型检查交给 ide/editor 解决,在 build 之前自己跑 tsc 去检查。
:
: 另外,微软最近有一个新提案,让 js 支持 type 语法。简单来说,ts 就是合法的 js,但类型相当于 jsdoc 的作用,js 引擎不做类型检查。如果通过了话,以后连类型擦除的工作都不用了,基本上 dev-server 就是做点儿加 metadata、解决一下 path aliases,我理解连 sourcemap 都不用生成了。
:
: 【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: : 我说的前端工具链指的是swc那些, 把 babel webpack tsc 等等用 rust 重写, 速度可以提高两个数量级
:
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 203.211.108.*]
--
FROM 123.120.160.*
作为独立的 pipeline,bundle 的效率并不敏感,花10秒还是10分钟对 deploy 流程来说没什么实际影响。反正也不大可能有一拍脑袋,突然决定5分钟后随机发布一个版本的需求
另外,vite 的 bundle 流程也是一样使用的 esbuild,如果 ts 想做类型检查,那还是得拿 tsc 走独立的流程。基于 esbuild 的设计,已经不大可能出现功能比它更丰富、方便写插件,但速度却更快的工具,更不可能快上一个数量级了。
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: vite 是一个新思路的产物, 和工具链用不用 rust 改写这个话题没关系
: esbuild 也是这个广义的重写 web 工具链的运动的一部分, 而且应该算是先驱, 只不过使用 go 写的. 作者说, 当时只是想要把 js 写的版本机械改写为更快的语言, 试过 rust, 但 rust 没有 GC, 很多 tsc 原有的数据结构根本没法实现, 太麻烦, 所以才改用 go 写了.
: 如你所言, 虽然有了 vite, 但是生产链路还是需要 bundle 的, tsc babel 这样的
: ...................
--
FROM 203.211.108.*