Fwiiw

I noticed that CC’s generated Go code nowadays is very solid. No hallucination recently that i can remember or struck me. I do see youtube videos of people working with js/ts still struggling with this. Which is odd, there is way more training material for the latter. Perhaps the simplicity of Go shines here.

CC might generate Go code for which there are already library functions present. So thorough code reviews are a necessity.

Modern idiomatic JavaScript and TypeScript encourage "clever" code. The latter also has a very complicated type system, which, again, is frequently used, especially in .d.ts files for pure JS libraries because JS devs love tricks like functions doing different things based on number and type of arguments. So models learn all that from the training set, but then often can't deal with the complexity they themselves introduce.

Much as I dislike Go, it is indeed probably closer to the ideal language for the LLM. But I suspect that we need to dial it down even further, e.g. no type inference whatsoever (so no := etc). In fact I wonder if forcing the model to spell out the type of every subexpression as a type assertion might be beneficial due to the way LLMs work, for the same reason why prompting for explicit chain-of-thought improves outputs even with models not specifically trained to produce CoT. In the similar vein, it could require fully qualified names for all library functions etc. But it also needs to have fewer footguns, which Go has aplenty - possible to ignore error returns, concurrency is unsafe etc. I suspect message passing a la Erlang might be the best bet there but this is just a gut feel.

Of course, the problem with any hypothetical new PL optimized for LLMs is that there's no training data for it. To some extent this can be mitigated by mechanically converting existing code - e.g. mandatory fully qualified names and explicit type assertions for subexpressions could be easily bolted onto any existing statically typed language.

This is precisely what the CC extension does, no? At least that’s how the extension behaves in JetBrains IDEs.

Nope. It allows the CLI to read and parse your files. It absolutely does not give you Cursor-like interactivity.

If I’m wrong I’d be overjoyed! But I have it installed and have seen no hint of this.

It doesn't give you a Cursor-like experience but it gives Claude Code the LSP info, which means it will make less mistakes, especially with TypeScript

I started a new project to test out CC and constantly find I have to ask it to fix ts errors…it’s nice I don’t have to tell it what error it is (ie “fix the ts errors in file.tsx”) but I’m surprised it doesn’t have a “check ts” step automatically (i even added something to CLAUDE.md, which seems to work sometimes, but not always). It’s especially bad when working with recently updated libraries. It keeps suggesting thing that don’t exist anymore even though ts clearly knows it’s wrong.

Otherwise CC has been stellar and I live it’s a CLI + optional vs code extension.

I’ve used Cursor a good deal and also CC. The CC JetBrain extension replaces my code in the IDE, shows me a preview ans allows me to confirm, decline, etc. Am I missing something super specific about Cursor’s behavior? It doesn’t seem that practically different to me.

The CC vscode plugin can also fetch the errors and warnings reported to vscode by other plugins and language Servers, making the additional compile step obsolete

That's the biggest reason that the IDE plugin exists, so that Claude Code can get access to the LSP information

Right. Which it can. But to suggest that this makes it Cursor-like is wildly misrepresentative.

Copilot in vscode is so bad about typescript errors as well.