9 ms·

This can't possibly be guaranteed to work just by disabling the checker, can it? If Rust optimizes based on borrow-checker assumptions (which I understand it ca

• tialaramex 9mo ago
  If you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. Evidently millions of people want broken garbage, Herb Sutter even wrote a piece celebrating how many more C++ programmers and projects there were last year, churning out yet more broken garbage, it's a metaphor for 2025 I guess.
  • ozgrakkurt 9mo ago
    I have been using kde for years now without a single problem. Calling cpp garbage sounds wrong.
    • LtWorf 9mo ago
      People who can't do something, sometimes assume nobody else possibly could.
      • zzrrt 9mo ago
        I’m sure some people could tiptoe through minefields daily for years, until they fail. Nobody is perfect at real or metaphorical minefields, and hubris is probably the only reason to scoff at people suggesting alternatives.
        • LtWorf 9mo ago
          Just FYI rust projects have CVEs as well.
          • zzrrt 9mo ago
            Of course. My sense is there are a lot fewer in of out-of-bounds accesses and use after frees. Maybe a world-class programmer can go several decades without writing a memory error in C/C++, but they will probably eventually falter, meanwhile the other 99.9% of programmers fail more often. Why would you decline a compiler’s help eliminating certain types of bugs almost entirely?
      • 3836293648 9mo ago
        People hate C because it's hard, people hate C++ because it truly is rubbish. Rubbish that deserved to be tried but that we've now learned was a mistake and should move on from.
    • doodlesdev 9mo ago
      KDE is a great desktop environment , but it's also notorious for being a buggy and unpolished DE [1]. It's good your experience wasn't like that, but it's certainly not how the software is generally perceived. [1]: Of course, different versions have different levels of stability. Also, some of these bugs and problems wouldn't be prevented by using an alternative language such as Rust.
    • danudey 9mo ago
      Well FWIW, the original poster's anti-C++ statements aside, removing the borrow checker does nothing except allow you to write thread-unsafe (or race condition-unsafe) code. Therefore, the only change this really makes is allowing you to write slightly more ergonomic code that could well break somewhere at some point in time unexpectedly.
      • tialaramex 9mo ago
        Nope. Anything which wouldn't pass the borrowck is actually nonsense. This fantasy that magically it will just lose thread safety or have race conditions is just that, a fantasy. The optimiser knows that Rust's mutable references have no aliases, so it needn't safeguard mutation, but without borrow checking this optimisation is incorrect and arbitrary undefined behaviour results.
  • amelius 9mo ago
    People don't want garbage. But in any case, they don't want straightjackets like the borrow checker. Hence, they use GC'd languages like Go whenever they can.
    • eru 9mo ago
      Straightjackets can be very useful. Haskell (and OCaml etc) give you both straightjackets and a garbage collector. Straightjackets and GC are very compatible. Compared to C, which has neither straightjackets nor a GC (at least not by default).
      • deleted 9mo ago
        [deleted]
      • reactordev 9mo ago
        >Straitjackets can be very useful. Only if you’re insane.
        • qsera 9mo ago
          Damn! This is the funniest HN comment that I have ever come across...
        • josephg 9mo ago
          How dare you. C is a fine language. Just don't accidentally step on any of these landmines and we'll all get along great.
          • reactordev 9mo ago
            Not to mention your sidearm is a Sig P365. We like to call them footguns.
        • imtringued 9mo ago
          The meaning of straightjacket here is inherently subjective and not to be meant literally.
  • jjgreen 9mo ago
    It is possible to like something without hating people who like something else, can't people just live and let live?
    • tialaramex 9mo ago
      Did I write that I hated somebody? I don't think I wrote anything of the sort. I can't say my thoughts about Bjarne for example rise to hatred, nobody should have humoured him in the 1980s, but we're not talking about what happened when rich idiots humoured The Donald or something as serious as that - nobody died, we just got a lot of software written in a crap programming language, I've had worse Thursdays. And although of course things could have been better they could also have been worse. C++ drinks too much OO kool aid, but hey it introduced lots of people to generic programming which is good.
      • jjgreen 9mo ago
        Correct me if I'm wrong, but I don't think you think that C++ programmers actually want to write "broken garbage", so when you say "millions of people want broken garbage" the implication is that a) they do write broken garbage, b) they're so stupid don't even know that is what they are doing. I can't really read else than in the same vein as an apartheid-era white South-African statement starting "all blacks ...", i.e., an insult to a large class of people simply for their membership in that class. Maybe that's not your intent, but that's how it reads to me, sorry.
        • dminik 9mo ago
          Considering how many people will defend C++ compilers bending over backwards to exploit some accidental undefined behaviour with "but it's fast though" then yeah, that's not an inaccurate assessment.
        • tialaramex 9mo ago
          I can't help how you feel about it, but what I see is people who supposedly "don't want" something to happen and yet take little or no concrete action to prevent it. When it comes to their memory safety problem WG21 talks about how they want to address the problem but won't take appropriate steps. Years of conference talks about safety, and C++ 26 is going to... encourage tool vendors to diagnose some common mistakes. Safe C++ was rejected, and indeed Herb had WG21 write a new "standing rule" which imagines into existence principles for the language that in effect forbid any such change. Think Republican Senators offering thoughts and prayers after a school shooting, rather than Apartheid era white South Africans.
  • ada0000 9mo ago
    herb sutter and the c++ community as a whole have put a lot of energy into improving the language and reducing UB; this has been a primary focus of C++26. they are not encouraging people to “churn out more broken garbage”, they are encouraging people to write better code in the language they have spent years developing libraries and expertise in.
    • lordgroff 9mo ago
      And for which there's often no serious alternative to in many domains anyway.
      • ada0000 9mo ago
        even when there are alternatives, sometimes it makes sense to use a library like Qt in its native language with its native documentation rather than a binding - if you can do so safely
      • nemetroid 9mo ago
        Yes, many or even most domains where C++ sees a large market share are domains with no other serious alternative. But this is an indictment of C++ and not praise. What it tells us is that when there are other viable options, C++ is rarely chosen. The number of such domains has gone down over time, and will probably continue to do so.
        • pron 9mo ago
          The number of domains where low-level languages are required, and that includes C, C++, Rust, and Zig, has gone down over time and continues to do so. All of these languages are rarely chosen when there are viable alternatives (and I say "rarely" taking into account total number of lines of code, not necessarily number of projects). Nevertheless, there are still some very important domains where such languages are needed, and Rust's adoption rate is low enough to suggest serious problems with it, too. When language X offers significant advantages over language Y, its adoption compared to Y is usually quite fast (which is why most languages get close to their peak adoption relatively quickly, i.e. within about a decade). If we ignore external factors like experience and ecosystem size, Rust is a better language than C++, but not better enough to justify faster adoption, which is exactly what we're seeing. It's certainly gained some sort of foothold, but as it's already quite old, it's doubtful it will ever be as popular as C++ is now, let alone in its heydey. To get there, Rust's market share will need to grow by about a factor of 10 compared to what it is now, and while that's possible, if it does that it will have been the first language to ever do so at such an advanced age.
  • lordgroff 9mo ago
    The attitude expressed here and that tends to surface in any Rust discussion is the reason I completely lost interest in the language.
    • tempodox 9mo ago
      You’re expressing the same attitude here, just in reverse. Some users not thinking highly of C++ doesn’t make Rust a worse or less interesting language.
    • maxbond 9mo ago
      Rust isn't a one true language, no one necessarily needs to learn it, and I'm sure your preffered language is excellent. C and C++ are critical languages with legitimate advantages and use cases. Don't learn Rust of you aren't interested. But Rust, its community, and language flame wars are separate concerns. When I talk shop with other Rust people, we talk about our projects, not about hating C++.
    • Maxatar 9mo ago
      So don't use it. Rust is not intended to be used by everyone. If you are happy using your current set of tools and find yourself productive with them then by all means be happy with it.
  • pron 9mo ago
    For all its faults, and it has many (though Rust shares most of them), few programming languages have yielded more value than C++. Maybe only C and Java. Calling C++ software "garbage" is a bonkers exaggeration and a wildly distorted view of the state of software.
  • Spivak 9mo ago
    How are we still having the same trade off discussion being argued so black and white when reality has shown that both options are preferred by different groups. Rust says that all incorrect programs (in terms of memory safety) are invalid but the trade is that some correct programs will also be marked as invalid because the compiler can't prove them correct. C++ says that all correct programs are valid but the trade is that some incorrect programs are also valid. You see the same trade being made with various type systems and people still debate about it but ultimately accept that they're both valid and not garbage.
    • Maxatar 9mo ago
      >C++ says that all correct programs are valid but the trade is that some incorrect programs are also valid. C++ does not say this, in fact no statically typed programming language says this, they all reject programs that could in principle be correct but get rejected because of some property of the type system. You are trying to present a false dichotomy that simply does not exist and ignoring the many nuances and trade-offs that exist among these (and other) languages.
      • tialaramex 9mo ago
        Nope. C++ really does deliberately require that compilers will in some cases emit a program which does... something even though what you wrote isn't a C++ program. Yes, that's very stupid, but they did it with eyes open, it's not a mistake. In the C++ ISO document the words you're looking are roughly (exact phrasing varies from one clause to another) Ill-formed No Diagnostic Required (abbreviated as IFNDR). What this means is that these programs are Ill-formed (not C++ programs) but they compile anyway (No diagnostic is required - a diagnostic would be an error or warning). Why do this? Well because of Rice's Theorem. They want a lot of tricky semantic requirements for their language but Rice showed (back in like 1950) that all the non-trivial semantic requirements are Undecidable. So it's impossible for the compiler to correctly diagnose these for all cases. Now, you could (and Rust does) choose to say if we're not sure we'll reject the program. But C++ chose the exact opposite path.
        • 9mo ago
• MangoToupe 9mo ago
  > If Rust optimizes based on borrow-checker assumptions This is a binary assumption that you can understand to evaluate to "true" in the absence of a borrow checker. If it is "false" it halts the compiler
• CGamesPlay 9mo ago
  Yes. An analog would be uninitialized memory. The compiler is free to make optimizations that assume that uninitialized memory holds every value and no value simultaneously (because it is undefined behavior to ever read it). In the following example, z is dereferenced one time and assigned to both x and y, but if z and x are aliased, then this is an invalid optimization. fn increment_by(x: &mut i32, y: &mut i32, z: &i32) { *x = *z; *y = *z; } https://rust.godbolt.org/z/Mc6fvTzPG https://rust.godbolt.org/z/Mc6fvTzPG
  • OptionOfT 9mo ago
    > Yes. An analog would be uninitialized memory. The compiler is free to make optimizations that assume that uninitialized memory holds every value and no value simultaneously (because it is undefined behavior to ever read it). Even casting a MaybeUninit<i32>::uninit() to i32 is UB, even though every bit pattern in that memory space is a valid i32. What's interesting is your code example is solved in Rust. By preventing a reference and a mutable reference all of the sudden the code becomes easier to reason about. No need for special attributes: https://www.lysator.liu.se/c/restrict.html#comparison-with-noalias https://www.lysator.liu.se/c/restrict.html#comparison-with-n...
• masklinn 9mo ago
  > This can't possibly be guaranteed to work just by disabling the checker, can it? It works in the sense that the borrow checker stops bothering you and the compiler will compile your code. It will even work fine as long as you don't write code which invokes UB (which does include code which would not pass the borrow checker, as the borrow checker necessarily rejects valid programs in order to forbid all invalid programs).
  • dataflow 9mo ago
    > It will even work fine as long as you don't write code which invokes UB (which does include code which would not pass the borrow checker, as the borrow checker necessarily rejects valid programs in order to forbid all invalid programs). To be clear, by "this" I meant "[allowing] code that would normally violate Rust's borrowing rules to compile and run successfully," which both of us seem to believe to be UB.
    • masklinn 9mo ago
      Not quite, there is code which fails borrow checking but is safe and sound. That is part of why a number of people have been waiting for Polonius and / or the tree borrows model, most classic are relatively trivial cases of "check then update" which fail to borrow check but are obviously non-problematic e.g. pub fn get_or_insert ( map: &'_ mut HashMap<u32, String>, ) -> &'_ String { if let Some(v) = map.get(&22) { return v; } map.insert(22, String::from("hi")); &map[&22] } Though ultimately even if either or both efforts bear fruits they will still reject programs which are well formed: that is the halting problem, a compiler can either reject all invalid programs or accept all valid programs, but it can not do both, and the former is generally considered more valuable, so in order to reject all invalid programs compilers will necessarily reject some valid programs.
      • hyghjiyhu 9mo ago
        Imo if you run into the halting problem it's because you are trying to do too much. In particular I think what you actually want is to check soundness based on the "shape" of the code rather than the reason about which variables can have which values and what that means for soundness. flag=false; if flag { use_after_free(); } can be rejected with a clear conscience.
• Sytten 9mo ago
  Correct, I was reading a very interesting blog post [1] on how the rust compiler will change the LLVM annotaions like sending noalias for mutable pointer. This changes a lot the generated machine code. Disabling the borrow checker won't enable those LLVM flags. [1] https://lukefleed.xyz/posts/who-owns-the-memory-pt1/ https://lukefleed.xyz/posts/who-owns-the-memory-pt1/
• djdjfljfgddfg 9mo ago
  I guess this is like putting an unsafe { } around all your code...
  • aw1621107 9mo ago
    Not really. Unsafe blocks don't change the semantics of Rust code or disable Rust's normal checks, so if you have something that doesn't compile due to a borrow checker error adding an unsafe block around that code will do precisely nothing to get around that error.
  • Narishma 9mo ago
    No, unsafe doesn't disable the borrow checker.
    • djdjfljfgddfg 9mo ago
      lol, that'll teach me :D