- I work on the JavaScript toolchain layer where language semantics, compiler correctness, and polyglot distribution meet. - Core member of @swc_rs - 🦀
Beijing
Joined August 2012
- Tweets949
- Following213
- Followers1.8K
- Likes1.1K
阿卡琳 retweeted
Glad to see Yuku’s work shaping the next generation of JavaScript tooling. Congrats to the SWC and Rstack teams!
Introducing SWC Next: the foundation for SWC’s next major version, built on a new architecture inspired by Yuku.
- Up to 3x faster native parsing
- Up to 10x faster parsing through the JavaScript API
- A flat, ESTree-based AST designed for speed, memory efficiency, and JavaScript extensibility
Starting with parsing, we’re bringing the rest of SWC to this new architecture.
Built together by the SWC and Rstack teams.
阿卡琳 retweeted
Introducing SWC Next: the foundation for SWC’s next major version, built on a new architecture inspired by Yuku.
- Up to 3x faster native parsing
- Up to 10x faster parsing through the JavaScript API
- A flat, ESTree-based AST designed for speed, memory efficiency, and JavaScript extensibility
Starting with parsing, we’re bringing the rest of SWC to this new architecture.
Built together by the SWC and Rstack teams.
Applied to Codex for OSS!
Over the past year, Codex has helped us fix bugs, resolve long-standing issues, and deliver major performance improvements in SWC.
Excited to keep pushing SWC forward with Codex!
We started Codex for OSS six months ago.
Today, we’re renewing the program with $100 Pro plans and doubling the number of grants (from 5,000 to 10,000) to reach more maintainers.
(If you received a grant previously, we encourage you to re-apply!)
openai.com/form/codex-for-os…
Thank you @kdy1dev and @Soon_Iter for becoming my GitHub sponsors! Your support means a lot to me and helps me continue contributing to open source.
Thank you @hardfist_1 for sponsoring me on @github. You can join them at my sponsors profile: github.com/sponsors/magic-ak…
Thank you @hardfist_1 for sponsoring me on @github. You can join them at my sponsors profile: github.com/sponsors/magic-ak…
原子组合, 遵循 unix 哲学, 有极好的正交性和复用性. 但组合不是免费的, 在上下文切换边界有着性能损耗.
巨大单体, 就像 systemd, 强耦合极致性能. 但是难以拆出来单独使用其组件.
鱼和熊掌, 怎样才能都要?
有些 PR，实际上是在往项目里硬塞一段逻辑，直接扭转原有设计，只为了拟合某个提交者自己撞上的业务场景。
它不关心系统整体一致性，也不关心抽象边界，只会留下一句：“默认关闭，不影响兼容性。”
最后，项目不再有统一逻辑，只剩下一堆互相踩踏的开关。代码演化成没人敢动、没人能懂的混沌体。
Would it be secure if we do it this way?
Do you know that using GitHub CLI (gh) may expose you to supply-chain attacks?
It stores a long-lived GitHub token on your machine, which can be stolen by any malicious scripts.
This is what happened in the recent Nx Console supply-chain compromise, which led to GitHub’s internal source code being leaked.
