But the motor is not the only thing that needs to be cooled. It’s mainly the battery, which has a narrow operating range. The power electronics that convert AC to DC also need to be cooled.
So you’re halving the cooling needs of the motor, which is nice but small compared to the other two. And even then, total cooling doesn’t impact range that much compared to warming the battery in cold climates.
There was this video which showed film directors doing something similar. They film their scene with “filler” music previously used in some other film. Then they hand the scene to the music director and ask a score for it, which forces the director to make something very similar to the filler music. It then makes all film music sound similar.
This was only possible due to the “productivity boost” of digital editing pipelines, which allowed directors to edit immediately after filming.
Per token costs will fall, but the harnesses will get more token hungry. Instead of just centering the div it’ll spin up a battery of agents to architect, critique, advise, code, review, refactor and so on.
I wish I could disable most of these. I already hate all the "oh you're actually right, let me fix that" nonsense. Then it proceeds to burn 50k tokens on the git history instead of copying logic A from a different part of the codebase to logic B, where I want that exact logic without having to write the boilerplate myself...
Makes me think of how my Claude.md files specifies to use the built in framework code-generators (rails). Those generators are deterministically right every time.
I wonder how often the Agent actually follows the guidance. I do see them follow it when I look. But it doesn't seem so every time.
This is tricky since it can and will ignore your md directions. When possible I try to lean on tool call hooks or skills that invoke deterministic scripts. As much as you can remove the "choice" the better though still there's a lot of randomness in how reliably it invokes skills ime.
Hooks are incredibly underused by most people and are the easiest way to establish a first line of defense against bad behavior. Things like blocking tool calls that will read .env file or execute "create or replace table".
A lot of the time if you're copying code from one place to another what you actually want to do is abstract it so you can reuse it in both places.
The LLM can easily do this type of stuff, just tell it and it'll happily do it. This is exactly what I mean when I tell people they need to work closer with the AI, tell it how to do things. Don't just tell it what to do and get frustrated when it does it differently than you would.
A good way to achieve this without writing huge prompts is tell it to plan the change first. Just give it some vague low-effort directions. It'll usually get most things right, you tell it what you want different and once you're happy you tell it to go ahead.
Nah the codebase is legacy fucked and I cant be bothered to try and optimize business flows without the fear of other stuff breaking.
Claude 100% of the time even thinks we use laravel despite the project being some old lumen codebase, so most of laravels features are not available. It also gets the PHP version we are using wrong 100% of the time.
Are you some kind of entitled corporate dev that barely has any influence on the codebase? If I fuck up a whole business goes down as I am the only dev there currently. We cant afford that happening.
Also why would I mess with anything claude.md related? I just use the CLI tool. LLM enthusiasts always claim how smart these things are so they should figure it out on their own, you know?
I have full control of my codebase. I'm not afraid to make changes to it because I know what I'm doing.
You would edit Claude.md to say things like what tech the project is using, because that's the entire point of claude.md. It's literally the solution to the exact problem you're complaining about. Any information you want it to know, you put in there and then it knows it. And you can tell Claude to make or update the file for you.
I'm not one of the people telling you how smart LLMs are. I'm telling you how to use it efficiently, by not expecting it to know everything but rather provide the information that it needs in order to be a more useful tool.
This is a spicy take, unless the business is willing to face some down time, and I am hired to do exactly what you said, I’d never touch any line of code unless I absolutely have to. Different environments don’t help as much.
We tend to obsess over software quality when it’s the least important thing for a business. It’s just a means to an end.
This is what its about, we have multiple ecom shops running 24/7 and cant simply afford downtime or a change of business flow that maybe doesnt affect shop A and B but definitely affects shop C and D...
- Takes weeks or months to get simple features out the door, and when they're out they're buggy as hell and the bugs never get fixed. Sound familiar?
> I’d never touch any line of code unless I absolutely have to
And this is how legacy code is made. Years of everyone "never touching anything they don't have to" leads to a giant steaming pile of shit.
> unless the business is willing to face some down time
How does a simple refactor cause downtime? I do this kind of stuff all the time and pretty much never cause any downtime. In the very rare cases that prod downtime does occur it's generally not because of some simple code refactor, and we have it back up in no time by just rolling it back. Unless it's not related to the code at all, in which case it also wasn't a refactor that caused it.
That feels like a market failure though. For a tool to be a useful extension of the user, it should work in the way a user expects it, without a huge amount of having to realign and repackage your normal process.
Maybe that's something we can hope for in a next-generation of LLM product. Right now, the race seems to be all about performance and capability, but maybe when we get to a plateau of performance, vendors can start differentiating by building tools with clearer voices and expectations-- focused system prompts and training, maybe. If you know DeepSeek will follow your requests fairly literally, while Qwen will start adding best-effort tweaks, you can decide which one is the right choice for a given task.
I asked Claude to read two logs and assemble them in a single table for easy reading the other day. It takes me like 30 seconds to pull and toggle between the logs normally, but I figured it would be nice to have a skill to let the machine crunch it all onto a single page. After 5 minutes, it spat up a ball of Markdown with half the content truncated and summarized it in a way I didn't ask for and had no interest in.
If I had asked a human to do it, there's no way it would come to that conclusion because doing the wrong thing is literally more effort. Maybe the model did those things because "typical" requests want summarization so it's the implicit default, but IT SHOULDN'T BE MY RESPONSIBILITY TO GUESS THIS.
You're just expecting too much. If a task takes you 30 seconds to do you're almost certainly better off doing it yourself than getting an LLM to do it. If it's a recurring task it might make sense to create a skill for it, and this is exactly the use case for skills. Give precise instructions so it does the task correctly, and save them for later so you can do it again easily.
I don't really get how you guys can be so demanding - this technology is magic. It's doing things that 5 years ago we could only dream of. It still blows my mind every time I paste a screenshot of some vague issue along with a quick and dirty prompt and it just gets it and gives me the right answer immediately.
In the hands of a competent user these things are absolutely incredible, I can develop solutions faster, with higher quality and less effort. So honestly man all you guys complaining that they aren't good enough? I can't help but think you guys must really not be very competent. Complaining about problems while the solution is staring you in the face.
> I don't really get how you guys can be so demanding - this technology is magic
That could be the problem. I suspect a lot of developers have spent years developing workflows and understandings based on the idea the machine is precise, repeatable, and does exactly as it's told. "Magic" is a very poor match for that strategy.
> Complaining about problems while the solution is staring you in the face.
Not quite sure what the "solution" is here. Am I supposed to try to restyle the prompt to be "quick and dirty" to give Claude more room to stretch and hopefully hit my desired goal? Or am I supposed to iterate repeatedly on the skill to add a harness of "don't truncate that, don't add a summary, etc" until it behaves how I want?
I'm not saying you're wrong. I think it's almost more like the difference between programming languages. If you come into writing FORTRAN with a TCL/Tk mindset, you're going to have a hard time getting what you want, but the industry understood that and made environments for both. I suspect right now, since the big market is outside the hardcore programmer market, they're going to focus on the "it does magic with vague prompts" version before the "it's reliable and precise with specific prompts" one.
There are a lot of instances where you don't want to create an abstraction that will tie two disparate areas of the code together even if they happen to be using a similar pattern you want to copy. For example, when you expect their implementations to diverge in the future.
I have experienced enterprise codebases that have been DRY'd to the point they become ossified.
That's why I said "a lot of the time". Not always. And it's not really a problem to de-DRY things, literally just copy/paste and make the change you want.
The bigger problem in my eyes is when the requirements start to diverge people just add an if branch and soon you have a function/component that does 7 different things depending on how it's used and it's a big buggy mess.
It's also possible in many of these cases to identify sub-patterns you could abstract, to create a set of tools you can compose in different ways in order to satisfy the different use cases. Instead of one function/component you make multiple, and use them together.
All this stuff is just basic programming but I've mostly given up trying to preach about it. Most people don't care, and even if they did care they just don't have the talent to write really good code. It's rare to find a dev who does really solid work. In my experience you either do it because that's who you are, or nothing I say will make any difference.
A fair question is why this fork of coreutils is required when the original Rust rewrite (https://github.com/uutils/coreutils/) supports Windows, in addition to Linux, macOS and wasm.
Steam does control the vast share of desktop gaming. But has no influence on console (Xbox, playstation, switch) or mobile (android, ios). They are a monopoly.
But they don’t abuse their monopoly so they haven’t broken any laws.
Your partitioning between those two things is good, but I still don't think that either label applies to them:
> Steam does control the vast share of desktop gaming.
Between the Epic Games Store, GOG, Humble Bundle, Xbox, Origin, Itch, and a few others, I don't believe their control is anywhere close to the fraction needed for Steam to be a "monopoly", either legally or in casual speak.
> Steam does control
...and, what's more, they don't "control" anything - what prevents you from either using multiple clients (on the player side) or selling on multiple storefronts (on the developer side)?
A monopoly has to monopolize some limited resource or market - you can't really have a monopoly if there's no limiting or exclusivity. That's like saying that Fortnite is "monopolizing" the battle royale genre because it's the most popular - it is the most popular, but there's no exclusivity because you can always play another battle royale in addition to Fortnite.
Monopolies need pie charts (limited resources that are taken by a single actor), but Steam is a bar in a bar chart.
Google controls 90% of the search market and the browser market. There is nothing preventing anyone from searching on Bing. Yet, the correct terminology is control of the market.
Google has a monopoly on search. Have they abused that monopoly? That’s a legal question that’s currently in court.
Steams share is somewhere in the 70s and it is far stickier than Google. A gamer can’t abandon their steam library easily. Have they abused this monopoly position? IMO no, but my knowledge is limited.
Did you look at his artwork of a judge hitting a protestor with a gavel while the protestor was bleeding on the ground and think “huh, I wonder what this means” (https://www.bbc.co.uk/news/articles/cm2z30p033ro).
By those standards a man wrapped in the flag walking off the edge is the height of subtlety. I guarantee you this - none of the people it should be offending will realise he’s talking about them.
Is it possible you’ve misunderstood what Rust promises?
> It isn't possible to create a programing language that doesn't allow bugs to happen
Yes, that’s true. No one doubts this. Except you seem to think that Rust promises no bugs at all? I don’t know where you got this impression from, but it is incorrect.
Rust promises that certain kinds of bugs like use-after-free are much, much less likely. It eliminates some kinds of bugs, not all bugs altogether. It’s possible that you’ve read the claim on kinds of bugs, and misinterpreted it as all bugs.
On the other hand, there are too many less-experienced Rust fans who do claim that "Rust" promises this and that any project that does not use Rust is doomed and that any of the existing decades-old software projects should be rewritten in Rust to decrease the chances that they may have bugs.
What is described in TFA is not surprising at all, because it is exactly what has been predicted about this and other similar projects.
Anyone who desires to rewrite in Rust any old project, should certainly do it. It will be at least a good learning experience and whenever an ancient project is rewritten from scratch, the current knowledge should enable the creation of something better than the original.
Nonetheless, the rewriters should never claim that what they have just produced has currently less bugs than the original, because neither they nor Rust can guarantee this, but only a long experience with using the rewritten application.
Such rewritten software packages should remain for years as optional alternatives to the originals. Any aggressive push to substitute the originals immediately is just stupid (and yes, I have seen people trying to promote this).
Moreover, someone who proposes the substitution of something as basic as coreutils, must first present to the world the results of a huge set of correctness tests and performance benchmarks comparing the old package with the new package, before the substitution idea is even put forward.
Where are these rust fans? Are they in the room with us right now?
You’ve constructed a strawman with no basis in reality.
You know what actual Rust fans sound like? They sound like Matthias Endler, who wrote the article we’re discussing. Matthias hosts a popular podcast Rust in Production where talks with people about sharp edges and difficulties they experienced using Rust.
A true Rust advocate like him writes articles titled “Bugs Rust Won’t Catch”.
> Such rewritten software packages should remain for years as optional alternatives to the originals.
> must first present to the world the results of a huge set of correctness tests and performance benchmarks
Yeah, you can see those in https://github.com/uutils/coreutils. This project has also worked with GNU coreutils maintainers to add more tests over time. Check out the graph where the total number of tests increases over time.
> before the substitution idea is even put forward
I partly agree. But notice that these CVEs come from a thorough security audit paid for by Canonical. Canonical is paying for it because they have a plan to substitute in the immediate future.
Without a plan to substitute it’s hard to advocate for funding. Without funding it’s hard to find and fix these issues. With these issues unfixed it’s hard to plan to substitute.
Those Rust fans exist on almost all Internet forums that I have seen, including on HN.
I do not care about what they say, so I have not made a list with links to what they have posted. But even only on HN, I certainly have seen much more than one hundred of such postings, more likely at least several hundreds, even on threads that did not have any close relationship with Rust, so there was no reason to discuss Rust.
Since the shameless promotion with false claims of Java by Sun, during the last years of the previous century, there has not been any other programming language affected by such a hype campaign.
I think that this is sad. Rust has introduced a few valid innovations and it is a decent programming language. Despite this, whenever someone starts mentioning Rust, my first reaction is to distrust whatever is said, until proven otherwise, because I have seen far too many ridiculous claims about Rust.
Could you find one such person on this thread? Someone making ridiculous claims about what Rust offers.
I’ll tell you what I think you’ve seen - there are hundreds of threads where you’ve seen people claim they’ve seen this everywhere. That gives you the impression that it is universal.
The comment you linked says something specific about a specific kind of bug being eliminated - memory safety bugs. And they’re not making a claim, they’re repeating the evidence gathered from the Android codebase. So that’s a fact, memory safety bugs truly did not appear in the Rust parts of Android.
The comment you linked is not claiming Rust code is bug-free. That’s a strawman I’ve seen many, many times. Haters will claim that this happens all the time, but all I see are examples of the haters claiming this. You had to go back 5 months and still couldn’t find anything similar to the strawman.
The only language I've ever seen users make that claim for is Haskell. Rust users have never made the claim, but I've seen it a lot from advocates who appear to find "hello world" a complex hard to write program.
I understand the (narrow) hard guarantees that rust gives. But there there are people in the wider community who think that the guarantees are much, much broader. This is a pretty widespread misconception that should get be rectified.
It’s possible to actually learn something from this, whereas the one fable created is just slop with pretty colours.
reply