3 ms·

Zig shouldn't be mentioned here - of course it's compiler dependent, because it doesn't claim to be a stable language yet.

throwawaymaths 4y ago
And not only that, specification is an explicit goal (they have a sepcification person in the core team even at this early stage). But what is interesting I think is that if miniRust is successful (or even if it isn't) zig can learn lessons on how to do borrow checking on zir: even if it isn't part of the official language release it could be a useful tool for ci/linting/touchup, especially if it becomes an "anointed" tool
- tcmart14 4y ago
  To back up the comment on specification. On one of the recent Rust podcasts, they had Andrew Kelley on. From what he says, the roadmap has them publishing a formal specification of the language once they 1.0. So yea, it is on the roadmap and an intention with making the stable 1.0.
  - ralfj 4y ago
    Which podcast was that? A Rust podcast with the main Zig dev sounds very interesting!
    - tcmart14 4y ago
      Rustacean Station, 24 Jun 2022 was when it was posted.
- pcwalton 4y ago
  Borrow checking only works if your APIs are designed with borrow checking in mind. Zig's APIs are not, so they won't borrow check.
  - throwawaymaths 4y ago
    Wrong. There is a clear set of logical rules by which you can look at code and reason about whether or not there are resource errors. If you can do it, a computer can do it too. You may need to have hints, like annotating a function called "alloc" or "open" as creating a resource, but I think that's not unreasonable.
    - pcwalton 4y ago
      Yes, that "clear set of logical rules" is called the Rust ownership and lifetime system, and the system that enforces it is called the borrow check. And, having designed a lot of Rust's borrow rules, I'm telling you that the borrow check only works because of the specific rules that Rust enforces: in particular, no more than one mutable pointer to a location. Non-Rust languages don't enforce those rules, so grafting the Rust borrow check onto the language will rule out a lot of idiomatic code. For example, in C++, you would be unable to write shared_ptr<T> for non-const T (this is just one of a mountain of examples), and I'm sure that the situation would be similar in Zig once you start diving into the details. I'm much more interested in specific details of how to permit mutable aliasing while simultaneously avoiding use-after-free. From what I've seen, the only compelling answer is a garbage collector.
      - throwawaymaths 4y ago
        I think your concept of what is possible with languages is limited and you are suffering from either narrow tunnel vision or some sort of emotional overinvestment in what you've put effort into. I don't know what the right answer is. It could be as complicated as something like SEL4 does, it could be like typescript is for JavaScript, it could be annotation based like dialyzer is for Erlang. Not all of these are perfect, of course, but the point is is a wide open space of tradeoffs in safety, performance, and ergonomics (including ability to reason about scary vulnerabilities that rust can't auto fix like race conditions or business logic errord) between "what rust looks like" and "c level wild west".
        4y ago
j-pb 4y ago
It's still a good example where the specification is in flux and a lot of documentation virtually non-existent (e.g. std), but that is still very usable, simply due to the fact that it isn't a very complex language in terms of semantics, which in turn makes it less dependent on a very precise spec.

throwawaymaths 4y ago

And not only that, specification is an explicit goal (they have a sepcification person in the core team even at this early stage). But what is interesting I think is that if miniRust is successful (or even if it isn't) zig can learn lessons on how to do borrow checking on zir: even if it isn't part of the official language release it could be a useful tool for ci/linting/touchup, especially if it becomes an "anointed" tool

tcmart14 4y ago
To back up the comment on specification. On one of the recent Rust podcasts, they had Andrew Kelley on. From what he says, the roadmap has them publishing a formal specification of the language once they 1.0. So yea, it is on the roadmap and an intention with making the stable 1.0.
- ralfj 4y ago
  Which podcast was that? A Rust podcast with the main Zig dev sounds very interesting!
  - tcmart14 4y ago
    Rustacean Station, 24 Jun 2022 was when it was posted.
pcwalton 4y ago
Borrow checking only works if your APIs are designed with borrow checking in mind. Zig's APIs are not, so they won't borrow check.
- throwawaymaths 4y ago
  Wrong. There is a clear set of logical rules by which you can look at code and reason about whether or not there are resource errors. If you can do it, a computer can do it too. You may need to have hints, like annotating a function called "alloc" or "open" as creating a resource, but I think that's not unreasonable.
  - pcwalton 4y ago
    Yes, that "clear set of logical rules" is called the Rust ownership and lifetime system, and the system that enforces it is called the borrow check. And, having designed a lot of Rust's borrow rules, I'm telling you that the borrow check only works because of the specific rules that Rust enforces: in particular, no more than one mutable pointer to a location. Non-Rust languages don't enforce those rules, so grafting the Rust borrow check onto the language will rule out a lot of idiomatic code. For example, in C++, you would be unable to write shared_ptr<T> for non-const T (this is just one of a mountain of examples), and I'm sure that the situation would be similar in Zig once you start diving into the details. I'm much more interested in specific details of how to permit mutable aliasing while simultaneously avoiding use-after-free. From what I've seen, the only compelling answer is a garbage collector.
    - throwawaymaths 4y ago
      I think your concept of what is possible with languages is limited and you are suffering from either narrow tunnel vision or some sort of emotional overinvestment in what you've put effort into. I don't know what the right answer is. It could be as complicated as something like SEL4 does, it could be like typescript is for JavaScript, it could be annotation based like dialyzer is for Erlang. Not all of these are perfect, of course, but the point is is a wide open space of tradeoffs in safety, performance, and ergonomics (including ability to reason about scary vulnerabilities that rust can't auto fix like race conditions or business logic errord) between "what rust looks like" and "c level wild west".
      - 4y ago

j-pb 4y ago

It's still a good example where the specification is in flux and a lot of documentation virtually non-existent (e.g. std), but that is still very usable, simply due to the fact that it isn't a very complex language in terms of semantics, which in turn makes it less dependent on a very precise spec.