Totally agree. After trying to flesh out Unreal's git plugin, it really shows how far from ideal git really is.
Partial checkouts are awkward at best, LFS locks are somehow still buggy and the CLI doesn't support batched updates. Checking the status of a remote branch vs your local (to prevent conflicts) is at best a naive polling.
Better rebase would be a nice to have but there's still so much left to improve for trunk based dev.
Most people I've seen complain say things like "I asked it for code and it didn't compile."
The real magic of LLMs comes when they iterate until completion until the code compiles and the test passes, and you don't even bother looking at it until then.
Each step is pretty stupid, but the ability to very quickly doggedly keep at it until success quite often produces great work.
If you don't have linters that are checking for valid syntax and approved coding style, if you don't have tests to ensure the LLM doesn't screw up the code, you don't have good CI, you're going to have a bad time.
LLMs are just like extremely bright but sloppy junior devs - if you think about putting the same guardrails in place for your project you would for that case, things tend to work very well - you're giving the LLM a chance to check its work and self correct.
It's the agentic loop that makes it work, not the single-shot output of an LLM.
Stuff like this works for things that can be verified programmatically (though I find LLMs still do occasionally ignore instructions like this), but ensuring correct functionality and sensible code organization are bigger challenges.
There are techniques that can help deal with this but none of them work perfectly, and most of the time some direct oversight from me is required. And this really clips the potential productivity gains, because in order to effectively provide oversight you need to page in all the context of what's going on and how it ought to work, which is most of what the LLMs are in-theory helping you with.
LLMs are still very useful for certain tasks (bootstrapping in new unfamiliar domains, tedious plumbing or test fixture code), but the massive productivity gains people are claiming or alluding to still feel out of reach.
It depends - there are some very very difficult things that can still be easily verifiable!
For instance, if you are working on a compiler and have a huge test database of code to compile that all has tests itself, "all sample code must compile and pass tests, ensuring your new optimizer code gets adequate branch coverage in the process" - the underlying task can be very difficult, but you have large amounts of test coverage that have a very good chance at catching errors there.
At the very least "LLM code compiles, and is formatted and documented according to lint rules" is pretty basic. If people are saying LLM code doesn't compile, then yes, you are using it very incorrectly, as you're not even beginning to engage the agentic loop at all, as compiling is the simplest step.
Sure, a lot of more complex cases require oversight or don't work.
But "the code didn't compile" is definitely in "you're holding it wrong" territority, and it's not even subtle.
Yeah performance optimization is potentially another good area for LLMs to shine, if you already have a sufficiently comprehensive test suite, because no functionality is changing. But if functionality is changing, you need to be in the loop to, at the very least, review the tests that the LLM outputs. Sometimes that's easier than reviewing the code itself, but other times I think it requires similar levels of context.
But honestly I think sane code organization is the bigger hurdle, which is a lot harder to get right without manual oversight. Which of course leads to the temptation to give up on reviewing the code and just trusting whatever the LLM outputs. But I'm skeptical this is a viable approach. LLMs, like human devs, seem to need reasonably well-organized code to be able to work in a codebase, but I think the code they output often falls short of this standard.
(But yes agree that getting the LLM to iterate until CI passes is table-stakes.)
I think getting good code organization out of an LLM is one of the subtler things - I've learned quite a bit about what sort of things need to be specified, realizing that the LLM isn't actively learning my preferences particularly well, so there are some things about code organization I just have to be explicit about.
Which is more work, but less work than just writing the code myself to begin with.
IME it does fail pretty hard at first. One has to build up a little library of markdown and internal library of prompt techniques. Then it starts working okay. I agree there is a hurdle still, trying it on one task doesn't really get one over the hurdle.
Windows update is how it used to work and it's terrible. An update breaks old apps, or downloads a every single version (not feasible). Who would want to run windows update to install a new app?
It's just a bad idea. Today we just pack in the DLLs and it just works.
No one suggesting using Windows Update to install new apps, they are suggesting the current .Net framework should be elevated to a first class Windows citizen and included with Windows installs and updated with Windows Update, and that seems like and obvious idea that should have been implemented when .Net Core became .Net.
We would like it to be good. Whichever way to achieve goodness - either be backwards compat, or ship all the stable versions, I don't care but the current situation is silly. Apple gets flack for this and that, but their UI toolkit situation is lightyears ahead; you just pick the OS version you want to target in your app build settings and it will work that way for everyone.
100 MB per runtime, for everyone, and the majority of them are out of support. Is that really the good option? Why not the option the author dismissed: a 9 MB AOT-compiled executable which doesn't need a separate runtime?
That's something which is MS' problem; they're supposed to be the company who is best at backwards compatibility, but clearly have strayed from that path.
Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code.
The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times.
Actually, really like maven, it's focus on building in standard way is fantastic (but agreed, it look messy, with all its xml and necessary versioning).
Actually, I like Maven. It's perfect for code that is broken into medium-sized projects, which makes it great for service-oriented architectures (would have said microservices here instead, but think we're learning that breaking our services too finely down is generally not a good idea).
Yeah, it seems like Maven is designed to build just one project with relatively little build-code (although, figuring out versioning of the libs used in your build can get tricky, but guessing this is how it is in most languages). It's still one of my favorites build tools for many situations.
LOL I wish. LLMs massacre gradle code all the time. Once you're past boilerplate generation and doing anything remotely unusual they can't stop hallucinating broken shit that they insist works.
I've been using maven for 20+ years, gradle for 10? ant for 5 before that. sbt for 15. I've written custom plugins for all of them. I know them quite well, unfortunately.
I use LLMs to maintain them now. I keep the build files simple. It was an inconvenience before, but a trifle now.
* The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java.
* Log4shell, amongst other vulnerabilities.
* Super slow to adopt features like async execution
* Standard repo usage is terrible.
There is no point in using Java anymore. I don't agree that Rust is a replacement, but between Python, Node, and C/C++ extensions to those, you can do everything you need.
> Python, Node, and C/C++ extensions to those, you can do everything you need.
Or you can use Java and have libraries that cover almost anything provided in those languages, having access to a massive pool of labour when needed.
> * Log4shell, amongst other vulnerabilities.
As if no Python, JS, C/C++ libraries ever had vulnerabilities? That's a non-sequitur, every ecosystem has security issues, the most important aspect is how quickly they are fixed. Given Java's massive size, a lot of libraries see high usage, and are actively developed, so security patches are released quite quickly.
> * Standard repo usage is terrible.
What does this even mean? Standard library?
Java has its place, it's boring technology that gets things done, and let companies hire from a immense pool.
By the way, over 25 years of carreer I have professionally worked with Java, Scala, Kotlin, Clojure, Obj-C, Go, Python, Ruby, PHP, JS, even ASP 3.0, and some .NET (C# and F#). I'm not a Java purist but I call your arguments a bit bullshit, all of these languages have their places, strengths and weaknesses, the sooner you realise they are tools and if they are generally used perhaps there's something valuable about each of them, the sooner you stop wasting time trying to argue why "X sucks, use Y".
Use the best tool for the job, knowing more tools is never bad.
> Java and have libraries that cover almost anything provided in those languages,
This is pretty funny.
or example, the other day I wrote a menu for mac os using rumps. Simply pip install rumps, write code, run, boom Mac os menu. Let me know when I can do the equivalent for java, or any other "performant" language.
>As if no Python, JS, C/C++ libraries ever had vulnerabilities?
Comparing the severity of log4shell to any python vulnerability is beyond crazy.
You have the Apache foundation, pushing its logging library as the industry standard, and multiple people saw no problem with not only the idea of a log statement being able to execute arbitrary code from the internet, but also making it the default behavior.
If at that point, everyone would instantly abandon any software from Apache in Java, I would have more respect for Java devs. But of course, they can't, because the ecosystem is so small that there is no replacements, so everyone is forced to cuck out to Apache, and who knows what and when other idiotic decision they are going to make.
There are plenty of other issues to cover on Java, but the log4shell pretty much is indefensible. Even if Im wrong about everything else, my argument still stands on that alone.
Re Gradle using groovy/kotlin: so what? Gradle is not a standard any more than Maven, and java is not primary used as a scripting language, so it makes sense that it has a different language for its config files? What's the deal here?
Show me a language without vulnerabilities.
It has virtual threads for quite some times and it is a much much better choice for most use cases than async.
This discussion kind of irks me. I just read these posts as:
"The quote saying A is bad. Actually it said A all along!"
It's just complaining about others making a different value judgement for what is a worthwhile optimization. Hiding behind the 'true meaning of the quote' is pointless.
As far as alternatives, I wonder if anyone has tried a screen that cycles through colors in a known sequence. Using this modulating-color screen, it might actually be easier to separate the subject because you get around the "green shirt over green screen" problem. You might even be able to use a time sampling to correct the light cast on the subject from the screen as you would have a full spectrum of response.
I could also imagine using polarized light as the backdrop as well.
the general problem with any technique that isnt just throw some vaugely green thing behind our actors is that setting up complicated tech like this on an actual film set is extremely expensive. both the time it would take and the risk of it not working. so you end up with a dedicated permanent stage install but now you need to get the actors and crew to that place. better keys isnt a bad enough problem to justify that effort/cost. even the highly touted "virtual production" mandalorian stuff where you just put a big led wall behind the actors has shown to be more expensive than traditional vfx unless you tightly control the creative or approach.
And all the people aware of the production technique watch it and imagine the characters saying "We can't run from the monster in different direction, our virtual production stage is precisely this big!"
What alternative would they be referring to? Green threads were only (re-)introduced to Java in version 21 in 2023.
I think what they're trying to say is that Java's green thread implementation has special support for async I/O. Threads that block on I/O aren't polled for completion by the runtime, instead they use OS async features under the hood.
This allows Java's green threads to compete performance-wise with async/await solutions, but with cleaner code that doesn't need colored functions.
In older green thread implementations in other languages, I/O can actually cause significant CPU overhead due to polling threads that are blocked by I/O requests.
I think the DSM 5 says a disorder must cause clinically significant distress or impairment in social, occupational, or other important areas of functioning.
Correct. But even that definition risks over pathologizing the human experience. It creates a distinction between a broken brain and a reasonable reaction to a broken environment.
DSM defines a disorder by how well an individual fits into the current economic and social system. Technically, if someone is so blissfully happy they stop showing up to their job, they would actually meet the criteria for a disorder.
Just like if someone lives in a high-crime area with little security they may have crippling anxiety. DSM would say they have a generalized anxiety disorder, but I would argue they don't, they are experiencing a reasonable reaction to a broken environment.
We are far too quick to jump to "this person isn't functioning in society, therefore something must be wrong with them" instead of doing the hard work of adapting our social and economic systems to be more inclusive of different types of human experiences.
Case in point, homosexuality used to be a sociopathic personality disorder, and pre-DSM we thought it was a mental illness causing enslaved people to want to escape slavery.
> We are far too quick to jump to "this person isn't functioning in society, therefore something must be wrong with them" instead of doing the hard work of adapting our social and economic systems to be more inclusive of different types of human experiences.
Careful saying things like that, someone might accuse you of being a socialist (slight /s)
Partial checkouts are awkward at best, LFS locks are somehow still buggy and the CLI doesn't support batched updates. Checking the status of a remote branch vs your local (to prevent conflicts) is at best a naive polling.
Better rebase would be a nice to have but there's still so much left to improve for trunk based dev.
reply