51–60 of 134 posts
Earlier quoted context omitted.
Working with both I can say that this is a big no, go mod is as fast if not faster, usually Go dep are much faster because Go does not import as much dependencies as Rust.
In Rust you only need to compile your dependencies once. After that it's just your app because dependencies don't change.
This was an obvious next step. Most current products can only restrict the token prediction to valid JSON or a specific JSON schema at best. There's no reason that this should be the only grammar available for constrained output mode. The real challenge will be to make this detect and switch languages automatically. For example, a snippet of code could include a LaTeX formula in a comment and SQL in a string literal.…
SRLCG: Self-Rectified Large-Scale Code Generation with Multidimensional Chain-of-Thought and Dynamic Backtracking https://arxiv.org/abs/2504.00532 IterGen: Iterative Semantic-aware Structured LLM Generation with Backtracking https://arxiv.org/abs/2410.07295 ROCODE: Integrating Backtracking Mechanism and Program Analysis in Large Language Models for Code Generation https://arxiv.org/abs/2411.07112v1
There was also an hn thread: https://news.ycombinator.com/item?id=36425375
Earlier quoted context omitted.
This is about the speed with which the compiler can advise an LLM that a particular thing checks or doesn't check. Typescript is much slower than Go
okay so basically the faster compiling means a tigher feedback loop for the LLM to -know- if the code compiles or not etc? interesting is go faster than rust?
TypeScript has a type system that is complex enough, you can literally implement wasm inside it (and then use that to run e.g. Doom: https://socket.dev/blog/typescript-types-running-doom)
I think TypeScript is uniquely positioned to be the optimal language for LLMs. Tons of training data (benefiting from all the JS examples as well) plus the structure of types for LLMs to follow and tools to enforce.
The vibe code society would benefit way more if libraries hosted their docs in a way that's easy to copy and paste into an LLM.
Earlier quoted context omitted.
God help us…
what do you dislike about it?
So for these reasons alone I would be against using TS as a lingua franca for LLM codegen (as is GP I assume). As another commenter mentioned, LLMs have a tendency to throw their hands^Hlogits up when presented with complex TS type errors and just resort to using `any` to get it to compile (and probably hiding bugs).
And that doesn't even touch the issues with the JS/TS ecosystem and runtimes more broadly.
Earlier quoted context omitted.
https://ai-sdk.dev/llms.txt
Depends on the library I guess, I spent 12~ hours today vibe coding with LiveKit and their /llms.txt is https://docs.livekit.io/llms.txt
I've never seen it check-in uncompilable code, but watching the Devin console I can see it building and using the code to ensure commits are not complete garbage. When it has checked-in compilable and almost right but slightly wrong code, automatically running lint and tests (it doesn't always run them before checking in) from ci triggers it to push a fix on its own.
Feedback loops are nice, but they can be expensive, and time consuming (oh look at me complain that it takes Devin a whopping 15 minutes to complete a task) so I can definitely see the value in type constraints.
Are there some related works?