3 ms·

Memory unsafety (by default without opt-in) is being treated like a feature in these newer languages.

by avgcorrection 4y ago

hsn915 4y ago
What other language takes this stance? (other than jai, which is not released)
- renox 4y ago
  Zig
renox 4y ago
That's because memory safety has a price: either a GC (which creates interoperability issues if you have two languages with GCs..) or a complexity price like in Rust.. So these languages stay memory unsafe but tries to minimise the issues caused by the lack of safety.
- avgcorrection 4y ago
  Making an effort in language design also has a price.
- still_grokking 4y ago
  That's not true. Memory safety could be free. Actually it would even outperform any memory unsafe language, when done right™. The key would be hardware supported automatic memory management. This tech exists since many years but nobody uses it (likely because our "good old friend": patents, which is a death sentence to any good idea). https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon12AndThen.pdf https://researcher.watson.ibm.com/researcher/files/us-bacon/... https://people.eecs.berkeley.edu/~kubitron/papers/holistic_runtime/maas-asbd16-hwgc.pdf https://people.eecs.berkeley.edu/~kubitron/papers/holistic_r... https://adept.eecs.berkeley.edu/wp-content/uploads/2018/06/A-Hardware-Accellerator-for-tracing-garbage-Collection-Maas-6-2018.pdf https://adept.eecs.berkeley.edu/wp-content/uploads/2018/06/A...
gingerBill 4y ago
I've replied to you before on this in other comments. (here is one such example: https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951) Odin has numerous memory safety features enabled by default. Having manual memory management does not entail no "memory safety". You could easily have a language with GC or ARC and still have all of the unsafe features of C. Objective-C is a brilliant example of this. Many memory safety can be achieved with many constructs such as: * Bounds checking for array-like types * Having no pointer arithmetic * Having distinct typing (virtually no implicit type conversions) * Having no array-to-pointer demotion like in C (combination of the above to problems) * Having actually decent array types: fixed-length arrays, slices, dynamic arrays, #soa arrays, etc * Have length-bound strings rather NUL-terminated strings * `Maybe(^T)` type to allow for non-nil pointers to be explicitly checked * Built-in discriminated `union`s (of which `Maybe` is just one of those) * Virtual Memory Protects * And many more! Most of the unsafe features in C/C++ come from most of the above features, especially pointer-semantics and the lack of a decent array type. What Odin does not offer is ownership semantics and lifetime semantics, which is an entire discuss to itself which I won't talk in this comment.
- avgcorrection 4y ago
  If Odin is memory-safe by default then my bad, I was wrong.

Memory unsafety (by default without opt-in) is being treated like a feature in these newer languages.

hsn915 4y ago

What other language takes this stance? (other than jai, which is not released)

renox 4y ago
Zig

renox 4y ago

That's because memory safety has a price: either a GC (which creates interoperability issues if you have two languages with GCs..) or a complexity price like in Rust.. So these languages stay memory unsafe but tries to minimise the issues caused by the lack of safety.

avgcorrection 4y ago
Making an effort in language design also has a price.
still_grokking 4y ago
That's not true. Memory safety could be free. Actually it would even outperform any memory unsafe language, when done right™. The key would be hardware supported automatic memory management. This tech exists since many years but nobody uses it (likely because our "good old friend": patents, which is a death sentence to any good idea). https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon12AndThen.pdf https://researcher.watson.ibm.com/researcher/files/us-bacon/... https://people.eecs.berkeley.edu/~kubitron/papers/holistic_runtime/maas-asbd16-hwgc.pdf https://people.eecs.berkeley.edu/~kubitron/papers/holistic_r... https://adept.eecs.berkeley.edu/wp-content/uploads/2018/06/A-Hardware-Accellerator-for-tracing-garbage-Collection-Maas-6-2018.pdf https://adept.eecs.berkeley.edu/wp-content/uploads/2018/06/A...

gingerBill 4y ago

I've replied to you before on this in other comments. (here is one such example: https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951) Odin has numerous memory safety features enabled by default. Having manual memory management does not entail no "memory safety". You could easily have a language with GC or ARC and still have all of the unsafe features of C. Objective-C is a brilliant example of this. Many memory safety can be achieved with many constructs such as: * Bounds checking for array-like types * Having no pointer arithmetic * Having distinct typing (virtually no implicit type conversions) * Having no array-to-pointer demotion like in C (combination of the above to problems) * Having actually decent array types: fixed-length arrays, slices, dynamic arrays, #soa arrays, etc * Have length-bound strings rather NUL-terminated strings * `Maybe(^T)` type to allow for non-nil pointers to be explicitly checked * Built-in discriminated `union`s (of which `Maybe` is just one of those) * Virtual Memory Protects * And many more! Most of the unsafe features in C/C++ come from most of the above features, especially pointer-semantics and the lack of a decent array type. What Odin does not offer is ownership semantics and lifetime semantics, which is an entire discuss to itself which I won't talk in this comment.

avgcorrection 4y ago
If Odin is memory-safe by default then my bad, I was wrong.