Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

Post reply on HN
Print view View original

571–580 of 586 posts

Re: Go is an ideal language for AI-assisted software engineering

#571

Post by iLemming »

bygosh wrote: post #373
rudedogg wrote: post #74

I keep seeing these language specific proclamations, and they are annoying and reek of inexperience to me. I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work. I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it…

do people actually claim LLMs are good with Lisp? all i've seen recently are people frustrated that their model can't seem to balance parentheses.

LLMs are surprisingly good with Lisp dialects. With a caveat - when you give them actual (homoiconic) REPL. It makes little sense treating a Lisp just like any other language, which is roughly the Unix/pipe model - batch-style. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in-between the calls and in files. Each tool invocation is stateless.

Things get far more interesting when you give an LLM a true Lisp REPL. LLM stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens.

Like if you ask any experienced dev to write a Clojure program giving them nothing but a notepad.exe, they'd immediately fail without structural editing and connected REPL. Why people expect that LLM somehow, magically do it better?

Re: Go is an ideal language for AI-assisted software engineering

#572

Post by duckbrain »

majewsky wrote: post #496
olmo23 wrote: post #478

Earlier quoted context omitted.

> But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}. Static analysis tools can catch this, no?

Static analysis does not help if the type comes from a library and is _meant_ to be initialized using a literal. And then upstream adds new fields where the zero value is different from the previous behavior, causing users to silently drift away from the intended behavior. I had this happen to me with a type from std, and had to add a specific test to guard against it with future std upgrades: https://github.com/sapc…

That's a dependency making a breaking change, right?

Re: Go is an ideal language for AI-assisted software engineering

#573

Post by throwaway2037 »

osigurdson wrote: post #536
throwaway2037 wrote: post #369

Earlier quoted context omitted.

> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.

If you reach a scenario that should crash your app, exceptions are fine. However, they are a pain (and brittle in the case of C#) when the intention is to handle them. This is the reason why many newer languages don't use exceptions.

    > brittle in the case of C#
Can you explain more? In my experience, exceptions in Java, C#, and Python are all very stable and not-at-all "brittle".

Re: Go is an ideal language for AI-assisted software engineering

#574

Post by throwaway2037 »

Cthulhu_ wrote: post #547
osigurdson wrote: post #536

Earlier quoted context omitted.

If you reach a scenario that should crash your app, exceptions are fine. However, they are a pain (and brittle in the case of C#) when the intention is to handle them. This is the reason why many newer languages don't use exceptions.

They're also a "thinking error"; most errors are not exceptional and should instead be part of the regular flow of your application. But in 90's/2000's languages like Java and C#, they consider "this file does not exist" as an exception. Second issue is that they include a call stack and are generally pretty expensive to construct. To circumvent this, a lot of exception languages are written in a more defensive style…

It is interesting that you picked Java/C# and "they consider "this file does not exist" as an exception". Firstly, I know more about Java. It is not an exception when testing for the existance of a file that does not exist. However, it is an exception to attempt to open a file (for reading) that does not exist. Also, for those unaware, exception class FileNotFoundException is a subclass of IOException, which is "checked" and cannot be ignored. However, when calling the C function "open" (or "fopen") to open a file, the programmer can easily forget to check the return value. This is harder to do in Java, thanks to the checked exception.

Here is some sample Java code to demonstrate:

    > try {
    >     FileReader reader = new FileReader("file.txt");
    >     // Use 'reader' here.
    > } catch (FileNotFoundException e) {
    >     // ...
    > }
How do you propose to change class FileReader such that it will not throw an exception if the file does not exist?

    > To circumvent this, a lot of exception languages are written in a more defensive style.
I don't understand this comment. Can you provide some examples?

Re: Go is an ideal language for AI-assisted software engineering

#575

Post by caseymarquis »

Go ignores the needs of the developers in favor of the needs of the architect and technical managers.

I’ve always disliked it for that reason.

In roughly November of 2025, “software developer” stopped being a position that humans fill directly. We all became architects and technical managers. Even the most complex code is now pair programmed with an AI.

I’ve chosen go for all new backend work since January 2026.

Development is now about good architecture that optimizes for locality of reasoning, rock solid testing, and categorizing risk on modules to decide what needs human pair programming and detailed review, and what can be safely vibecoded and left to AI to manage.

Frontend dev is now vibecoded directly by PMs at my organization within very specific and heavily enforced architectural constraints. The quality of work went up substantially because the experienced devs now just focus on the rules and review for the fronted codebases, while the PMs focus entirely on UX.

It is a strange new world.

Re: Go is an ideal language for AI-assisted software engineering

#576

Post by lenny321 »

Honestly this article is already 8 months behind. In 6 months they will recommend Rust. Still wrong. Answer already been found. Formal verification or nothing. Lean v4.33.0. Since v4.30.0 LLVMBindings are included making direct projection to llvm IR instead of emitting C or emitting IR

Only formal verification kernels will solve the issues discussed. It cannot make your c design correct, it can only verify the code itself whatever is written.

Point is, this is solved known, and everyone get enough ahead made the jump long time ago.

Also, sorry, standard libs are almost always forbidden now. They can’t be trusted. Anything important is written from scratch.

Why? Go and others standard libs are “broken”, meaning they are half assed lightly defined not purpose built for a developers job. They are general. That was good once upon a time. Not anymore.

Use Go and attempt JSON Canonicalization. You can’t. It’s valid. Proven so. Why? Stdlib json parsing is normalizing and lossy. Fail closed. Float to string violates ecma 262 for floats. Every single action taken is in violation. This is the stage of today’s programmmkng. Developers who don’t even understand what “correct” is. https://lattice-substrate.github.io/blog/2026/02/27/shortest...

The issue is NOT AI LLM, it’s poor development by HUMANS. The same problem we always had.

Post reply on HN