I wish if err != nil return err was just 1 token.

Joking aside, as much as Go's stdlib and tools do the heavy lifting here, Go's verbostiy and expressing simple things in lots of lines worked against me most of the time.

▲

frollogaston 8 hours ago | parent | next [-]

Heh, I checked https://platform.openai.com/tokenizer to see if they made it 1 token, it's not.

▲

nomel 9 hours ago | parent | prev [-]

I've had a really terrible time getting LLM to properly handle errors as return values. It seems that bubbling up errors, in a side channel, to a contextually relevant point in the code (exceptions) seems MUCH easier for LLM to reason about/implement properly.

Maybe my problem is I'm using a language with exceptions, so trying to go against the statistical grain, with return values, is just too much.

▲

frollogaston 8 hours ago | parent [-]

Exceptions are inherently better for high-level code, where basically every loc can fail and 99% of the time you only want to bubble that up. You only want errors as values in systems code, where exceptions would be landmines. Rust and Go both did that because they were at least originally designed for systems code.

Also, Go makes it way too easy to accidentally swallow an error. Rust doesn't have that problem.

	▲	6 hours ago \| parent [-]
		[deleted]