- 主题:rust和自动驾驶
没有想象的那么容易，oracle 自己有 cloud，然后为了让大家都用自己的 cloud，于是又搞了一堆限制，让 aws rds 用起来比以前麻烦很多
aws 为了留住客户，也开发了一套工具能够帮助把 oracle 的数据库包括 plsql 转成 pg。我们试过一次，转完之后没法直接用，还是有不小的距离。我给老板估计的数字是一个人全职搞一年，新客户基本就可以用 pg 了。但现在 oracle 实际上是客户买单，所以老板并不着急搞。而是似乎还有法律上的问题，所以想让 aws 也能出人来一起搞。
反正下狠心的话，哪怕不转 plsql，用其它语言重写核心逻辑，长期来看还是省钱的。老板们也不傻，就 oracle 这种运作模式，逮着一只羊就可劲薅。除非真的有政治原因的，不然新系统能避免用的话，肯定是要避免的
【 在 z16166 (Netguy) 的大作中提到: 】
: 保持壁垒，这样搞oracle的dev和dba能拿高价钱
--
修改:eGust FROM 203.211.108.*
FROM 203.211.108.*
没啥不火的，正经用 sql 的压根就不会考虑不合规定的 mysql/mariadb
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: pgsql 和 mysql 基本兼容的吧，搞不懂为什么 pgsql 不火
--
FROM 203.211.108.*
没听过，不了解
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: clickhouse 之类的呢
--
FROM 203.211.108.*
这方面目前来看，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 (菜Ｍ.喵星耗子) 的大作中提到: 】
: 我说的前端工具链指的是swc那些, 把 babel webpack tsc 等等用 rust 重写, 速度可以提高两个数量级
--
FROM 203.211.108.*
作为独立的 pipeline，bundle 的效率并不敏感，花10秒还是10分钟对 deploy 流程来说没什么实际影响。反正也不大可能有一拍脑袋，突然决定5分钟后随机发布一个版本的需求
另外，vite 的 bundle 流程也是一样使用的 esbuild，如果 ts 想做类型检查，那还是得拿 tsc 走独立的流程。基于 esbuild 的设计，已经不大可能出现功能比它更丰富、方便写插件，但速度却更快的工具，更不可能快上一个数量级了。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: vite 是一个新思路的产物, 和工具链用不用 rust 改写这个话题没关系
: esbuild 也是这个广义的重写 web 工具链的运动的一部分, 而且应该算是先驱, 只不过使用 go 写的. 作者说, 当时只是想要把 js 写的版本机械改写为更快的语言, 试过 rust, 但 rust 没有 GC, 很多 tsc 原有的数据结构根本没法实现, 太麻烦, 所以才改用 go 写了.
: 如你所言, 虽然有了 vite, 但是生产链路还是需要 bundle 的, tsc babel 这样的
: ...................
--
FROM 203.211.108.*