281–290 of 310 posts
Earlier quoted context omitted.
Right. So why did you deny it earlier?
I'm answering the part of your question about why I post about something that I find works. Are you this dense in real life or is this an act?
Are you under the impression that HN is some kind of intelligent animal?
Earlier quoted context omitted.
Because you'll have to review it, and Go's design limits the number of ways it can go wrong. Code is free, sure, but it's not guaranteed to be correct, and review time is not free.
If code must be correct, and review time is not free, and review time is costlier than code time, why not just ... ... write the code yourself?
Earlier quoted context omitted.
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.
Well, that's just metaprogramming. 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 l…
Biggest thing was lack of cooperative multitasking until virtual threads (Project Loom). And much older, lack of lambdas before Java 8.
I think Go isn't bad choice. It is widely popular, so I'd assume there's plenty of it in training sets and has stable APIs, so even "outdated code" would work. There's also rich ecosystem of static analyzers to keep generated code in check. On the other hand I think Rust is better by some margin. Type system is obviously a big gain but Rust is very fast moving. When API changes LLMs can't follow and it takes many tri…
How are the generated Haskell programs? I imagine much shorter than Go and easier to eyeball for correctness, but can’t say as I’m not fluent in it. LLM-generated procedural Python scripts are very readable in my experience.
Earlier quoted context omitted.
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.
Lambdas have been available for 10+ years. 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…
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.
Earlier quoted context omitted.
im a java guy, but it simply takes too long to start up and uses too much memory to be a reasonable language for ai agent development.
"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.
Earlier quoted context omitted.
Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.
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.
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.
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…
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.