A headwind makes it harder to advance in the direction you're going. I think you might have meant to say "there is a strong tailwind towards memory safety".
Also in aviation, but with caveats; you want to take off and land with a headwind, because the headwind gives a greater airspeed which means greater lift.
This is true for takeoffs but not for landings. You want to land with a headwind because this means that for the same airspeed you have a lower groundspeed, i.e. when you actually touch down you're going slower on the runway than if you touched down at the same airspeed but with a tailwind.
No. Your calculated landing speed doesn't change depending on the winds, so you'll always be touching down at roughly the same airspeed for the same aircraft type, weight, and flap setting. Touching down with a headwind just means you don't need to use the brakes as hard.
It's beneficial on takeoff because headwind already factors into your airspeed before you even start rolling, which gives you more lift for the same groundspeed yes, enabling you to rotate sooner than you otherwise would.
The recommendation is qualified for typical apps that do not have extreme performance or scale requirements. They use Java for many, many things.
C++ is still indicated for systems that are optimizing for performance and scalability characteristics, since it intrinsically requires a lot of "unsafe" constructs.
> C++ is still indicated for systems that are optimizing for performance
The only evidence I've seen for this is that people with a vested interest in my believing this keep saying it is true. That's the exact same evidence I have for Trump having triumphed in Iran. Do better if you want me to believe you.
> since it intrinsically requires a lot of "unsafe" constructs.
This is an excellent reason to choose Rust. The whole point of Rust's technology is to enable you to encapsulate the tricky difficult part of the problem so that people don't blow their foot off working on the mundane parts of the software. And the truth is there are always mundane parts of the software.
I'm feeling generous so I'll add more here: Vec<T> illustrates how this works. This is a growable array type, C++ has std::vector<T> for much the same concept. But inside Vec<T> this encapsulation is used heavily so that there's a RawVec<T>, which doesn't care about knowing how many things are in the growable array, only about its capacity, then a RawVecInner which doesn't even care what things we're keeping in the array, it's just an appropriately large container for whatever it is, that RawVec<T> remembers what T is if that becomes important - and then a Cap which doesn't even contain things, it's just in charge of being able to represent the capacity correctly while having the same shape as "just" an integer but not always necessarily working like one.
Vec<T> is entirely safe to use, very pleasant, no danger. But internally it's extremely sophisticated, hence the layers of different types encapsulating different pieces of the problem to make a growable array type with excellent performance.
Tangent: your comment would have been stronger without the politics.
Btw, Rust ain't the only vector here. With an LLM at your side, you can also write your performance and safety critical parts in Lean and prove them correct.
Lean can compile to some pretty fast code. (Though it needs a bit more engineering work around eg SIMD to get really fast.)
I do think though, it is in the best interests for all compiled languages to eventually bootstrap themselves, instead of depending on either C or C++ for their implementation.
Either that, or we really need to keep improving C and C++ safety story, if they are to stay around on those language runtimes, or compiler backends.
I heard that unsafe rust is then unsafer than c++. I haven't learned rust yet, and I get that it's a tradeoff because the rest of the system can still be relied on. But how true is that first statement?
It's not helpful to think of it as "unsafer" but I think the way I'd explain this goes as follows:
Rust has some stricter and more complicated rules even than a language like C++. Just as in C++ you absolutely must obey these rules at all times. However, in Safe Rust the tooling will ensure that following those rules is never your problem. You don't even need to know what the rules are, just like you don't need to know why a plane works let alone how to fly it to get on a jetliner and fly across the country for $$$.
In unsafe Rust, it is your job as programmer to understand and obey these rules because the "unsafe super powers" you can use only in these blocks cannot be checked by the tooling, it can help sometimes but you can't rely on it. Writing ten lines of correct unsafe Rust is thus probably significantly harder than writing ten lines of C++. But the Rust programmer knows when they need to be at their sharpest, they need proper review by somebody paying attention, they need to slow down and think it through, versus the rest of the safe Rust where it's less scary, in C++ every line you write might be a fatal problem.
Basically, walking a tight rope is harder than everyday walking, but you know when you're on a tight rope, you've trained for it, everybody is focused on your safety - so actually maybe that's not a problem, lot of people get injured just walking about every day.
Rust allows much more aggressive optimization of the reference types than C++. If you have a &T, the compiler can assume that it will not change over the entire lifetime of the reference, and reorder things even past things that a C++ compiler would never reorder across. This can easily bite you badly if you have the mental model of C/C++ pointers and step into unsafe land. There is a separate warning for:
unsafe {
mem::transmute::<&T, &mut T>(t) //takes a &T, returns a &mut T
}
in the compiler because this is something that a lot of people think might be safe (I'm running single-threaded, everything would be so much simpler if I just mutated this bit while no-one's looking), but is in fact pretty much always UB of the nasal demons type. But there are more ways to step on this problem than the most apparent way, and the compiler is not able to protect you from all of them.
To be clear, just declaring a block to be unsafe does not immediately do anything in Rust, it just allows a set of primitives that are not normally available, so it is possible to use unsafe judiciously without immediately stepping into a million landmines. You just have to be careful and ideally read the docs and the nomicon page for the operations you do, especially if they are very long.
It's harder to write unsafe code in Rust. That doesn't make it "unsafer". What I mean is this, if you want to write unsafe code in Rust the C++ way, your entire program has to have unsafe markers everywhere. It's just as unsafe as C++ at that point.
But if you want to write unsafe code in Rust the Rust way, you run into a requirement that didn't exist in C or C++: The abstraction around the unsafe code must be safe for you to drop the unsafe marker. This created a unique category of abstractions that no other language has, so if you are working on unsafe code in Rust you are often a pioneer doing something never done before.
> This is an excellent reason to choose Rust. The whole point of Rust's technology is to enable you to encapsulate the tricky difficult part of the problem so that people don't blow their foot off working on the mundane parts of the software. And the truth is there are always mundane parts of the software.
The problem is that it actually sucks for dealing with the encapsulated parts. The reason everyone loves Rust is because they can just import a package where somebody else did the hard part for them and not worry their pretty little brains about a thing, getting high performance with minimal concern. That is a valid advantage, and that does make more mundane usage of the language safer. But it does not make the unsafe parts safer. There is every reason for having unsafe-oriented languages with ergonomics that actually make working with unsafe code more reliable too. The annoying thing about Rust is that 90% of its users are religious dogmatists who insist that Rust is the only valid language rather than accepting different languages can have different advantages, and moreover that 90% is basically the 90% who are benefitting from Rust while not being the ones who have to write unsafe code themselves.
The autovectorizer works quite well in llvm with all the aliasing guarantees rust gives it. Especially now fastmath hit so wide types aren't necessary anymore. I don't need unsafe or crates that use unsafe to beat the performance of c++. If you are doing something very specific with niche intrinsics llvm can't use, then maybe I'd have to use unsafe. But I don't run into that. Rust is faster for the same reasons it avoids UB. Also the Kool aid comes in multiple flavors!
This is so untrue I still don't know how anyone can even claim this. When I run tests in Rust, the biggest portion of the time is spent compiling the test (lets say 3-4 seconds), then the tests conclude practically instantly, in less than half a second.
Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start and the test execution is extremely slow too.
Even if you do manage to match the performance after warmup, you still have the issue that keeping the class files in RAM plus the JIT compilation state will cost more memory than simply running AOT compiled code. You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Once you get into the micro optimizations like the lack of mutable aliasing in Rust, there is significantly more potential for auto vectorization.
What you mean by "real world systems" is probably defined in such a narrow way that all the weaknesses of Java programs don't count anymore.
> This is so untrue I still don't know how anyone can even claim this.
Because it's referring to long running processes, AKA the kind of things where hot paths can be JITted into faster native code than is possible from static compilation because the JIT has information about the real-world usage patterns.
> Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start
That strongly implies you're using some sort of framework that's doing a _lot_ of initialization. That's not JVM startup time, don't be intellectually dishonest here.
> You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Again, the main use case for Java is long running server processes. No one cares if the binary is 1, 10, or 100MB or if it consumes 2, 3, or 4x the memory as long as the throughput is there. And Java has a long track record of delivering very good performance in those contexts, coupled with an extremely rich and mature library/tooling ecosystem.
I think this used to be true more than it is now. Memory has been relatively expensive in cloud environments for a while (often 2x the price of an ec2 node for an equivalent with 2x RAM) and DRAM shortages aren't helping.
For the most part yeah but does depend on scale. For Java there are lower cost migration pathways like native compilation anyway if that does become your concern
> The biggest problem was that the first ~couple of hours were spent getting all of the PCs connected, updated, and working properly-enough.
Every lan party would have that one guy who turned up with nothing pre-installed or patched, and would finally, after a couple of hours, get their copy of Unreal Tournament working and join the game just as everyone had grown tired of it and were ready to hop into another game instead. This would rinse and repeat for almost every game.
I had some sympathy, but not too much, because we were generally fairly organised about sending out game lists in advance.
There was something delightfully chaotic about trying to get a good game of anything actually played, because even without technical problems, you'd get a situation where at most a third of the players were keen, another third were mildly amused and another third were basically just barely tolerating it because they wanted to play something next and didn't want to ruin the vibe, but clearly would much rather be playing almost anything else. Of course, as games rotated, so did these groups.
There was also that corner of people who had no intention of playing anything and were just there to utilise the ability to privately swap their terrabyte sized "anime" collections across fast ethernet ( or via physically handing over hard-drives ). I tended to leave them well alone.
I actually didn't get much gaming done on those days since I didn't usually have much of a gaming machine for myself at that time. My focus was instead mostly directed at getting everyone else up and running.
Every now and then I'd take a turn at someone else's computer. It worked fine.
Except that one day when I did bring a reasonably-capable machine with a Voodoo3 2000 card. On that day, I was the one having computer issues and it seemed like getting updated drivers from 3dfx was the correct move to make.
But nVidia had just announced their purchase of 3dfx. And 3dfx's own website was dead like it had never really existed; as if someone had walked into the closet where it was hosted and yanked the plug out of the wall. It was at that time that it became clear that the early web tendency to scatter mirrors of important things all over the place had become a lost concept.
I spent hours trying to find drivers. It felt like all of my well-honed Google-fu was a spectacular failure. But I did eventually succeed at finding recent drivers, and they did fix my problem, and games were then played.
The specificity of the occasion pins down the date very precisely: Saturday, December 16, 2000.
Firstly when you've instructed it ( possibly through skills ) not to do something. It'll keep reminding you that it didn't do that. So I might say, "Check out and review this PR, do not make comments on it", and then it'll be keen to point out it hasn't posted comments to the PR.
But more often it happens when it tries one approach, gets itself messed up, and then has to back out that approach, clean up its mess and do something else.
It'll often then spend more time explaining the wrong approach than the right one, which can be frustrating, especially if all its working is buried in the detailed transcripts.
This is a skill I learned as a coffee shop supervisor and youth camp counselor, and now I really practice it on Slack with half-interested product owners.
- Always describe tasks in the positive. (Never describe tasks in the negative.)
- DO guide the user safely. DO NOT use DO NOT because the reader already DID.
- Give guided choices based on your expertise.
- Asking two-or-more questions results in one-or-less answers.
- Conditionals are also questions, so you only get one.
I only use AI agents and tools for work, I don't create them, so I'm not a subject matter expert. Where I've anthropomorphized the tools highlights my own misunderstandings.
It interactively shows you each change that would be added and lets you decide whether it should be staged or not. Down to the hunk level, so you can partially stage a file if you so choose.
I don't feel like this was a piece by someone who has used LLMs too much.
I'm fairly confident this is just LLM writing the majority, possibly tweaked by a human.
Opening line is a form of, "It's not X, it's Y": ".. isn't thinking. It's I/O".
Then the start of the second paragraph is that weird breathless kind of writing:
> Reading five files to answer a question about one method. Generating a test file that follows the exact same pattern as the twenty test files next to it.
More "It's not X, it's Y": The seat license isn't what hurts, it's the tokens.
The softly pressed insistence that AI is worth it, really: "The tooling pays for itself but only if..."
Yes I'm more than okay. AI has enabled a scale of personal ambition I could only previously have dreamed of.
I've never been the kind of coder who could easily sit down and get their thoughts out from mind to written lines. I've seen that happen in a few gifted individuals, and AI might be frustrating them, because for them, coding was never the bottleneck, but for me, I would always get stuck in analysis paralysis, and just writing the first line of a project was a daunting prospect.
With AI I'm able to construct an entire ecosystem of programs I've always wanted.
The code isn't perfect, but I understand enough to fix architectural mistakes and to guide the AI to a good enough solution.
It's true I've always been better at breaking things than making things, but for someone who was "never really a coder" I've had a good career doing it all the same!
>> I've never been the kind of coder
>Looks like you were never really a coder, to be honest.
I do not understand the bitterness here at all. AI is just a tool you can use for better or worse.
I learnt basic programming at an old age of 10 and 6502 assembler 2 years later from (paper)books.
There was no Internet and I dreamed of one day owning a magical software program called Macro Assembler so I could use labels and advanced loops in assembler programs instead of tediously translating examples from the book or magazines using a pencil and paper into assembly without such features.
The AI today is like that Macro Assembler for me back then. You, a human, are simply moved one layer of abstraction higher.
Did I enjoy writing that assembler back then when the goal was to complete a calculation in the time it took the crt tube's electron gun to draw one line on the screen? Sure. Would I want to write accounting software in it? Hell no.
There have been very crappy coders and great coders before and after AI. Just like almost no one writes assembler anymore, almost no one will write normal code in the age of AI. But knowledge of it, how it should be written is still going to be important.
Your value as a human is in the architecture of the software and choices that influence it's entire functioning. In maintainability, scalability and resilience present in your design from day 1 not added a year later.
You know how much slop and crappy work I saw before AI? A lot.
I have started to wonder to what degree programming discussion online is astroturfed. The financial incentive to flood programming discussion (any discussion related to work) with pro-AI messaging, and the simultaneous ease with which AI makes it to do so, makes it hard not to ponder what amount of seemingly organic pro-AI sentiment is not.
I'm sure there is some that is indeed genuine. It could even be most. But I'd be surprised if it is all.
The comment reads like flesh-generated language to me, but I might be fooled. The breadths of pro-AI sentiment is possibly astroturphed, but there's also an argument for an enthusiastic minority of people to write a lot more comments.
As the person above said, AI has significantly increased my ability to execute on ideas. I always liked computers, always liked building things, but was never that great at coding, and was never that good at going super deep into one topic. Instead, I have broad knowledge of a lot of things like product design, requirements engineering, devops, security.
I work with a fully agentic flow, but I would argue very seriously; My job has not gotten easier, I am doing at least as much hard thinking as before. From assisted RE over design (TDD focused Spec), implementation by agents, review by agents with partial human oversight, I have a speedup of maybe 50-100%.
More importantly, I can do things I couldn't do before. And when it comes to performance and defect-density, it is comparable to very senior people I couldn't touch before. I do agree that the code doesn't look like a human would write it - too abstracted, sometimes convoluted, often way too dense. But it isn't worse code, and if you accept that no one has to read that code ever again, then it is good. Agents are able to grok it just fine.
What was the point to you? What I took away from the article is that AI adds a bunch of complexity that is making it harder, not easier to understand.
And I'm saying that is true, but it's also enabling a kind of complexity and ambition in outcomes that might be a worthwhile trade-off.
In the same way we accept that cars are no longer something that a mechanic can understand and repair without a laptop, because we trade off the repairability and understanding for better mileage or safer handling.
Either I misunderstood the article, or people are misunderstanding my point, because I'm genuinely confused by being called a bot.
It's useful to you. I'd say take the win and let the haters quibble. I'm good enough at coding that I can use it as part of my day job, but I hate coding for the sake of coding. For me coding is a tool for solving problems, and now AI can sometimes help me solve problems I might not have had the motivation to persue. My scale is usually "a small application that helps me do X", not "I develop photoshop singlehandedly".
absolubtely. Worth noting though that a large number of people here literally do develop photoshop, or similar apps of similar complexity.
The fact they aren't doing it singlehanded makes it way harder, not easier. This is a central counterintuitive finding of most thinking about software development
( Edit: I should probably inform the layperson: It was Visual Studio 2022 )
reply