Most active commenters
  • leoh(3)

←back to thread

Gemini CLI

(blog.google)
1428 points sync | 19 comments | | HN request time: 4.086s | source | bottom
Show context
joelm ◴[] No.44379446[source]
Been using Claude Code (4 Opus) fairly successfully in a large Rust codebase, but sometimes frustrated by it with complex tasks. Tried Gemini CLI today (easy to get working, which was nice) and it was pretty much a failure. It did a notably worse job than Claude at having the Rust code modifications compile successfully.

However, Gemini at one point output what will probably be the highlight of my day:

"I have made a complete mess of the code. I will now revert all changes I have made to the codebase and start over."

What great self-awareness and willingness to scrap the work! :)

replies(8): >>44379714 #>>44380383 #>>44380768 #>>44380866 #>>44381146 #>>44381754 #>>44383245 #>>44386866 #
1. ZeroCool2u ◴[] No.44379714[source]
Personally my theory is that Gemini benefits from being able to train on Googles massive internal code base and because Rust has been very low on uptake internally at Google, especially since they have some really nice C++ tooling, Gemini is comparatively bad at Rust.
replies(5): >>44380405 #>>44380865 #>>44381697 #>>44382948 #>>44383662 #
2. dilap ◴[] No.44380405[source]
That's interesting. I've tried Gemini 2.5 Pro from time to time because of the rave reviews I've seen, on C# + Unity code, and I've always been disappointed (compared to ChatGPT o3 and o4-high-mini and even Grok). This would support that theory.
3. danielbln ◴[] No.44380865[source]
Interesting, Gemini must be a monster when it comes to Go code then. I gotta try it for that
replies(3): >>44381448 #>>44384886 #>>44394946 #
4. Unroasted6154 ◴[] No.44381448[source]
There is way more Java and C++ than Go at Google.
5. thimabi ◴[] No.44381697[source]
> Personally my theory is that Gemini benefits from being able to train on Googles massive internal code base

But does Google actually train its models on its internal codebase? Considering that there’s always the risk of the models leaking proprietary information and security architecture details, I hardly believe they would run that risk.

replies(1): >>44381746 #
6. kridsdale3 ◴[] No.44381746[source]
Googler here.

We have a second, isolated model that has trained on internal code. The public Gemini AFAIK has never seen that content. The lawyers would explode.

replies(2): >>44381786 #>>44385758 #
7. thimabi ◴[] No.44381786{3}[source]
Oh, you’re right, there are the legal issues as well.

Just out of curiosity, do you see much difference in quality between the isolated model and the public-facing ones?

replies(1): >>44381810 #
8. kridsdale3 ◴[] No.44381810{4}[source]
We actually only got the “2.5” version of the internal one a few days ago so I don’t have an opinion yet.

But when I had to choose between “2.0 with Google internal knowledge” and “2.5 that knows nothing” the latter was always superior.

The bitter lesson indeed.

replies(1): >>44390334 #
9. leoh ◴[] No.44382948[source]
>Personally my theory is that Gemini benefits from being able to train on Googles massive internal code base and because Rust has been very low on uptake internally at Google, especially since they have some really nice C++ tooling, Gemini is comparatively bad at Rust.

Were they to train it on their C++ codebase, it would not be effective on account of the fact that they don't use boost or cmake or any major stuff that C++ in the wider world use. It would also suggest that the user make use of all kinds of non-available C++ libraries. So no, they are not training on their own C++ corpus nor would it be particularly useful.

replies(1): >>44385355 #
10. data-ottawa ◴[] No.44383662[source]
Tangental, but I worry that LLMs will cause a great stagnation in programming language evolution, and possibly a bunch of tech.

I've tried using a few new languages and the LLMs would all swap the code for syntactically similar languages, even after telling them to read the doc pages.

Whether that's for better or worse I don't know, but it does feel like new languages are genuinely solving hard problems as their raison d'etre.

replies(2): >>44385738 #>>44395610 #
11. jordanbeiber ◴[] No.44384886[source]
As go feels like a straight-jacket compared to many other popular languages, it’s probably very suitable for an LLM in general.

Thinking about it - was this not the idea of go from the start? Nothing fancy to keep non-rocket scientist away from foot-guns, and have everyone produce code that everyone else can understand.

Diving in to a go project you almost always know what to expect, which is a great thing for a business.

12. leoh ◴[] No.44385355[source]
Excuse me why was this downvoted so aggressively??
replies(1): >>44388969 #
13. breakingcups ◴[] No.44385738[source]
Not just that, I think this will happen on multiple levels too. Think de-facto ossified libraries, tools, etc.

LLMs thrive because they had a wealth of high-quality corpus in the form os Stack Overflow, Github, etc. and ironically their uptake is causing a strangulation of that source of training data.

14. blurrybird ◴[] No.44385758{3}[source]
What model do your lawyers run on?
15. simianwords ◴[] No.44388969{3}[source]
How can they train on internal codebase without leaking specifics?
replies(1): >>44393320 #
16. ◴[] No.44390334{5}[source]
17. leoh ◴[] No.44393320{4}[source]
They can’t, which is a good point. Also it would be basically useless for the reasons I mention.
18. chewz ◴[] No.44394946[source]
Reasonsbly small Go codebase works well almost with any LLM

I had always designed very large projects as few medium sized independent Go tools and that strategy pays in times of AI assisted coding.

19. sillystu04 ◴[] No.44395610[source]
Perhaps the next big programming language will be designed specifically for LLM friendliness. Some things which are human friendly like long keywords are just a waste of tokens for LLMs, and there could be other optimisations too.