5 ms·

Do you have any specific languages in mind?

by turminal 4y ago

matkoniecz 4y ago
Author of linked article mentions Rust
- turminal 4y ago
  Rust is a good replacement for most use cases, but I think specifically in case where you're looking for a more predictable and less risky implicit behavior, the replacement should be more stable and predictable than Rust is at the moment.
  - matkoniecz 4y ago
    What kind of language is C replacement without UB and better concurrency and more stable/predictable than Rust?
    - mlindner 4y ago
      Question, but where do you get the idea that Rust is not stable or predictable? I understand you were asking for something _more_ stable/predictable than Rust, but Rust is already very stable and very predictable (in fact I can't think of any ways that Rust is "unpredictable").
- JonChesterfield 4y ago
  Fun thing there is rust feeds into the same optimisation pipeline as C or C++, so there's a definite risk of it inheriting some of their semantics via errors in the compiler implementation.
  - masklinn 4y ago
    Compiler bugs are always a potential issue for fuckup. Hell, rust has had codegen issues because it extensively leveraged features which are almost non-existent in C, and thus were little exercised and poorly tested.
  - oconnor663 4y ago
    There have been several cases where Rust's use of "restrict" pointers exposed bugs in LLVM, and the Rust compiler had to disable some optimizations as a workaround. But I haven't heard of anything like that happening with signed overflow. (Probably any bugs with basic integer behavior would get noticed quickly?) Another thing to watch out for here (especially if anyone's trying to transpile Rust to C) might be C's strict aliasing rules accidentally getting applied to Rust raw pointers.
  - PoignardAzur 4y ago
    The promise of Rust is that you never run into undefined behavior if you only use safe code. There are some caveats (using dependencies with badly written unsafe code, the noalias bugs others mentioned) but in the general case, if you're writing code without 'unsafe' blocks, you're not going to trigger UB. You're certainly not going to run into LLVM optimizing your bound-check out of existence because it occurs after an overflowing operation.
  - deleted 4y ago
    [deleted]
baq 4y ago
Basically anything else.
- turminal 4y ago
  C has a specification and weird stuff doesn't happen as long as you follow it. Doing so is very hard at times, but if a project cares about unpredictable optimizations, then it probably also cares about other kinds of unpredictable behavior. Which unfortunately eliminates a lot of languages that make no guarantees about their semantics.

Do you have any specific languages in mind?

matkoniecz 4y ago

Author of linked article mentions Rust

turminal 4y ago
Rust is a good replacement for most use cases, but I think specifically in case where you're looking for a more predictable and less risky implicit behavior, the replacement should be more stable and predictable than Rust is at the moment.
- matkoniecz 4y ago
  What kind of language is C replacement without UB and better concurrency and more stable/predictable than Rust?
  - mlindner 4y ago
    Question, but where do you get the idea that Rust is not stable or predictable? I understand you were asking for something _more_ stable/predictable than Rust, but Rust is already very stable and very predictable (in fact I can't think of any ways that Rust is "unpredictable").
JonChesterfield 4y ago
Fun thing there is rust feeds into the same optimisation pipeline as C or C++, so there's a definite risk of it inheriting some of their semantics via errors in the compiler implementation.
- masklinn 4y ago
  Compiler bugs are always a potential issue for fuckup. Hell, rust has had codegen issues because it extensively leveraged features which are almost non-existent in C, and thus were little exercised and poorly tested.
- oconnor663 4y ago
  There have been several cases where Rust's use of "restrict" pointers exposed bugs in LLVM, and the Rust compiler had to disable some optimizations as a workaround. But I haven't heard of anything like that happening with signed overflow. (Probably any bugs with basic integer behavior would get noticed quickly?) Another thing to watch out for here (especially if anyone's trying to transpile Rust to C) might be C's strict aliasing rules accidentally getting applied to Rust raw pointers.
- PoignardAzur 4y ago
  The promise of Rust is that you never run into undefined behavior if you only use safe code. There are some caveats (using dependencies with badly written unsafe code, the noalias bugs others mentioned) but in the general case, if you're writing code without 'unsafe' blocks, you're not going to trigger UB. You're certainly not going to run into LLVM optimizing your bound-check out of existence because it occurs after an overflowing operation.
- deleted 4y ago
  [deleted]

baq 4y ago

Basically anything else.

turminal 4y ago
C has a specification and weird stuff doesn't happen as long as you follow it. Doing so is very hard at times, but if a project cares about unpredictable optimizations, then it probably also cares about other kinds of unpredictable behavior. Which unfortunately eliminates a lot of languages that make no guarantees about their semantics.