@SuperMild 看到你的 monostich 了。请教个问题。

为什么 jar 里有 kotlin 的 class ，是因为 javalin 引入的吗？

@iseki kotlin 1.0 时候用过一阵，不过项目后来 java 重写了。kotlin 实现找不到人。不知道现在有没有好点。公司好多小伙连 var x = new XX(); 这种语法糖都不吃。

@Aloento 主要就为了练练手，公司主要用 java ，但是用看包装 x 层的 spring 。转前端好几年了，想着搞点 java ，后面整点 kpi 活。

还是卡，都直接卡死了。还没有 idea 舒服。

xfs 。就是看不惯 lost+found 。

自从 webstorm 打开 2k 行的 .vue 文件卡死之后，只用 webstrom 看 git 记录。

没有人觉得 webstorm ，应该说 jetbrain 做的 git ui 特别好用吗？

@codehz

张宏波曾经是 ocaml 的核心开发（？）。bucklescript 的编译器也是 ocaml 写的，好像也通过转换移植了 ocaml 的一些标准库吧。bucklescript 的语法很多是直接抄 ocaml 。bucklescript 编译出来就是 js 代码。官方介绍是人类可读的 js 代码。

然后 bucklescript 又造一个语法（官方好像是叫 theme ），叫 reason 。reason 的语法比较接近 js 。reason 好像是给 facebook 造的。官方就支持直接写 react 的组件。bucklescript 、reason 实际上是共用一个编译器。

再后来张宏波回国之后，又将 reason/bucklescript 重新命名为 rescript 。rescript 好像只支持 reason 语法。

reasonml 不知道是什么。

----

以上都是凭记忆写的。

前端不懂业务已经是固有印象。但是 spring boot 写 CRUD 的后端就不要看不起前端了，五十步笑一百步。

前端上手太容易了，特别是 vue 、react 之类的工具的出现，都让人有一种“学几天我也行”的感觉。然后一看代码，一阵“清香”。代码写得好的、结构设计得好的前端实在不多。但是并不所有老板都能理解前端的难点。老板在业务和代码质量两者中选择，必然是前者。同理写 CURD 的后端也是一样的。

但前端的路似乎比较窄，看着是没有后端空间多。后端的天花板也比前端高。

那个 touch bar 是个好设计。左侧的自定义键盘也很有想像力。量产似乎不还容易实现。

来一个星星

说的是文档工程师吧

后端 28k 可能是带运维的吧。毕竟前端就是一个 nginx ，不需要运维。

js 工具链是真的卷。卷 rust ，卷 go ，现在又来卷 zig 。rust 、go 起码有稳定版本，zig 现在还是很早期阶段。

ts/jsx 转换、bundler 使用 zig 实现，也加入 node_modules 的支持算法，这部分可以对标 esbuild （ go 写的）。bun 也加入 napi 支持，似乎可以直接使用 nodejs 的一些 c 拓展。

JavaScriptCore 用来跑 js 代码。JavaScriptCore 性能可能比 v8 差点，至少很多 benchmark 结果是这样的。README 上写是比较容易集成到 zig 代码吧。

编译似乎是用 build.zig ，说不定自己编译 bun 会比较简单。

roadmap 还很长很长。不知道啥时候能清掉。

有意+1 。希望文档可以优秀一点。

手上的多个 vue2 项目，属于长期维护的项目，保持小版本更新。大版本属于有生之年系列，比如 vue2 -> vue3 。这哪能叫升级，基本上是重写了。

M590 ，蓝牙，少占一个 A 口

最近迷上这个

https://marketplace.visualstudio.com/items?itemName=fabiospampinato.vscode-monokai-night

对比过 caddy 、nginx 、traefik proxy 。

caddy 的好处就是自带 auto https 功能、静态文件服务（ traefik proxy 没有内置），配置也比较省事； traefik 也支持 letsencrypt 支持，更倾向反向代理场景，动态配置比较方便，和 docker 配合也很容易。

可是，但凡有点性能需要，应该首选 nginx 。nginx 也支持 letsencrypt ，看着配置比较复杂。

kotlin 可以的。不想要 jvm 的，就 rust