@changwei #2 superbase 讨论热度高是因为适合当前 AI 一天写一个网站的环境。
这俩不好比较，因为不是一个东西，不过可以参考下这个：
https://www.devtoolsacademy.com/blog/neon-vs-supabase/

go 不适合，但 rust 写得不好更不适合。
rust 难就难在写法太多，要压榨出最佳性能可不是靠 AI 胡扯就行的。

go 如此简单你都看不懂 AI 写的代码有哪些陷阱，更不用说 rust ，我怕你来回改最后性能连 go 都不如。

@superhot #4 打包工具可以正确处理 namespace import ，例如 zod 推荐统一使用 import * as z form 'zod'
barrel 的缺点不是 tree shaking ，只要没有副作用，打包器是能正常 tree shaking ，但是开发阶段的首次启动变慢了，热更新变慢，各种 CI 检查都会变慢。因为必须加载完全部代码全能分析出用到了哪些代码，但是如果全路径定位到文件本身，就不需要对 n 个模块的复杂关系进行非常耗时的分析，因为桶文件经常会引用桶文件，几乎要把全部项目几千个文件都分析完才能梳理出单个文件的依赖图关系，哪怕它的直接依赖只有几个文件，如果只分析引用的实际依赖，整体计算量会指数级下降。

@superhot #3 IDE 会自动更新路径，除了 PR 难看点也没什么影响。
我曾经抱有相同的想法，模块内的改动不会影响到外部，这被称为封装性好。
但反过来说，它隐藏了一定的信息量
import {a} from '@/a'
import {a} from '@/a/b/c'
第二种写法是很长，但一眼就能看出这是第几层嵌套的模块，它可以培养开发者把文件当成模块的习惯，而不需要人为构造一个模块

还有一个是统一写法的问题，如果 eslint 不进行限制，同样一个导入有 n 种写法
import {a} from '@/a'
import {a} from '@/a/b'
import {a} from '@/a/b/c'
如果统一禁止掉桶文件，只有一种写法。
我能接受团队内的任何固有习惯，但我希望只能用一种习惯，不要给我第二种选择。

@craftsmanship #1 因为早期编辑器没有自动导入，为了省几个字符开发人员就想了个"巧妙"的方法少写点，现在的话没必要了，而且实际上并不会少写多少。

社区里可能有一万个惯例实际上是反模式，从来如此不一定是对的。
例如有些风格指导库会让只有一个导出时使用默认导出而非具名导出，例如 Airbnb ，在 ts 下这是错的，应该尽量避免默认导出，除非不得不用 (配置文件、i18n)。

两个缺点：
1. neon 开源部分几乎停止维护
2. 供应商锁定
除此之外没有缺点，想用就用呗，只要记得免费不等于没有代价就行

@wangym20804 #9 高并发、数据堆积、分布式事务是微服务带来的副作用，单体项目如果达不到承载上限不会有这些问题。就拿消息堆积来说，为什么消息会堆积，因为微服务调用链路过长，等待内网延迟过久，加上各种分布式组件带来的开销，一个简单请求从几十毫秒变成几百毫秒甚至几千毫秒，处理速率慢了十倍百倍当然会导致数据堆积如山。
这跟业务简不简单完全是两码事，复杂的巨石单体应用多得是，难不成 aws 、stackoverflow 的业务很简单吗？
有些项目天生适合微服务，有些项目天生适合单体，但以我的观点，世界上 99%项目根本不需要微服务，而且多数人根本处理不好微服务带来的额外复杂度。

令人讽刺的是，最终 aws 把自己的`微服务->单体`博客给删掉了，毕竟微服务用户越多，他们的产品越好卖
https://web.archive.org/web/20230504060528/https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

@Seulgi #5 虽然要做的事情很简单，但实现起来相当困难。最大的问题在于各种软件没有通用的、标准化的操作途径，这个项目的很多代码都是土法手搓各种不可复用的模拟调用方法。
再往后，新时代的面向用户的软件应该要主动暴露相关入口便于 AI 介入，并且版本号说明要提供结构化的相关列表，目前各种解决方案的随机崩溃率太高，只能是一个过渡方案。

@ragnaroks #26 对于计算密集型场景，nodejs 可以把这部分任务交给 napi-rs
就我个人体验来说，性能是一个复杂项目中最不重要的指标

@iorilu 没有必要再学一门"后端语言"。
除非公司项目硬要扣一点性能，monorepo+ts+全栈是 AI 时代性价比最高的做法。
目前公司的所有后端项目都用 ts 重写了，我们对性能要求很高，但至今为止还没碰上 nodejs 带不动的场景，就算 nodejs 性能差一点也可以换 bun 。

@duuu #9 外国的信用卡基于"信用"本身，付款人可以取消支付，因此免密信用支付才能推行下去，被意外盗刷了用户是可以不认的。
而且这也不是盗刷，用户授权给游戏公司，游戏公司生成一笔交易订单推送给支付渠道，支付渠道验证后批准这笔交易，在支付渠道看来，这是一笔正常的交易。
不管国内还是国外，都是一模一样的流程，如果这事发生在中国，就是绑定支付宝/微信的用户授权给游戏开通免密支付，结果发现自己的支付宝/微信余额被莫名扣减。

> 商家一定无法控制扣谁的钱
这是错的，商家能控制扣谁的钱是免密支付的基石。
用户授权给商家，那么就相当于把自己钱包的部分管理权授予给商家，商家拿到你的令牌可以请求平台进行交易，平台只会验证密钥、令牌、余额等信息，对支付平台来说，它不会也不能去验证这笔钱是不是你发起的。而在这个案例中，是商家发错信息了，平台依照请求忠实地促成这笔交易，第一过错是发错东西的商家，第二过错是把令牌授予商家的用户，支付平台在这里没有任何过错。
一般来说，碰上这种事支付平台会狠狠地罚商家一大笔钱，因为它的信誉受损，信誉或者信用是支付平台能长久运营的基石。

拿 xxl-job 和 airflow 比较很奇怪，它们是完全不同的东西。
xxl-job 踩在了过于简单与过于复杂中间，且对 javaer 友好，让一些屎山项目能够顺利迭代下去。
xxl-job 之类的工具是基于微服务且明确违反微服务设计哲学的实用性妥协方案，它实际反映出很多公司是为了使用微服务而使用微服务，而不是需要使用微服务而使用微服务，如果是后者居多，那么并不需要这么一个"分布式调度中心"。
对于更复杂的分布式调度，不应该采用高入侵性方案，而是应该搭建一个调度平台 https://github.com/temporalio/temporal

@hellojukay 轮着来难道不是指一家人轮流去娘家/婆家吗，我不理解你这"一个人"是什么个意思。
我姐和姐夫就是这样的，我没觉得有什么问题。

失业金没影响，进小程序会告诉你能领多少个月
确定入职下家公司后要申请停止领取，不然公司交不了医社保

你的反感是对的，但正确方式不是抵制它，而是控制生成的代码的质量。
vibe coding 主要有两个作用远胜于传统编码：1. 快速出 demo 、快速使用从未接触过的库; 2. 强大的静态检查。
除此之外，vibe coding 并没有解决编程的实际复杂度，它只能作为开发人员的一个工具，而是否能用好工具，与工具本身无关。

@liminany1 因为 99%中药对 99%病人没有作用，爱吃就多吃点。

愚蠢的人类，妄想从随机数里找到规律

我说个暴论，凡是用得上 EventEmitter 的项目，99%是屎山