3 ms·

Also, check out Google's in-development Carbon Language, designed to address the same issues with a Kotlin-like approach. It's an entirely new language that cou

• jjnoakes 2y ago
  Does Carbon have any undefined behavior? Some of the wording in their goals document suggests that they do/will, but it isn't clear to me.
  • gumby 2y ago
    Unless you solve the halting problem, every language has undefined behavior.
    • tialaramex 2y ago
      Nope. A language which has semantic requirements and isn't willing to reject programs for which it has been unable to determine whether they meet the requirements, will have these cases by Rice's Theorem. This is why C++ is a complete disaster. C++ specifically does not allow the compiler to reject such programs. You can defuse this like (safe) Rust by just writing conservative checking. You will reject some programs you would like to have successfully compiled, but that's actually OK, programmers who hate it are inspired to improve the checking, that's what Rust's "Non-Lexical Lifetimes" - mentioned by Sean, are about. Even more radically, you can be a Special Purpose language and just only allow a relatively small subset of possible programs, all of which you know are correct, that's why WUFFS gets to emit indexing with no runtime bounds miss checks - it did all the bounds checks at compile time, all source where that wouldn't be possible isn't legal WUFFS code.
      • mgaunard 2y ago
        That is incorrect. A C++ compiler is perfectly allowed to reject any program that contains undefined behaviour. It's just not required to do so.
        • leni536 2y ago
          It's allowed to reject programs that will evaluate an undefined operation on every possible execution. This is pretty much impossible, so no compiler even attempts this.
          • mgaunard 2y ago
            It can replace any path with undefined behaviour to one that does std::abort.
            • pjmlp 2y ago
              It can, but in practice no one does it.
              • majoe 2y ago
                When you think about it, that's what -fsanitize=undefined is doing. It detects undefined behaviour at runtime and aborts the program.
                • leni536 2y ago
                  It detects some, but not all UBs. AFAIK it can't detect UB due to hnsequenced access to the same variable.
                  • mgaunard 2y ago
                    There are different sanitizers that detect different types of UB. Asan, Msan, Tsan and UBSan all detects different ones.
                • deleted 2y ago
      • gumby 2y ago
        I suppose you can make that assertion by moving the goalposts. But Rice's theorem specifically addresses such behavior: all turing machines are inherently undecidable for all but trivial cases. You can well argue that Rust may be better than C++ in some dimension, just as others can argue that those qualities have an unreasonable or intractable cost (note that about 20% of all crates resort to `unsafe`). But your blanket assertion is not even supported by the reference you made. Also the user is free to tell a C++ compiler to reject programs that use many sorts of undefined behavior, though indeed nobody would claim that any current compiler can identify all such cases. But Rice's theorem says that no Rust compiler could either.
      • mike_hock 2y ago
        Yes, but it seems that we can't satisfy all reasonable real-world use cases this way, or else Rust wouldn't have the "unsafe" escape hatch that's actually used by real code.
    • School-Cotton 2y ago
      That’s not true. The halting problem / Rice’s theorem only mean that the behavior can’t be statically determined by the compiler, not that it’s undefined.
    • Yoric 2y ago
      C++ has a specific definition of UB. Most languages don't suffer from it, regardless of halting problem.
    • Asooka 2y ago
      No? The CPU doesn't have undefined behaviour, thus any code running on it doesn't have undefined behaviour either. There are certain operations whose result is not defined in certain states, I think on Intel some SSE operations had undefined results, but even then the same order of operations will lead to the same result. C/C++ compilers generally let you turn off almost all possible undefined behaviour assumptions. I think the only one you can't turn off is the assumption that a pointer to an object is properly aligned, which is understandable - if every pointer had to be checked for alignment before every access, it would ruin performance. In general I would be much happier if I could assert to the compiler that my data fits certain parameters and it would optimise based on these explicit assertions rather than on implicit assumptions (undefined behaviour). Those assertions could be turned off in the final build if we determine they actually impact performance, but I expect I'd be able to keep them on all the time.
      • fluoridation 2y ago
        CPUs do have undefined behavior.
      • gumby 2y ago
        > The CPU doesn't have undefined behaviour, thus any code running on it doesn't have undefined behaviour either. Have you read Rice’s theorem? Every nontrivial program on a Turing machine (which has only defined behavior) is undecidable.
        • Slyfox33 2y ago
          That's not what c++ UB is.
        • jaccobbo 2y ago
          Real computers are not turing machines, they are FSMs.
  • summerlight 2y ago
    My understanding is that if you want a high level of semantic compatibility with C++, a certain degree of UB is quite hard to avoid. But at least unlike C++, they prefer not to leave 100s of different possibilities on the table.
• kccqzy 2y ago
  I'm not convinced Carbon will become popular at all. I was a Google employee when it was first announced and even internally the project was shrouded in secrecy because there was a ton of resistance. Google employees who cared about safety wanted to write Rust.
  • maxloh 2y ago
    Isn't a memory-safe language subset one of their long term goals?