> the author never actually tries agentic coding in Rust vs Python
> Can't say I've tried Rust
...
Well, I've actually tried both. The result is similar to what happens when humans code: for small programs the simplicity and terseness of Python helps, but in large programs that accumulate many more invariants that have to be upheld, strictness of Rust becomes an advantage, because it can catch subtler issues with ownership, lifetimes, thread safety.
Although ownership and lifetimes seem like a Rust-specific chore, they're used in APIs to represent all kinds of temporary and single-use objects, so ownership errors are often symptoms of logic bugs that would exist in C++ and even Python, like an event handler callback assuming the event will fire only once when it can fire n times.
You don't see as much improvement with C++, because C++ requires the programmer to get these things correctly, instead of correcting the programmer.
Although the post focuses on RGB, the same quantization issue exists for any type of signal being mapped between discrete and continuous representations.
The issue isn't in having a representation for 0 photons, but about maximizing information stored in a byte. Ideally you shouldn't be underutilizing the byte value 0, nor add bias to data that should have been assigned to the 0th bucket, regardless of what it represents (you could have a color space that goes from bright to super bright, and still want to ensure that every byte represents equal chunk of your brightness range).
Yep, the exact same problem arises in digital audio, mapping between integer sample formats and the floating point representation that is generally used internally.
The job has changed from a craft to operating an unreliable machine.
Instead of satisfaction of solving challenging problems with your own skill and creativity, you babysit a text extruder and slog through mistakes in its generated output.
Arguably this may make software cheaper to make and accessible to non-programmers, but for people who liked their job it's like being demoted from a restaurant chef to a microwave button pusher.
> The job has changed from a craft to operating an unreliable machine.
Many tech/software people were completely unsympathetic if not downright arrogant when their products displaced people in other professions who felt the same way.
The lesson here is that ultimately, change comes for everyone.
This also perfectly describes the career change from software engineer to engineering manager.
Instead of solving things yourself, you need to learn how to describe them in a way others can solve them. Otherwise you will just be fighting the instinct to just do it yourself.
At least as a software manager you get the satisfaction of helping another human being develop in their own career. I doubt making Claude Code less prone to certain kinds of fuckups is quite as rewarding.
Meh. Since when "typing" implies "solving challenging problems with your own skill and creativity". The "solving" and the "creativity" happen in your head while "typing" is a manual labor. I can contemplate multiple problems at the same time but I can only type one thing at a time. Writing code is like 10% of my programming job. I take an LLM to do the typing for me any day. I still solve challenging problems. Because my secret skill isn't typing, you see. Yeah, call it "dismissive".
You must truly have no love for your craft if you see "manually" writing code as _just_ typing. That's like calling writing a novel just dragging ink over paper.
Yeah, sure. We both know it’s not black and white. Like all of you write rocket ship software. You’re all funny. Heads too far up your asses. What fucking craft are you talking about “implement this html and css exactly like described in the ticket”, or “write this deployment pipeline for that client for the 50th time”, or “implement authentication for the 15th time this year”. Really fucking novel stuff. Craft my ass.
Not going to bother responding to most of that as it does not warrant a response, but I would point out that the word craft does not imply novelty or uniqueness.
In many cases the really key idea that transforms the overall system design comes from working closely on the specific implementation details. Maybe you don't redesign the system this time, but you saw how you might do it, and you get ideas about how to do it the next time. The craft involves a back-and-forth between different levels of abstraction, and cutting that link does feel like we're sacrificing something.
Yeah, you do it every day for money, right? And someone is paying you for that? Dude, people designed ships, aircrafts, the shuttle with a ruler and a pencil, today people use CAD and CFD because it’s cheaper and better but people still know how to use the ruler and pencil! At least those who want to know, know. But not everything has to be designed with the ruler and the pencil. Be the guy who presses buttons, and knows how to use the ruler and the pencil!
It’s different, because in our field we’re often learning or doing new things, as opposed to merely rehashing the exact same thing we’ve done before.
I find it very difficult to learn a new thing by reading it, vs by doing it.
And indeed, most mathematicians, who do get paid to do math, work a lot with pencil and paper. If math is secondary to your job, you likely will not, but if it’s your primary job, you likely spend a lot of time working ideas out in the more primitive fashion.
> I find it very difficult to learn a new thing by reading it, vs by doing it.
The whole point of the discussion about LLMs in our field is exactly what you say. Yes, we do often find ourselves doing new things. They are exciting the first and the second time we do them. Later they become a chore.
When you’re doing something that requires a lot of typing for the 17th time… why! Like, how many times are you going to write that golang http server scaffold. Or, how many times are you going to create that new terraform project with those same modules. I hear people say “oh yeah, write a generator”. To which my answer is: do you have a budget for it, or do I need to invest my own time.
It’s possible to guard the model so that it acts according to your expectations. Just invest the time in that tooling. It’s as exciting as any other problem. You learn the domain by writing software guardrails, your effort results in a software analysis of the business domain problem. It’s a much more valuable and rewarding work than writing some code.
I don't think there's a consensus about that, as demonstrated by divided opinions on EU DMA and Apple vs Epic.
The anti-regulation arguments aren't framed as "market competition is bad", but rather "the market will sort itself out without intervention" and "let companies do whatever they want to avoid killing innovation".
Unlikely, since library interfaces need to use a trait to accept all of the open/closed inclusive/exclusive syntax variations. If the only accept one specific named range type, they're clunky already.
Rust's sync functions can block and await async functions.
Which is another problem with the article: it doesn't clearly define what counts as having the "color". The problematic dead-end situation exists in JS, but languages with cross-thread communication can work around it.
People can't memorize as much information, and can't manually reproduce the works as quickly. There's a natural limit to how much damage a person can do without help of machines. That's why it's legal to fart where industrial-scale sewage outlets are not allowed.
Second, laws are for people. Laws don't have to treat machines the same. People have needs for things like freedom of artistic expression, participation in a shared culture, and machines don't. Copyright is a compromise that tries to balance needs of people, and stops making sense when the same compromises are done for machines that don't have these needs.
> Can't say I've tried Rust
...
Well, I've actually tried both. The result is similar to what happens when humans code: for small programs the simplicity and terseness of Python helps, but in large programs that accumulate many more invariants that have to be upheld, strictness of Rust becomes an advantage, because it can catch subtler issues with ownership, lifetimes, thread safety.
Although ownership and lifetimes seem like a Rust-specific chore, they're used in APIs to represent all kinds of temporary and single-use objects, so ownership errors are often symptoms of logic bugs that would exist in C++ and even Python, like an event handler callback assuming the event will fire only once when it can fire n times.
You don't see as much improvement with C++, because C++ requires the programmer to get these things correctly, instead of correcting the programmer.
reply