I own this as well and while I appreciably the levelized cost, there is simply zero comparison to my gen 1 Studio Display. The gloss and shin on the Kuycon means it only works in dimmly lit rooms.
Nano texture in mixed lighting scenarios is worth every penny even on a lower resolution and lower refresh rate panel.
Coming here virtually/in person to confirm that even though it’s a bit rude to “rank” people, I basically struggle to understand how incredibly good Frank is - extraordinarily fast, deeply capable, and kind to a fault. A very uniquely, typical, amazing Recurser.
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it.
Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns.
The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams to adopt agentic coding workflows at my consultancy [0], Go delivers highly consistent results via Claude and Codex regularly and more often than working with clients using TypeScript and/or Python.
When LLMs have to navigate Python and TypeScript there is a massive combinatorial space of frameworks, typing approaches, and utility libraries.
Too much optionality in the training distribution. The output is high entropy and doesn't converge. Python only dominated early AI coding because ML researchers write Python and trained on Python first. It was path dependence, not merit.\
The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction.
Go has many many failings (e.g. it took over a decade to get generics). But LLMs don't care about expressiveness, they care about predictability. Go 1.26 just shipped a completely rewritten go fix built on the analysis framework that does AST-level refactoring automatically. That's huge for agentic coding because it keeps codebases modern without needing the latest language features in training data or wasting tokens looking up new signatures.
I spent four years building production public key infrastructure in Golang before LLMs [1]. After working coding agents like everyone else and domain-switching for clients - I've become more of a Go advocate because the language finally delivers on its promise. Engineers have a harder time complaining about the verbose and boilerplate syntax when an LLM does it correctly every single time.
Java has decade(s) of cruft and breaking changes which LLMs were trained on. It's hard to compare. Plus Go compilation speed/test running provides quick iteration for LLMs.
There is a decently long list of breaking changes now. Removing JavaEE modules from the JDK, and restricting sun.misc.Unsafe, are the ones people usually run into.
A long enough list of small changes eventually equates to a big change. People generally can't update applications from Java 8 or below to a new one without code updates.
If hadoop did it, so can you. I'm talking about a project that stretched Java 8 to, and arguably beyond, its intended operational boundaries. Unlikely that you’re leaning on this boundary. It's Spring Boot upgrades that will be giving you troubles.
Not really. It has a pretty bare bones OOP (single inheritance, interface), primitives and objects, generics and pretty much that's it.
Newer features fit very nicely and didn't increase the language surface (records are just a normal class with some methods auto-generated, while sealed types are just a restriction on who can subtype an interface -- and yet these give full ADT support for the language that improves readability and type safety).
Annotations add a seemingly infinite amount of new semantics. You can’t predict anything with confidence just looking at the code without also studying the annotation processors in depth, which regular Java tools don’t help you with.
Also, java annotation processors are strictly "append-only", they can't change code written as is. They may subclass it, or build new classes that make use of the annotations.
In my experience LLMs are more than happy with annotations, especially from the widely used ones (spring/jakarta ee, lombok though it's not an annotation processor, etc).
If you think about it, an annotation like @Path("/endpoint") is very informative for both humans and LLMs alike, being local to what it attaches to. Within an agent, the code serving the endpoint will be immediately visible in the context returned by a simple string search, no need to do another round of "find wherever this codebase registers routes".
That metaprogramming is how a lot of places end up doing Java, because Java is a bad language that needs crutches like that. Or at least needed until whatever newer version fixed limitations of the old one, but all that old code is still around.
Biggest thing was lack of cooperative multitasking until virtual threads (Project Loom). And much older, lack of lambdas before Java 8.
It’s even simpler to have a “register” method that takes the path specification, the HTTP verb, and a function to handle the request.
There is no case where annotations are superior to the meta programming facilities built into the language proper. Annotations only became popular because Java didn’t have easy syntax for function references or anonymous functions for a very long time.
Also, hard disagree on "register" method being simpler. A register method is code, while an annotation is a static declaration, ergo data. The former can happen in a helper function, renaming it from "register" to "path", changing/modifying the parameters, or putting it into some while loop dynamically generating endpoints.
At the very extreme it is Turing complete to figure out what endpoints are registered.
10+ years of lambdas, but you can still tell from new code that the language used to not have lambdas. Plenty of code is older than that too.
The annotations are static, yeah. That's one advantage. I would still rather not do that. A lot of people were happy not to need that anymore in like NodeJS.
Sandboxing is a completely orthogonal issue and WASM is probably not a good direct target for LLMs.
Of course writing a language that compiles to Wasm is certainly a way, but you would have to sandbox also all the other tools that is used during development (e.g. agents can just call grep/find/etc).
How are JVM startup times nowadays? Frankly the need to ship with a JVM (modulo graal admittedly) is a drawback, eg for CLI tools - which the author listed as a requirement. Go's static executable story, combined with it's competitive performance - without C++ or rust contortions - is a strong combo when your focus is on startup time and deployment simplicity. (If, otoh, I cared a lot about GC I'd definitely prefer Java - eg for non-fast algo trading.)
Java is a fine language, tech stack, and ecosystem, but I agree with the author and parent commenter that this is a sweet spot for Go. Their decision to use it makes a lot of sense.
Exactly, the propping up of Go seems unfounded. Java in it's newest iterations make it more compelling as a target, and people, especially young people, overlook it because of its stigma as enterprise cruft.
Most of the young people like me learned Java as a first language in AP Computer Science, then probably again in college. We were tested thoroughly on all the OOP details and required to use that in projects. The most popular video game is/was also in Java, and people love to mod it.
But still nobody wants to use it given the choice, because it sucks. 75% of the code you write is boilerplate mainly thanks to OOP, the com.foo.bar stuff is an eyesore, and it somehow uses even more RAM than Python. That's without getting into the enterprise cruft land where each method has 3 annotations on it, where the annotations themselves are maintained by an entire outsourced team.
Well, you should have learned about the language something in the meanwhile then.
75% boilerplate, come on. It has records and pattern matching now. Many of the cases of boilerplate are strictly self inflicted. And this criticism is absolutely laughable in a thread about Go, where you have to repeat some error ritual every 3 lines, losing the signal in all the noise. Java is a much more concise language than Go.
com.foo.bar solves a very real issue that is a big problem in e.g. the Node and Rust ecosystem (package name squatting).
And it uses as much RAM as you set it to use. It's true of every managed language that more memory equals less work to do, that is better throughput. But Java's GCs are the state of the art, it will work just fine with half the pre-configured memory.
However, the cause it not really Java as such, but massive frameworks and tooling (e.g. Maven). Maybe AI will bring some fresh air to Java, because old truths might no longer be valid. But it will be hard to get rid of old habits because it manifested in AI training data.
"AI guys" use Claude CLI that renders to a terminal via freakin' react.
Come on, java starts up fast enough and the memory usage can be set (better throughput vs less memory, it's a classic tradeoff. Go just defaults to worse throughput).
Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly.
Java takes flags for min/initial/max memory that, as a strict law of nature, are always wrong the first time you try. And it holds onto unused memory unless you pass another flag. Idk exactly why there's no reasonable default for that, but probably cause it's in a VM. No other language has this problem.
> Come on, java starts up fast enough and the memory usage can be set
Yeah it can be adjusted, on the other hand you have a language that just works.
Starts instantly and memory usage is bounded by usage, not guesstimate of how much the JVM will need.
> Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly
Have you many java projects that didn't use some fat framework?
Good for you if you did, but 100% of java project I had the displeasure of touching were huge mess with deprecated frameworks on ancient java versions.
The points about tooling certainly do not apply to Java, for example, Maven vs Gradle (which is a huge mess in and of itself - do you use Kotlin or Groovy), and which plugins are you willing to pull in? Or is Ant still the thing? SpotBugs, Spotless? What test framework do you use? Do you use Mockito or one of the myriad alternatives?
Go has _none_ of this nonsense, and it's better for it. Nor does Rust, FWIW, which IMO is also a better target language than Java for just about everything.
Gradle could be used as an AI benchenmark on its own! The syntax of plugin DSLs changes all the time. Special credits could be achieved for handling old (Groovy) and new versions (Kotlin) of Gradle itself.
I mostly write Go code (and have barely had to write any code myself in the past months), but today I had to do some work in a Java project and Claude Code was a terrible experience.
It really felt like using AI tooling of a year or two ago. It wasn’t understanding my prompts, going on tangents, not following the existing style and idioms. Maybe Claude was hungover or doesn’t like mondays, but the contrast with Go was surprising.
One example is that I wanted to add an extra prometheus metric to keep track of an edge case in some for loop. All it had to do was define a counter and increment it. For some reason it would define the counter the line before increment it, instead of defining it next to the other counters outside of the for loop. Technically not wrong (defining a counter is idempotent), but who does that? Especially when the other counters are defined elsewhere in the same function?
Anyway, n=1 but I feel it has an easier time with Go.
Well, there was a Claude outage today, maybe related :D
My n=1 is that it is pretty good with Java, on par with other popular languages like Python and JS, in line with these 3 probably being a good chunk if not the majority of training data.
> 'The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction.
This lines up neatly with the kind of low‑abstraction systems I like running: 2021 HP PC with i7, bare‑metal‑ish, Crunchbang++, no desktop, openbox window manager. Boots to login in 17 seconds. Terminal front and center — local AI bare-metal inference, no wrapper, ffmpeg, ffplay, etc.
Go’s “no abstraction ceiling” feels like the same preference at the language level: shallow stack, no indirection, and code that stays close to the metal. That’s why LLMs work so well on Go: it’s opinionated, predictable, and there’s usually one obvious way to do things. Personally, I've come to love a LACK of abstraction.
I'd have said the same a few months ago, but looking at the code quality that the SotA LLMs right now I have to say it's excellent and the problems they have are not with the language but with the subject problems, esp. when they require some complex design that isn't well documented beforehand. They seem to struggle with keeping a world model. Languages themselves, they run circles around humans.
Now the case for Go or for other tightly standardised languages is that whatever the LLM produces, you're likely to be familiar with and make sense of its decisions. With C++, you can generally steer the LLM to refactor things in a certain way but it's extra steps. With Ruby it works surprisingly well too. I'm a lot less happy with their results in Lisp or in Bash/zsh for instance, and mixed results in C depending on what you give them to start - they just come with such random stuff. But it may be just a matter of training set and the relative free-form of those languages.
> But LLMs don't care about expressiveness, they care about predictability.
I think this is true, but it misses a very key point. Go does an impressively bad job at designing APIs that are difficult to misuse, so LLMs will misuse them and will require also writing unit tests to walk through it, just to validate it used the libraries correctly. This isn't always possible (or is awkward/cumbersome) for certain scenarios like database querues.
All of the reasons people argue Go is good for LLMs are more true for Rust. You and the LLM can design libraries to be difficult to misuse, and then get instant feedback from the compiler to the LLM about what it did wrong, and often with suggestions about how it should fix them! This also makes RL deriving from compiler feedback more effective.
This allows the LLMs to reason more abstractly at larger scales, since the abstractions are less leaky (unlike in Go). The ceiling on abstraction screws you here, since troubleshooting requires more deep diving. It's the same reason Go projects become difficult for humans at large scales, too.
Go is not difficult to maintain at large scale, I mean take Kubernetes for example, it's "trivial" to understand and modified even though it's in the millions loc.
Kubuernetes is built by a trillion dollar company who has the resources to manage QA and dev tooling at a scale that the vast majority of teams do not.
Take async for example. You have to choose some third-party async runtime which may or may not work with other runtimes, libraries, platforms, etc.
With Go, async code written in Go 1.0 compiles and runs the same in Go 1.26, and there is no fragmentation or necessity to reach for third party components.
It is literally being changed constantly. They chose to add it to the Linux kernel but they have to build the features they need into the language as they go. It's not backward compatible like C and C++ either. Sure, there are a couple of versions you could try to pin to in Rust, but then all your libraries need to be pinned to the same version (to be fair, this last part is an assumption).
It's not, especially the part about it being actively changed to adapt to Linux. I've heard several complaints about this already. I may have been a little harsh on the stability concerns but I stand by my assertions in general.
Rust is harder for the bot to get "wrong" in the sense of running-but-does-the-wrong-thing, but it's far less stable than Go and LLMs frequently output Rust that straight up doesn't compile.
LLMs outputting code that doesn't compile is the failure mode you want. Outputting wrong code that compiles is far worse.
Setting aside the problems of wrong but compiling code. Wrong and non-compiling code is also much easier to deal with. For training an LLM, you have an objective fitness function to detect compilation errors.
For using an LLM, you can embed the LLM itself in a larger system that checks it's output and either re-rolls on errors, or invokes something to fix the errors.
I wonder: How does Rust and Haskell compare to Go when it comes to LLM code generation? I was always thinking that the compiler induced feedback loops could give these languages an edge?
What would be the best language properties for LLM assisted coding?
It is easy to get started in. Some of the major warts it has, at least the ones that annoy me, revolve around deployment and management. Python packaging has been "fixed" at least 6 times
Golang is the best language there is for most workflows that aren't bare metal embedded or have real time requirements, and this is coming from a 20 year+ C++ dev.
I agree with most of this. You can learn Go syntax in an afternoon. Idiomatic Go takes a little longer but it just doesn't have the complexity footguns C++ does. But you can shoot yourself in the foot somewhat in Go. I'm talking about buffered channels, which are a mistake most of the time and a premature optimization almost all of the time, and you can explode your program with goroutines. But honestly it's not bad.
Python is an interesting one because it's not always obvious the program is wrong or will fail, thanks to dynamic typing.
But another problem is the Python philosophy since 3.0. Where once backwards compatibility was treated as almost sacrosanct, 3.0+ does not. 2.7 persisted for so long for this reason. But minor releases in 3.x make breaking changes and it's wild to me.
I just wish Go had cooperative async/await rather than channels because (IMHO) cooperative async/await is a vastly superior abstraction to unbuffered channels in particular.
LLMs are great with Typescript. But the fact remains that there are many different browsers and several runtimes (Node, Deno, Bun), each of which may have slightly different rules.
> As someone familiar with those ecosystems, I'm have trouble envisioning the degree of operator error or imprecision that would cause this to be a problem.
Because you are familiar with the ecosystem? Just like python devs saying it's normal to juggle with 3 package managers to run a simple script.
Back to your original point: You also are biased by what you are used to use.
Thankfully, I don't have to touch any JS project anymore, but oh god what a nightmare it is.
Even just having CLI tools requiring constant updates to not break randomly during the day is enough pain that I won't touch that with a 10m pole.
I genuinely think you're having a mental health episode. I don't see any other way to justify your reaction to my post. Or the fact that you've now gone through my post history and made several more rude posts.
On the off chance that I'm wrong and this is just your normal personality (in which case, God help you): what extraordinary claim did I make? Quote it.
> I genuinely think you're having a mental health episode
It's not acceptable to post like this on HN. It counts as name-calling, snark, flamebait and other breaches of the guidelines. We're trying for curious conversation here, not this. I understand the other commenter was the first to escalate, but it takes two to make a hellish subthread like this.
I think you have a pattern not reading comments which answer your questions before you ask them which then causes negative reactions.
> On the off chance that I'm wrong and this is just your normal personality (in which case, God help you):
When asked to stop making personal attacks, you made more. I've flagged your comment and reached out to @dang, I think your behavior is inappropriate for this forum.
Looking at the site guidelines, do you feel your comments are appropriate and following the spirit of the site rules? Really?
If your first comment in the subthread wasn't escalatory enough, this phrase in your second comment was way out of line:
> Surely you're not just talking out of your ass
It's not cool to start a flamewar like this then call in moderator support when replies get heated. We can't take sides in a flamewar like this when both participants are going at each other.
You evidently understand plenty how HN's guidelines and moderation work. Please make more effort to uphold the standards that are expected here in future.
Maybe your cultural frame is that mental health isn't a protected category and it's an appropriate insult. That's not what the law says in professional environments and that's not been my experience in professional discourse.
If your attitude is that if one person litters it's now ok for anyone else to dump on protected categories, it's your clubhouse and you can set the rules.
That's your right, and it's also my right to say that I don't want to be associated with this forum even indirectly.
Could you provide me with a good email address to send my CCPA request to delete all my data and comments and account? I sent emails to a few YC addresses with:
"I am writing to request that you delete my personal data from all of your paper and/or computer records pursuant to Section 1798.105 of the California Consumer Privacy Act (CCPA)
To the extent that you rely on consent to process my personal data, I withdraw that consent. To the extent that you rely on your 'legitimate interest' to process my personal data, I object to the processing as there are no overriding legitimate grounds.
If you are selling my personal data to third parties, please consider this email as my direction to you not to sell my personal data to third parties.
Please don’t ask me to perform a self-service process such as locating my information on your website, filling out a form, or providing a mobile advertising ID. These requests place an undue burden on my side.
If you are not able to comply with my request to delete all of my personal data, please advise as to the specific reason for which this request cannot be acted on. Please advise which sections and subsections of the law you are relying upon, and identify the specific reason for which you are relying on those exceptions, such as which legal obligation, or internal purpose or use. Please delete all my personal data which does not fall under these exceptions."
I have not received a response.
I can write again in 46 days with a complaint attached mentioning you personally and a letter from my state representative indicating they'd like to know more as well. Or you can resolve this quickly in a mutually amicable way by just deleting my account and all my comments.
I replied to the other commenter before I replied to you and made it clear that comments attacking other community members with insults about mental health are not acceptable.
Without circular investments and valuations what would Open AI be worth? 100B? 300B? Entirely on revenue alone it seems like 20B. Current valuation appears to be two orders of magnitude off.
>Without circular investments and valuations what would Open AI be worth? 100B? 300B? Entirely on revenue alone it seems like 20B. Current valuation appears to be two orders of magnitude off.
They just passed $20B in revenue, you can't really expect a company with this much hype and traction to have a 1x multiple.. that's not to say a 35x multiple makes sense either.
All I see everywhere is "OpenAI generated $13 billion in revenue in 2025" and it just cost them $8 billion. $5B loss in 2025 and projections of losing $14B this year.
I guess making the investment conditional on the company doing an IPO (or something that will never happen) should remove any doubts.
But I'm not sure there is enough money on the world (literally) for them to get an IPO high enough. If they sell too little of the company, they'll be still holding the bag when it fails.
Well technically "Open""AI" is a SaaS company. It should be worth almost nothing due to AI being able to code AI (AI training is probably the simplest enterprise code).
This is interesting for offloading "tiered" workloads / priority queue with coding agents.
If 60% of the work is "edit this file with this content", or "refactor according to this abstraction" then low latency - high token inference seems like a needed improvement.
Recently someone made a Claude plugin to offload low-priority work to the Anthropic Batch API [1].
Also I expect both Nvidia and Google to deploy custom silicon for inference [2]
Note that Batch APIs are significantly higher latency than normal AI agent use. They're mostly intended for bulk work where time constraints are not essential. Also, GPT "Codex" models (and most of the "Pro" models also) are currently not available under OpenAI's own batch API. So you would have to use non-agentic models for these tasks and it's not clear how well they would cope.
(Overall, batches do have quite a bit of potential for agentic work as-is but you have to cope with them taking potentially up to 24h for just a single roundtrip with your local agent harness.)
Openai has a "flex" processing tier, which works like the normal API, but where you accept higher latency and higher error rates, in exchange for 50% off (same as batch pricing). It also supports prompt caching for further savings.
For me, it works quite well for low-priority things, without the hassle of using the batch API. Usually the added latency is just a few seconds extra, so it would still work in an agent loop (and you can retry requests that fail at the "normal" priority tier.)
That's interesting but it's a beta feature so it could go away at any time. Also not available for Codex agentic models (or Pro models for that matter).
I built something similar using an MCP that allows claude to "outsource" development to GLM 4.7 on Cerebras (or a different model, but GLM is what I use). The tool allows Claude to set the system prompt, instructions, specify the output file to write to and crucially allows it to list which additional files (or subsections of files) should be included as context for the prompt.
Ive had great success with it, and it rapidly speeds up development time at fairly minimal cost.
Late reply, but the answer is:
1) there is a fair amount of behind the scenes work going on that I dont want the agent to have access too or know about. Tools make it very easy to have strong control over what can and cannot be done. File system access is built directly into the tool, which makes it much easier to be confident about what it has access too, since the thing that actually has the permissions is the tools code, not the agent.
2) Portability, I can host it from a single spot and serve it to multiple models on different machines easily, which is very desirable for me.
3) I can update the configuration of the tool independent of a skill.
A skill wouldn't be a bad option though, and I highly recommend creating one yourself! The ability to customize our workflows and tools to a high degree is one of the largest strengths of agentic coding.
MCP is fine if your tool definition is small. If it's something like a sub-agent harness which is used very often, then in fact it's probably more context efficient because the tools are already loaded in context and the model doesn't have to spend a few turns deciding to load the skill, thinking about it and then invoking another tool/script to invoke the subagent.
Is that true? I had tool use working with GPT-4 in 2023, before function calling or structured outputs were even a thing. My tool instructions were only half a page though. Maybe the long prompts are causing problems?
They're talking about "skills" which are not the same thing as tools. Most models haven't been trained on the open SKILL spec, and therefore aren't tuned to invoke them reliable when the need occurs.
Much like people have different takes on the right way to do the SDLC, we're gonna see a lot of takes on orchestration. None of are really that meaningful until we unblock on validation, but to the extent that they also come with observability tools, they're at least useful there. I'm dubious of agent specific silo'd task management though, that should be surfaced to entire teams.
These comments are comical. How hard is it to understand that human beings are experiential creatures. Our experiences matter, to survival, to culture, and identity.
I mourn the horse masters and stable boys of a century past because of their craft. Years of intuition and experience.
Why do you watch a chess master play, or a live concert, or any form of human creation?
In fact, contrary things are so very often both true at the same time, in different ways.
Figuring out how to live in the uncomfortableness of non-absolutes, how to live in a world filled with dualisms, is IMO one of the primary and necessary maturities for surviving and thriving in this reality.
Yes. Unwillingness to accept contradicting data points is holding many people back. They have an unconscious need to always pick one or the other, and that puts them at a disadvantage. "I know what I think." But no, you do not.
This is so naive, you watch chess masters not because of the quality of the end result of the chess game but because it illustrates human ability, it's entertainment.
SWE the quality is measured in the end result, there's no beauty in handcrafted barely working code. So if machines come to the stage where they program better than 90% of human developers then yes the craft is done for. The profession is dead.
You can talk to LLM to give it specs for what you want built but that's basically a totally different profession that a high-schooler would do and salaries will soon follow suit.
Nano texture in mixed lighting scenarios is worth every penny even on a lower resolution and lower refresh rate panel.
reply