4 ms·

I'm not sure why any "citation" is needed here. C is widely accepted as being deeply unsafe language, and C++ has inherited those traits, and is still working o

I'm not sure why any "citation" is needed here. C is widely accepted as being deeply unsafe language, and C++ has inherited those traits, and is still working on plugging the weaknesses some 35 years later. Of course you can do things like bounds checking manually in C, and run with all sorts of warnings enabled, and you can use static code analyzers that uncover entie classes of bugs, but the whole point is to never get that far in the first place. I worked with Borland's Pascal dialect for 10+ years, and it offered a great deal of protections while still allowing you to use unsafe constructs when you needed to get close to the metal (e.g. pointer arithmetic and even embedded assembly code). But "safe by default" solves a lot of problems.

jstimpfle 6y ago
Pascal's low-level semantics are comparable to C's. That's why I dispute that it doesn't have the same traps. I agree that if you program C by emulating higher-level object systems, it becomes unmanageable and a lot of bugs around object lifetimes appear, and they're very hard to fix. I personally don't have a great interest in such object systems, but fail to see how C++ should be any worse than Pascal in terms of perceived safety resulting from the higher level of abstraction.
blackrock 6y ago
The problem that I see with Nim, is that it transpiles down to C. So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C? Whereas a language like Zig and Rust, compiles its code down to LLVM.
- pjmlp 6y ago
  That is an implementation detail, nothing prevents a future release of Nim compiler to directly generate machine code.
  - blackrock 6y ago
    Fascinating. When will they do it? I would prefer it generate direct machine code instead.
    - nimmer 6y ago
      > I would prefer it generate direct machine code instead. Why? C has been the best choice for Nim so far. Compiling with Nim+GCC is much faster than Rust, it generates applications with comparable performance, and it supports way more architectures.
- nimmer 6y ago
  > Nim can inherit these unsafe behaviors of C? Not at all. You could apply the same reasoning for assembly: just because you can write insecure assembly it does not mean that all assembly generated by compiler is using vulnerable coding patterns.

jstimpfle 6y ago

Pascal's low-level semantics are comparable to C's. That's why I dispute that it doesn't have the same traps. I agree that if you program C by emulating higher-level object systems, it becomes unmanageable and a lot of bugs around object lifetimes appear, and they're very hard to fix. I personally don't have a great interest in such object systems, but fail to see how C++ should be any worse than Pascal in terms of perceived safety resulting from the higher level of abstraction.

blackrock 6y ago

The problem that I see with Nim, is that it transpiles down to C. So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C? Whereas a language like Zig and Rust, compiles its code down to LLVM.

pjmlp 6y ago
That is an implementation detail, nothing prevents a future release of Nim compiler to directly generate machine code.
- blackrock 6y ago
  Fascinating. When will they do it? I would prefer it generate direct machine code instead.
  - nimmer 6y ago
    > I would prefer it generate direct machine code instead. Why? C has been the best choice for Nim so far. Compiling with Nim+GCC is much faster than Rust, it generates applications with comparable performance, and it supports way more architectures.
nimmer 6y ago
> Nim can inherit these unsafe behaviors of C? Not at all. You could apply the same reasoning for assembly: just because you can write insecure assembly it does not mean that all assembly generated by compiler is using vulnerable coding patterns.