TypeScript compiler in Kotlin multiplatform - I de...
# feed
k
TypeScript compiler in Kotlin multiplatform - I decided to use AI to autonomously rewrite TypeScript compiler in Kotlin, which has the benefit of native and web assembly targets, next to JVM, which might be surprisingly fast here. Microsoft is rewriting TypeScript compiler in Go, to benefit from parallel type checking. I want to benchmark how Kotlin coroutines would stack up. After providing the initial harness, this project is developing itself in full autonomy, using the original TypeScript compiler test suite. Whenever I have unused limits on my Claude account, I give it a go, while observing the heuristics which might be improved in such an environment - for example when an agent is going in circles analyzing low hanging fruits forever, instead of picking remaining issues one by one. The 1st phase is to ship the transpiler, the second is to rewrite the whole type checker. The 1st phase is almost there with maybe 10% of tests still failing. If you want to contribute your compute to this project, you are very welcome: https://github.com/xemantic/xemantic-typescript-compiler
👀 3
K 2
a
As always with those full vibe-coded projects, even if you have 100% of the tests passing, it will often contain many critical security issues or performances gaps I'm using AI too in my projects but I triple check and lead the AI to do the exact things I want, fixing things manually sometimes etc, with recent models and strict instructions it's better but still far from perfection when looked in details :') I find the idea great but I'm afraid that the result will be meh :c
k
This is exactly why I run this experiment - I am not pre-determining the outcome. I am also still coding by hand a lot, but only the code which machines still cannot write, which is mostly applied philosophy and ontologies of metacoginive systems. Rewrite like this compiler still requires a lot of higher level supervision, where I need to actually understand how compilers are working, and build tools first to reduce the cognitive load on the LLM. For example in the form of this project: https://github.com/xemantic/xemantic-kotlin-test It is designed to close the feedback loop between autonomous AI providing the implementation, and environmental response it gets when it fails in assumptions. Funny thing is that big part of this project - the sameAs inifx function, which is a unified diff implementation in Kotlin multiplatform, is my personal eval of LLMs. I had the perfect test suite (using itself) generated synthetically from GNU diff output for unified diff (there was no Kotlin multiplatform implementation). Sonnet 4.5 was the first model able to crack it in 30 minutes, all the models before were failing to deliver. After initial implementation was done, I order 3 more performance / memory optimization passes, and only then the model concluded that there is not much more to improve. The same test suite was passing in every case. As much as I can sympathize with you concerns, I would advice against writing software too much focused on today's LLM capabilities. Building towards the future, also with anticipation of other architectures like diffusion models, seems to me like a way to go.