Hugo

I found esbuild will never support emitDecoratorMetadata. What do you think about it?

@millsp I found anther proplem,maybe it is not the curry , but IntersectOf.

is there any example use trpc in vue 3?

Due to this https://github.com/WebAssembly/threads/issues/163, this proposal may never be stage 3. But according to the issue above, browsers already did their job.

Though rust is now first class citizen in wasm world, but I still think when go can support thread natively, go will be No.1 wasm player in more high level...

> 在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活. > > 试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决 个人认为，zod 最主要还是在与 json 衔接的地方（通常是后端与前端的交界处，用户输入到前端接口的交界处）提供运行时的类型检查，其目标要比 TS 的类型简单一些。所以并不见得要灵活成 TS 那样。其关注点就是当前的 json 的形状，外加一些业务规则限制。

> > > 在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活. > > > 试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决 > > > > > > 个人认为，zod 最主要还是在与 json 衔接的地方（通常是后端与前端的交界处，用户输入到前端接口的交界处）提供运行时的类型检查，其目标要比 TS 的类型简单一些。所以并不见得要灵活成...

> > > > > 在调研Zod时,发现存在一个困难点是, 我要使用zod的语法, 努力重写一遍我在service中已经实现过的ts类型声明; 一方面, 有重复工作的问题(虽然运行时校验和静态校验是两回事,但是意图上一一致的); 另一方面, zod对泛型等一些ts类型体操相关能力的支持好像存在问题,不能像ts类型定义那么灵活. > > > > > 试图google过 直接从ts type生成zod定义的工具, 也许可以解决第一个问题, 但是第二个问题还是无法解决 > > > > > > > >...

I think maybe you can try some test by remove sse and avx for compiler parameter.

> 潮流是个圈，兜兜转转又回来了，实际上也可以用当前市场行情来看， 互联网加速内卷，各行各业不好受，大公司头部公司裁员，那相应的提升竞争力只能从技术上着手，一个又会前端又会后端的人明显比只懂前端的人吃香，对公司而言一个人干了两个人的事情，岂不是更好。 https://tinyclouds.org/javascript_containers RD 最近发了个文，去探讨 JavaScript 容器的问题。如果后端确实能分裂成纯业务逻辑层和非业务逻辑层，那中间的业务层，无论是前端还是后端，用一种语言开发，效率肯定是最高的。就算市场行情好，技术的发展也会朝着效率更高的方向发展。只不过，市场行情不好，对工作效率的要求会更高，也算是一种推动力。 也许过几年，对程序员的需求是对各类 worker 有了解，而不是对 linux 有了解。云计算就真成水电煤了。