It’s interesting that people claimed the exact same thing when computers were being introduced to the work place int the 80s and 90s. Lots of papers showing how productivity didn’t go up at all and using a paper and pen seems to be just as efficient as using a PC.
Even in the 19th century, when electricity became widely available, there was no productivity gain for 30 years at least. This is a well understood phenomenon.
Without tools LLMs can do nothing more than emit text. You are probably assuming a harness is provided to the LLM with shell access but that is absolutely not necessary for LLM usage depending on the use case. For interesting stuff, you do want to provide some tools, but nothing with the power of a terminal if you are worried about security. A MCP server is perfect to securely provide the LLM with some controlled power exactly because it can do nothing at all other than call tools that go through the MCP server and can therefore be scrutinized, audited and ensure credentials are not visible to the LLM.
They have a UI which is pretty good! That explains why JS , they can run that in Electron and in TUI. I only use the UI now since it is do damn useful with its management of worktrees and multiple sessions, including ones running remotely via ssh devcontainers.
I would think that with agentic coding they’d be able to have a shared core and an interface native to the system, I.e. not react in the terminal and a swift or C# front end for the desktop app
They have a feature where they open a browser right in the app for Claude to use! They also use browser rendering for displaying various graphical formats. For once an Electron app that can actually justify shipping a whole browser in it.
Bob also knows how to quickly check things with a little bash scripting and tests. Can quickly switch branches to confirm regressions and consult documentation if something requires more information. His twin can also quickly scan for all the common security vulnerabilities in any code, and will do it without complaining as many times as you want him to.
I’ve come to trust Bob with code more than any human.
Yep! We run security reviews on our pull requests now and are shocked at how it stops a lot of vulnerabilities being shipped. We've had a couple of high score CVEs from the before-LLM times, and when the AI reviews the code that introduced the CVEs, it easily picks them up. We had 2 humans reviewing every PR, and both missed the issues. It's far too easy to miss security issues when you manually review them, but LLMs are exceptionally good at finding them. Unfortunately for me, I admit, I just can't get myself to push code anymore without an LLM checking my work (or writing much of it when I'm at work, I try to write code by hand in my own time to make sure I don't rust away, but at work there's no way to justify doing it the "slow" way anymore).
You just misinterpreted what NSArray is. It’s not an immutable type, it’s a read-only type. As others already mentioned that’s different things. If you have a read-only variable and exclusive access to it, then you can rely on immutability as well. This is what Rust has, for example. Many languages use this definition as well as it’s much more useful than having some sort of pure immutable type guarantee (which some languages do have with const).
Another language that uses this is Kotlin: List is a read-only type. MutableList is a subtype of List. You can get a “const” List by only keeping a reference to the value via a List binding. This can be worked around via casting and reflection, but even in Haskell you can do unsafe things that mutate a immutable value, so I don’t think that undermines the idea.
> I've been doing low-level programming professionally for 25 years
You haven't been doing any Rust though. You seem to think you can extrapolate your C++ experience to Rust. That's preposterous. The actual Rust programmers can't recognize this theoretical problem in their Rust programs.
It's not theoretical, it's one of the main reasons many large applications abandoned C++, and there's absolutely no reason for it to not exist in Rust. All low-level languages suffer from expensive evolution for fundamental reasons - the reliance on an AOT compiler and the lack of movable pointers impose serious performance tradeoffs in large programs. Optimising JITs and moving GCs were invented, in large part, to address this very real problem, familiar to many low-level programmers who have maintained large codebases for a long time. It's also why large runtimes like TCMalloc were invented to assist as much as they can.
Most actual Rust programmers haven't maintained a large Rust program for a long time. Now, don't get me wrong - there are many C++ programmers who are fine with it, but many who aren't. What I find annoying is people without much experience in Rust assuming that everyone or almost everyone should like it, even though that's never been true for any language. I'm not saying Rust is bad by any means; in fact, I think it's better than C++ in a few ways. I'm explaining why I don't like it.
Could that be because the language is fairly young? You don't see the "20-year-old legacy system" in Rust because it doesn't exist yet ;)
And if you look at other comments in this thread, many engineers have this mentality of "just use a crate, it's probably optimised already". They might not have performance problems immediately or obviously but it's more like ten thousand papercuts - a few allocations here and there, a few extra copies here and there and you've got a way slower program than it should have been.
Well, the problems don't start after 20 years but after 5 or so (depending on the size of the codebase and the rate of the application's evolution), and the reason there aren't many large and oldish Rust codebases isn't because the language is too young for that (work on it began twenty years ago, and it's been stable for over a decade); that's middle-aged for a programming language. When C++ was of a similar age, there were thousands of >1MLOC programs written in it. One reason is obviously because when C++ was of the same age, there weren't as many suitable high-level alternatives, and people just don't pick a low-level language for most large applications anymore. But most Rust fans at least on social media, have not actually had much experience with it or with low-level programming in general; I'm guessing most haven't worked on Rust projects with more than 10 full-time people on them (this isn't normal in the industry, BTW, as a lot of software lives in large programs). And again, there are people who can certainly live with these issues, but they are real, and many certainly find them troubling.
I’m not really down to watch a 90 minute video on the dramas of astrophysics, so I’m not sure what it says, but interestingly Sabine Hossenfelder took an extremely minor swipe at him not too long ago. Guess the dude is at least legit-enough for that? Haha
Even in the 19th century, when electricity became widely available, there was no productivity gain for 30 years at least. This is a well understood phenomenon.
Google for “the Solow Paradox”.
reply