3 ms·

Which ones are more to your taste? For me it is mostly Zig which seems closer to what I want to see in a language. Crystal also looks promising but I prefer lan

by jeltz 7y ago

Which ones are more to your taste? For me it is mostly Zig which seems closer to what I want to see in a language. Crystal also looks promising but I prefer languages without GC. Rust is a good language but it is a bit too complex and restrictive at times.

pron 7y ago
Yep, Zig is the one I like, and IMO it's a language that shows an interesting yet very simple model for what systems programming can be. But I'll admit that it's easier to look good before you're put to the test in the field, so I'll wait and see what becomes of it.
- devit 7y ago
  As far as I can tell Zig is equivalent to a subset of C++ and thus completely lacks all the guarantees that Rust provides and several of the features that C++ has; so there is no point to use it instead of those languages.
  - pron 7y ago
    If you prefer languages with more features, then simple languages aren't for you. But me? If you told me you'd give me language X but with far fewer features, my eyes would light up, and I'd only ask, are you sure you can't get rid of any more? As Saint-Exupery said, "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Zig has all you need to write clear, efficient, generic, systems code and nothing more, but also nothing less. It is also intended to help you write safe code, but it goes about it differently from Rust.
    - devit 7y ago
      As far as I can tell Zig only has C-like malloc/free-based allocation and thus is vulnerable to use-after-free, and so does NOT help you write safe code. It also doesn't seem capable of safe concurrency.
      - pron 7y ago
        You assume that the only way a language can help you write safe code is by making sound guarantees; this is wrong. A language can also help you write safe code by making it easy to selectively add runtime checks (that can then be selectively turned off in production), by making code-build-test cycles faster, and by making it easy to inspect what the code does. This approach has tradeoffs: it is unsound so it will let some undefined behavior bugs through; on the other hand it might do more to reduce bugs that are unrelated to undefined behavior.

by jeltz 7y ago

pron 7y ago

Yep, Zig is the one I like, and IMO it's a language that shows an interesting yet very simple model for what systems programming can be. But I'll admit that it's easier to look good before you're put to the test in the field, so I'll wait and see what becomes of it.

devit 7y ago
As far as I can tell Zig is equivalent to a subset of C++ and thus completely lacks all the guarantees that Rust provides and several of the features that C++ has; so there is no point to use it instead of those languages.
- pron 7y ago
  If you prefer languages with more features, then simple languages aren't for you. But me? If you told me you'd give me language X but with far fewer features, my eyes would light up, and I'd only ask, are you sure you can't get rid of any more? As Saint-Exupery said, "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Zig has all you need to write clear, efficient, generic, systems code and nothing more, but also nothing less. It is also intended to help you write safe code, but it goes about it differently from Rust.
  - devit 7y ago
    As far as I can tell Zig only has C-like malloc/free-based allocation and thus is vulnerable to use-after-free, and so does NOT help you write safe code. It also doesn't seem capable of safe concurrency.
    - pron 7y ago
      You assume that the only way a language can help you write safe code is by making sound guarantees; this is wrong. A language can also help you write safe code by making it easy to selectively add runtime checks (that can then be selectively turned off in production), by making code-build-test cycles faster, and by making it easy to inspect what the code does. This approach has tradeoffs: it is unsound so it will let some undefined behavior bugs through; on the other hand it might do more to reduce bugs that are unrelated to undefined behavior.