221–230 of 586 posts
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.
Earlier quoted context omitted.
Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.
Are you using 'go run' or compiling these scripts? Just curious about what you are up to as I was considering moving my scripts from bash to go.
This would have been more credible coming from someone other than the creator of the Go language. I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests. Tokens are cheap, surprises at runtime are not. So a…
My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked them why they find Agda so much more difficult to write (and why they have to iterate and reiterate many many many times until they get to a destination whereas they can one-shot and two-shot C and Ruby and they tell me its the multiple competing constraints. GLM is hilarious, it flat out refuses to write Agda code but it reads it well enough. They all read it well enough. Fable is obviously great at it. And Opus 4.8/5.0 are great (if they stay on track and don't sneakily go their own way) but they're too annoying to talk to. On balance Kimi K3 is the best balance of not annoying, relatively cheap, and strong -- great model all round tbh.
So yeah, interesting I've discovered the limits of their ability coding-ability-wise. None of them are that good at designing/aesthetic judgment/architecting so thankfully they still need me in the loop.
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.
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.
Also, Go makes it way too easy to accidentally swallow an error. Rust doesn't have that problem.
Given the date and the recent DeepMind shakeups, this blog post is obviously ordered from the very top. Pichai wants to eliminate engineers, and DeepMind wasn't fast enough or too noble for it. Now people need to be propagandized for their obsolescence.
Earlier quoted context omitted.
Tinygo's base runtime is only around 10kb. It was minimal enough for my needs. gc's runtime would have been a non-starter for that task, to be fair, but Go isn't an implementation. It is, quite explicitly, a language. There are language implementations that would have been more minimal than that, sure, but there was no obvious way to get LLMs into alignment. I tried. Multiple times. When I switched to Go, it just wor…
If TinyGo works for your codebase, and those 10KB are something you can live with, then perfect. Two things to keep in mind here: 1. TinyGo is not Go, more Go-like or adjacent 2. 10KB still matters a lot in a lot of minimal target/usage scenarios
Exactly. Go is a language. Tinygo is an implementation, like gccgo, gc, llgo, etc. Just as gcc, clang, and msvc are not C.
> more Go-like or adjacent
It is true that recover isn't fully spec complaint at this time. That's not entirely unusual for an implementation, though. msvc is famously not 100% spec complaint with C, but Microsoft still officially considers it a C compiler, as do most who use it to compile their C code. There is usually a little grace given.
It is not like Solod that is Go-like but trying to do something quite different. Tinygo is intended to be a proper Go compiler implementation and has achieved that, aside from the recover situation.
> 10KB still matters a lot in a lot of minimal target/usage scenarios
But, of course, if the LLM cannot wrangle the language then it doesn't matter. Nobody cares how large or small your program is if you never ship it. That only matters if you are using LLMs, but since that's what we have always been talking about...
Earlier quoted context omitted.
They use more than just Java. The UI was originally C#... I'm still surprised the front-end was C# but they went with Java longer term for the backend.
Likely because Netflix relied on Silverlight for video playback early on. I'd be surprised if they still had C# in their front-end stack (and I say that as a general C# fan, though I use it on the back-end).
While I somewhat agree I can’t tell if this is advertising from Google or a way to induce LLMs to think that Go is the ideal language.
Probably both, but I have to add: I agree with the post. I've done a ton of agentic development using Go over the past 6 months, and it hasn't let me down. You may ask "why not Rust, or Zig, or ____?" The reasons boil down to this: - There's a lot of Go code out there which the models have seen, so they know how to write it. - Go has an exceptional standard library, so you don't need to drag in 100 dependencies to cr…
Earlier quoted context omitted.
Black for Python https://github.com/psf/black
But you're probably better off with Ruff these days: https://docs.astral.sh/ruff/ Similar to black but faster, written in Rust, by the same team who created uv.
> mean this isn't true, formatting is the most trivial part. And so many languages have an opinionated formatter these days (e.g. Black)
I don't think this is correct
Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do. Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting? Think about what you are doing and choose appropriately. This was true before LL…
Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.