SnapDragon
4hr ago
And yeah, I find it somewhat sad that software engineering seems to eventually be going the way of blacksmithing
A better analogy might be that programming will be going the way of assembly programming. I think people who knew how to code raw assembly also lamented when high-level languages (or even C) became standard, and it went from hard to impossible to churn out your own assembly better than the compilers (except in some very specialized cases). At least in the short term, AI might just be lifting the "meta" of programming one level higher, where you can't write normal code better/faster than the LLMs, but you're still the one guiding the design.
SnapDragon
1d ago
Great writeup! In terms of LLM capability I think I agree that I didn't see too many "wow" moments in 2025. My biggest one was when ChatGPT aced the ICPC Finals, and Gemini got 11/12 on it (both results would have been more than enough for 1st place). I helped write the contest, and can confirm that it was very hard; based on the previous year's results, we absolutely did NOT expect AI to do well on it. But, arguably, that was more a measure of the fact that we just didn't realize how far thinking models had come at solving toy math/CS problems. Still, you don't need to be "wowed" all the time; as long as model capability doesn't stall out, slow steady progress is going to continue to change the world forever.
One thing I don't quite agree on is context windows. IMO windows are already almost too large; there's a limit to how much an LLM can "learn" from one pass through the context. I find the standard "needle-in-a-haystack" tests almost useless, because all they're testing is that an LLM can notice something out of place in those million tokens, which is not what you're asking for when you give it your codebase then ask it to contribute. What we need are better ways of digesting context, either by summarizing it in token form (like the text files that you're currently maintaining yourself), or, even better, some form of embedding-based short-term memory. I thought we'd make some sort of algorithmic improvements here in 2025, but I was wrong. Maybe in 2026.
(Maybe this is even a good thing, because society's already suffering so many shocks due to the current level of AI. An LLM's raw knowledge base combined with the ability to learn online might just be too much too fast.)
So, you have some good responses and I want to repeat that this is all just my opinion and personal experience. Thanks for the reply.
I won't address your criticism of our design because you don't know the details (and I'm not going into them). But we're not stupid people. Not collectively, at least... :) This attitude of "I've thought for three whole minutes and I can't see why anybody would ever want this, so the people telling me they want this are wrong" is kind of emblematic of Rust's design vs C++'s.
Yes and this is fantastic design because aliasing.
I agree it's nice that Rust solves the aliasing problem. They didn't have to solve it by confusing mutability and exclusivity, though! It's like if a plumber comes and fixes my toilet, but breaks some windows on the way out. The correct response to "hey, why did you break the windows" isn't "look, the toilet's fixed!"
I am not very knowledgable about this subject, but if const MyStruct contains a pointer in it, you can simply mutate the pointed data right?
You can if you can access it, yeah, but it'd be weird for the C++ object to give a user access to raw internal pointers. Note that in most cases you're also limited on what methods (including getters/setters) you can call on a "const MyStruct" - whether a function is read-only or not can be explicitly declared in its signature. Now, you don't have to use const at all in a library. Or you could use it but then have the same "internal mutability" as Rust - but why would you do that? The point of the keyword's existence is to allow programmers to positively assert "this is what a read-only version of this object looks like". Which is powerful and important and should be easier than it is in Rust.
If your complaint is that "const" doesn't force the C++ programmer to be safe, you're right about that. C++ gives options, not restrictions, and for bad programmers it is indeed full of footguns. My praise of "const" is due to what it can be in the hands of good programmers - and I would have loved it if Rust introduced the keyword but applied its stringent safety guarantees to it.
Usually when you newtype something, you are doing so because you don't want the inside type to be accessible as it is anymore, but only through a certain limited interface.
But the heap example I give is the exact opposite of this. I want access to the inside type (the number) - I never want to think about the heap's operator except at initialization - but instead I'm being forced to wrap it everywhere. Now, it's not entirely fair to compare Rust's library with C++'s STL. Like you said, "it can be annoying to find gaps like this in the language that takes years to close" - Rust is young, and the STL is the result of decades of finetuning/nitpicking work from thousands of people. I agree that, in the future, something like Rust's bad heap implementation might be a non-problem.
Ok, I guess we're getting into the weeds now. Anybody who's not a programmer, feel free to bow out. :)
Borrow checker is honestly one of the hot topics about Rust that always confuses me, because I almost never have problems with it apart from some very small edge cases. Meanwhile people online seem to base half their Rust experience on the borrow checker. May I ask you what sort of programming did you do?
Backend infra work. Efficiency was important, so we ended up having to use pointers to bypass the Rust borrow checker in cases where it just didn't work (e.g. for caching a map lookup). Concurrency was also important, and Rust's concurrency features were kind of tacked on later in its design. (Actually, Rust relies on third-party libraries to solve a LOT of its design flaws, like tokio for async stuff.) I do admit that the Send/Sync traits are nice for catching a few common concurrency bugs. But screw Rust for intentionally not implementing them for the pointer type because they want to discourage its use.
I will fight you to death about the mut keyword. It is absolutely fantastic and it pushes you in a more functional way of programming.
I don't think you should compare "const" and "mut" if you're not a C++ developer and you've never used "const" before. "const" is "absolutely fantastic" and pushes you to a "more functional way of programming" - it lets you clearly spell out what side effects all your functions and APIs have. With Rust's version of "&mut" - which despite the lying name (and horrible syntax) actually just means "exclusive reference", something that is correlated with but not the same as "mutable" - a shared non-mut object might change, it might not, you'll just have to check the implementation for details.
But this can be achieved easily with like a 10 line wrapper type around Mutexes in your codebase?
Here's a C++ object: MyStruct. Here's the read-only version of that C++ object: const MyStruct. You'll forgive me for not being impressed that this common safety pattern can be done in "like 10 lines" in Rust by implementing your own Mutex wrapper.
Anyway I used to write C code and switched to Rust without brushing much with C++ so it has been a gigantic improvement in all ways. But honestly I fail to see why anyone would prefer C++ at this point for new projects (except for gamedev where shipping something buggy and fun trumps correctness by a lot).
Yeah, don't get me wrong, C++ has plenty of issues, and I wish there was a better alternative that kept its strengths too. Rust, unfortunately, decided not to. If you're going directly from C to Rust, you might even think it's normal that you need third-party libraries to, say, put floats into a heap (heh).
EDIT: Actually, while I'm on the topic, and since you're a Rust pro, let me ask... does putting wrappers around everything feel natural to Rust developers? The type inference makes it so you don't have to see all the nested wrapping. Maybe that's just a paradigm I don't grok. Because I find Rust's heap to be spectacularly and uniquely badly designed. Rather than treating the comparator as a separate parameter from the thing being compared - like in every other language in existence - Rust instead has you create a wrapper object to override the object's comparisons. Which means you need to do type conversions for every get and put operation. And if you pull some objects out of a max-heap and you forget to convert them back, then do some comparisons on them yourself... the code (because its types are hidden) will look innocuous, but you'll get exactly the wrong result.
SnapDragon
6d ago
I worked at a startup that was having huge problems with their server responsiveness due to Go's GC. They unfortunately believed the hype that it was a fancy concurrent GC with very small stop-the-world pauses. What they didn't realize was that while the GC was running, many common memory-accessing operations slowed down 10x (due to e.g. memory fences to avoid screwing with the GC). The slow performance would snowball, and you'd end up with the server spending most of its time in an unacceptable high-latency state.
We did manage to get some good performance out of Go eventually, but it was by explicitly writing our code to bypass the GC (including managing our own memory arena). TBH I like Go in general, but I think you underestimate just how costly a GCed language, even with a modern fancy GC, can be.
SnapDragon
6d ago
Yeah, my ideal modern language would be a curated version of C++. It'd have a modern package manager, cut out a ton of the language features that are outdated or dangerous or both, and rewrite some existing features (e.g. lambda functions) to be less clunky now that backwards compatibility isn't a problem.
But making something like this wouldn't be very sexy.
SnapDragon
6d ago
Well, there's the paycheck of course! And I did like my coworkers, even if they were a lot more gung-ho about Rust than I was. But I didn't actually stick around - as of October, I've moved back to Canada (from Silicon Valley) and am giving retirement a try...
SnapDragon
6d ago
You make some good points, and I don't hate all uses of auto (I'll usually use it for iterators, too). Though making it so your code silently compiles when a library API changes isn't something I really approve of - it's not hard to see how that can go bad. Note that one of the things Rust does way, way better than C++ is package management - you don't have to update a library until you want to, and you can handle any compile errors at that time. As for your last scenario, another advantage Rust has over C++ is that it won't silently allow it to compile, since Rust has almost no implicit type conversions. I approve: Numbers changing types lossily is something that should be done explicitly.
I spent the last 2 years of my career fighting with Rust, and I detest the language. Unfortunately, I'm aware that I'm in the minority, and a lot of people buy into the hype that it's the wave of the future. In my opinion, it's a language that was a bad idea from the start.
-
Most programs are not the Linux kernel and do not need 100% safety guarantees. It's honestly fine if a game segfaults once in a while due to C++'s scaaaary "undefined behavior" (which is a crash 99.99% of the time).
-
And Rust kinda fails at the safety guarantees in practice, anyway. People who aren't experts bash their heads against the language, trying to do simple tasks that in any other language would be done in 15 minutes, and then they finally give up and do one of two things: wrap things in an unnecessary "unsafe" block, or copy a large object that didn't need copying. It turns mediocre programmers into bad programmers. (This isn't rhetoric; in our very real project, I saw how the "unsafe" blocks kept adding up, because we had to actually deliver a product instead of spending our time justifying ourselves to the borrow checker.)
-
The cost of C++ is all the crashes that we very visibly see everywhere. The cost of garbage-collected languages is sluggishness and, often, software literally just pausing for multiple seconds to free up memory. (When you're playing a game and you see a multi-second pause in the middle of gameplay, that's why.) The cost of Rust is in code that just doesn't get written, because it's 3-5x harder to get anything practical done. And unlike the first two, this is a subtle, invisible cost that is easily overlooked.
-
The designers of Rust really wanted to make a programming language with formally-verified correctness; there are other programming languages that go all the way on this, but they're all impossible to use. In fairness, Rust is merely difficult to use rather than impossible, but that's because the borrow checker is trying to do most of the proof for you. Unfortunately, the borrow checker isn't very good at it, and fails in many common actually-safe scenarios, and they didn't include any way for you to, well, help it along. (Ok, they do have lifetime specifiers, but those are insanely ugly constructs that provide no actual value to the programmer. They're only there for you to assist the borrow checker - often in ways it should be smart enough to do itself.) Now, Rust does keep improving the borrow checker, so fortunately this improves each year, but I doubt the problem will ever really go away.
-
The thing that really, really sticks in my craw is that the language is built around a horrible "mutable" keyword that is both ugly and a lie. C++ has "const", which is fantastic and they should have just copied it and been done with it. I actually think their choice not to do that is political, so they could pretend they were innovating over C++. But now, lots of objects have to have "internal mutability" to work, which means that there's no actual way to get, say, a reference to a mutex with the guarantee that you will not modify the object it points to. And you also can't have "const" member variables, so for instance, you can't initialize a temp directory as an object's member and add an in-language guarantee that it won't change until the object is destroyed.
-
One thing that Rust does really, really, amazingly really well is type inference. And it's nice in a lot of situations, but like the "auto" keyword in C++, I think people abuse it far too much. Types should be explicitly written out in code! They're a very important part of the logic! Libraries should be encouraged to be written so that types are easily readable (not 100-character-long nested monstrosities that both C++ and Rust are guilty of). And Rust uses its type inference to hide just how ugly its design actually is, so you don't have to stare at crap like
MutexGuard<Option<Arc<Map<int,Result<Option<String>,MyError>>>>>>all the time.
But oh well. I'm aware that some of this is just my biased old-man get-off-my-lawn outlook. (Also, I'm not a Rust master, so I'm sure that some of what I'm saying above is flat-out incorrect.) But I don't think I'm wrong that Rust has a lot of downsides and is not the right tool for many (or even most) purposes. Ironically, one saving grace is that it's getting popular at the same time as LLMs, which are actually pretty good at navigating its human-unfriendly intricacies. Without ChatGPT I would have been a lot less productive.
SnapDragon
11d ago
Piers Morgan's a leftist, but not a progressive partisan. Like Bill Maher, he's very critical of the excesses of the far left (anti-white racism, misandry, trans women in sports, etc.).
SnapDragon
15d ago
Well, people did lose jobs for tweets about the Kirk assassination (and we had like 5 blissful days of Kimmel being off the air), which isn't great from a free-speech perspective. But being sentenced to 2.5 years of prison goes way way WAY beyond that.
SnapDragon
16d ago
This is something that the electoral college protects against, since one state's messed up votes will just impact the outcome of that state, rather than the entire popular vote.
Er, no, the electoral college makes this problem worse. It serves to magnify the votes of certain districts over others, and it's often well-known which ones are the important ones (e.g. flipping a California district makes zero difference, flipping a Florida district is enough to change W to Gore). With the popular vote, it really requires a massive effort to shift the result by a few percentage points. With the electoral college, you just need to "fortify" the vote in a few well-chosen places.
Mind you, I still don't believe the 2016/2020/2024 elections were invalid (despite America's uniquely insane lack of voter ID). You'd still need a pretty large conspiracy to actually commit fraud at that scale, AND you'd have to overshoot, because you'll be wrong on some of the districts that you think will be "important".
Furthermore, democracy's most important feature is just to make government answerable to the will of the people. That survives even if every person on the [left/right] with 49% support will get frauded up to 51%. They're still reliant on that 49%; it doesn't make them an omnipotent dictator.
SnapDragon
26d ago
This. And their later show Silicon Valley, updated for the 2010s, also hit quite hard for somebody immersed in that reality.
SnapDragon
26d ago
How very coincidental!
SnapDragon
1mo ago
Well, that's not quite true - price discrimination really just means being able to charge different people different rates. And, despite the name, it can actually be a very good thing. The people at the front of the aircraft buying absurdly priced business/first-class tickets are helping to subsidize your flight. They're getting a little more comfort than you, but you're both getting the key thing (travel). Or free-to-play games - yes, some are predatory, but there are some absolutely amazing games you can play without spending a cent, because they're supported entirely by whales.
SnapDragon
1mo ago
She really does fit the girlboss trope (except for being somehow, inexplicably attracted to Threepwood), but it's a series full of exaggerated characters that lampoon pirate tropes, so I think it works well. Unfortunately I think if that series had been released today, I might have considered Elaine more cringy and woke. It's a good demonstration of just how oversensitive I've become, due to the complete saturation of modern media with this message. I wish I could go back to just enjoying stories without waiting for the woke shoe to drop every time a woman or minority shows up.
SnapDragon
1mo ago
Does it count as half a Godwin if we're already talking about Germany?
Ok, as long as you're not challenging the actual correct result, I can relax and accept that, sure, there's some philosophical weirdness about the whole thing. Sleeping Beauty's consciousness ends up "splitting" into both Monday and Tuesday, which is not something we normally encounter. So you could imagine some philosophical argument that her "soul" is more likely to experience the "qualia" of Monday than of Tuesday (if, say, "souls" jump into random time slices of a fixed universe, and earlier ones are more likely than later ones), so when it "picks one" to "be", it's not evenly apportioned. To an outside observer (i.e. for all practical purposes), across repeated experiments her body still experiences twice as many tails as heads, but her "soul" might not.
Is that a fair representation of what you think is "weird"?
This has some application to various anthropic arguments (and if we ever start simulating human brains or worrying about AI welfare, this is going to be a HOT topic of debate). Indeed, "souls" floating around independently and "picking someone" to "be" in a fixed universe is also a requirement for the Doomsday Argument to work. But personally I just think there's no disconnect between observers and physical bodies/brains (and everything I put in quotes above is nonsense). It's not something that can be settled with evidence, though.
SnapDragon
1mo ago
I already told you the actual proof: if somebody had "a reason that applies", you can swap Monday/Tuesday in it and it would give the opposite result, which is a contradiction unless the probabilities are the same. Whether you think that's called the "principle of indifference" or not doesn't matter. Like several other people in the thread, it just sounds like you're here to argue for your own variant of philosophy. But the measured result is 2/3 regardless of whether you think your version of probability is better than a mathematician's. "Reality is that which, when you stop believing in it, doesn’t go away."
It's true that there's an (usually) unspoken assumption in the setup, that Monday and Tuesday are both guaranteed to occur and there's no subjective difference between them. I think that's what you're calling out? So, what Wikipedia calls a "principle of indifference" occurs: if there were an argument for weighting Monday/tails higher than Tuesday/tails, then the same argument could be flipped to show the reverse too.
You could alter the experiment to violate this indifference. For instance, if there's a 1/3 chance that the experiment will be halted Monday night because of weather (so Tuesday might not happen). Or if Sleeping Beauty knew there was a 0% chance of rain on Monday and a 10% chance of rain on Tuesday, and she can see outside (so she has more subjective information about what day it is). You can still list the four states as {Monday,Tuesday} x {heads,tails}, but in the former case, they don't have equal weight (Bayesians would say there are different priors), and in the latter case, she has to apply two pieces of information (waking up, and whether it's raining outside).
SnapDragon
1mo ago
Not to mention the farcical phrase "sex assigned at birth". Wikipedia itself has fully adopted the Orwellian language - e.g. it incorrectly claims that Kitty Pryde was played by "Elliot Page", and there's a small note that Page "came out" as transgender, rather than deciding to switch genders.
The "man born with a defective body" belief may indeed be held by a "tiny minority" - but they've managed to capture many institutions and get them to adopt it wholeheartedly.
SnapDragon
1mo ago
If you want to work hard, earn money, and then use it to irrevocably damage your body and future prospects, well, I'm a libertarian and I can somewhat get behind that. If you want to euphemistically throw in that word "freedom", which is being used here to mean that I should pay taxes so you can do that for free, hell to the fucking no.
SnapDragon
1mo ago
Bleh. I don't think we're even in the same book. I find this mostly incoherent, particularly your description of my views (and how you think they've changed ... unless that was just bait to draw me back in, which, if so, I'm a sucker). So-called "thirders" don't take any philosophical position outside of "if something happens 2/3s of the time we say it has probability 2/3".
Many people genuinely think that there is something here that "updates" (or "changes" or something) their belief about a past event.
Yes, that is indeed what's happening. It has to be what's happening. It is impossible for the conditional probability distribution on X (which we're perhaps-sloppily calling Y even though it's technically just a different distribution on the same variable) to change without you having learned information. They're two ways of saying the same thing.
So your sticking point is you don't see how waking could be information. That's what the results show, but it conflicts with your non-formal description of what's going on (that since you know you're going to wake at least once, you learn nothing from it). Would you at least agree with me that you're gaining information in the lollipop example here? i.e., your position is that among the ways of eliminating Tuesday/heads from the probability space: "waking up", "not getting a lollipop", or hell, just "being told it's not Tuesday/heads", the first is meaningfully different from the other two?
Does that also mean that you'd consider the probabilistic version (where the experimenters flip a second coin privately to determine whether to "simulate" Monday or Tuesday - no amnesia drugs required) uncontroversial?
My credence that the coin originally came up (X) tails is 1/2, and because of that and my knowledge of the experimental setup, my probability estimate for what I will see if you show me the coin now (Y) is 2/3.
I have no issues with this math. My only issue is that I really, honestly cannot wrap my mind around a mindset that doesn't treat Y as the obvious thing the question's about. Anyway, thanks for the debate, and let's try to leave it on as much of a consensus as we're going to get. I expect, like Tanya, I'm doomed to be perpetually pushing this boulder up this hill, so I might as well make the best of it.
I'm with @TheAntipopulist, it kind of sounds like you're doing something wrong (model, tooling, context, prompting... dunno?). You're describing LLMs failing at a sub-junior-level coding task (calling an API), and modern LLMs are far more competent than this. Also, a task like "writing a serviceable database server" consists of a lot of code, but a lot of it is well-trodden code. They're great at churning out well-trodden code.
If your point is just "I haven't had success getting them to do simple tasks", that's fine and perfectly understandable; it's a new technology that we're all trying to figure out. Just don't generalize that to "they can't do simple tasks", in contradiction with other people's success stories (and benchmarks).
More options
Context Copy link