6 ms·

> He considers Rust too ideologically opinionated to be of use to him. He's not wrong. The rust community approaches everything from the standpoint that we sho

> He considers Rust too ideologically opinionated to be of use to him. He's not wrong. The rust community approaches everything from the standpoint that we should be forcing devs to code in a particular way because safety. What I like about Blow is that, so far, he's big into giving the dev options along with some (completely optional) syntactic sugar. The focus is on functionality, not ideology.

sanxiyn 11y ago
The idea that a programming language should focus more on helping people do things (functionality) rather than preventing people do things (safety) is an ideological stance, just as much as the reverse. Describing one side as functionality and the other side as ideology is not a good description. I understand that many people's ideology align better with Jai compared to Rust. On the other hand, many other people's ideology align better with Rust compared to Jai.
pcwalton 11y ago
> The rust community approaches everything from the standpoint that we should be forcing devs to code in a particular way because safety No, I'd actually be perfectly fine allowing the safety features to be turned off, and have suggested it several times. Nobody has seemed particularly interested, though, because what people tend to find is that safety ends up being good for productivity as well.
- sanxiyn 11y ago
  I don't think that's entirely true. We had many people interested in turning off bound checks with compile option, but it was rejected.
  - pjmlp 11y ago
    Those who don't learn from history are doomed to repeat it. My favorite Hoare quote given at his ACM award speech in 1980, referring to his work in Algol during the late 60's: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
    - erikpukinskis 11y ago
      In Jai it is easy to, for example, have bounds checks on during the entire development process to aid in finding bugs, then turn off bounds checks in a dozen critical loops for testing and release, then turn bounds checking on in one loop that still proved crash-y. Blow has said many times: he doesn't think the language should be prevent you from shooting yourself in the foot, because sometimes that means preventing you from doing what you want to do. He usually asks: what is something simple we can do that will give us 90% of the benefit, without adding a layer of overhead. Rather than Rust's "Safe All The Things!" approach, bounds checking is just another tool you can use or not use as is appropriate for the context.
      - pcwalton 11y ago
        > In Jai it is easy to, for example, have bounds checks on during the entire development process to aid in finding bugs, then turn off bounds checks in a dozen critical loops for testing and release, then turn bounds checking on in one loop that still proved crash-y. That's pretty much exactly Rust's philosophy as well. > Rather than Rust's "Safe All The Things!" approach, bounds checking is just another tool you can use or not use as is appropriate for the context. Rust's philosophy is not "Safe All The Things". It has "unsafe" for a reason. Anyway, I really dislike the overfocus on bounds checks, because they're pretty much zero overhead if properly implemented and optimized.
      - agentultra 11y ago
        Most Common Lisp implementations, for what it's worth, take this approach as well. For tight loops where you've removed the invariants and proved its bounds removing the run-time checks can give a non-trivial performance boost to production systems.
        zurn 11y ago
        If you mean the (speed 3 safety 0), it's more in line with pcwalton's idea to have a switch for generally turning off safety checks, not just bounds checks - because the other checks typically affect performance more.
  - pcwalton 11y ago
    > We had many people interested in turning off bound checks with compile option, but it was rejected. Can you cite where this happened? This sounds like it was an executive decision, but as I recall the community was opposed to a switch to turn off bounds checks. (Rightly so: the overhead of bounds checks is near zero.) As I recall, there were some people asking for a bounds check switch, but they were mostly people coming from the D community and new to Rust who were asking for a copy of the -noboundscheck switch (without benchmarks to show that it would help). The more interesting option would be something to turn off the lifetime, borrow, and mutability checks. But when I suggested this, almost nobody seemed particularly interested.
    - sanxiyn 11y ago
      Yes, I was referring to request to provide copy of -noboundscheck. You stated that nobody seemed interested in turning off safety features, so I provided a counterexample. As a matter of fact, I am interested in -noboundscheck switch. The motivation is so that people can easily confirm bound checks overhead is zero by themselves, because it seems many people find this hard to believe. I didn't submit a pull request implementing this (it is easy to implement) because I thought it was fait accompli. Was I mistaken and you will support such pull request?
      - pcwalton 11y ago
        It'd need to go through an RFC process, but I would be neutral and not opposed to such an RFC.
      - kibwen 11y ago
        I actually intend to benchmark this myself in the future and write a comprehensive blog post on my findings. Personally, I would oppose any RFC that attempted to add such a compiler flag, especially if its only purpose was to prove a point.
dkersten 11y ago
because safety I'd rather play a game that performs a little poorly than a game that crashes. I gave up on Dragon Age Origins due to how buggy it was, for example. I've also refrained from buying games that looked great due to bug reports. I can't tolerate a broken product, but I can tolerate one that doesn't perform quite as well as I'd like. Therefore, I think giving up on safety in favour of performance is a bad idea. Sure, its possible to write good code in any language, but the fact is people make mistakes, a lot and software is, in general, extremely buggy. Of course, I understand that not everyone thinks like me and the "average gamer" is possibly much less forgiving for performance problems than I am, so Blow of course is doing what he feels best serves his goals for the market he's in.
pjmlp 11y ago
The CVE database is full of proofs of what happens when a language that disregards safety like C gets adopted. Profilers do exist.

sanxiyn 11y ago

The idea that a programming language should focus more on helping people do things (functionality) rather than preventing people do things (safety) is an ideological stance, just as much as the reverse. Describing one side as functionality and the other side as ideology is not a good description. I understand that many people's ideology align better with Jai compared to Rust. On the other hand, many other people's ideology align better with Rust compared to Jai.

pcwalton 11y ago

> The rust community approaches everything from the standpoint that we should be forcing devs to code in a particular way because safety No, I'd actually be perfectly fine allowing the safety features to be turned off, and have suggested it several times. Nobody has seemed particularly interested, though, because what people tend to find is that safety ends up being good for productivity as well.

sanxiyn 11y ago
I don't think that's entirely true. We had many people interested in turning off bound checks with compile option, but it was rejected.
- pjmlp 11y ago
  Those who don't learn from history are doomed to repeat it. My favorite Hoare quote given at his ACM award speech in 1980, referring to his work in Algol during the late 60's: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
  - erikpukinskis 11y ago
    In Jai it is easy to, for example, have bounds checks on during the entire development process to aid in finding bugs, then turn off bounds checks in a dozen critical loops for testing and release, then turn bounds checking on in one loop that still proved crash-y. Blow has said many times: he doesn't think the language should be prevent you from shooting yourself in the foot, because sometimes that means preventing you from doing what you want to do. He usually asks: what is something simple we can do that will give us 90% of the benefit, without adding a layer of overhead. Rather than Rust's "Safe All The Things!" approach, bounds checking is just another tool you can use or not use as is appropriate for the context.
    - pcwalton 11y ago
      > In Jai it is easy to, for example, have bounds checks on during the entire development process to aid in finding bugs, then turn off bounds checks in a dozen critical loops for testing and release, then turn bounds checking on in one loop that still proved crash-y. That's pretty much exactly Rust's philosophy as well. > Rather than Rust's "Safe All The Things!" approach, bounds checking is just another tool you can use or not use as is appropriate for the context. Rust's philosophy is not "Safe All The Things". It has "unsafe" for a reason. Anyway, I really dislike the overfocus on bounds checks, because they're pretty much zero overhead if properly implemented and optimized.
    - agentultra 11y ago
      Most Common Lisp implementations, for what it's worth, take this approach as well. For tight loops where you've removed the invariants and proved its bounds removing the run-time checks can give a non-trivial performance boost to production systems.
      - zurn 11y ago
        If you mean the (speed 3 safety 0), it's more in line with pcwalton's idea to have a switch for generally turning off safety checks, not just bounds checks - because the other checks typically affect performance more.
- pcwalton 11y ago
  > We had many people interested in turning off bound checks with compile option, but it was rejected. Can you cite where this happened? This sounds like it was an executive decision, but as I recall the community was opposed to a switch to turn off bounds checks. (Rightly so: the overhead of bounds checks is near zero.) As I recall, there were some people asking for a bounds check switch, but they were mostly people coming from the D community and new to Rust who were asking for a copy of the -noboundscheck switch (without benchmarks to show that it would help). The more interesting option would be something to turn off the lifetime, borrow, and mutability checks. But when I suggested this, almost nobody seemed particularly interested.
  - sanxiyn 11y ago
    Yes, I was referring to request to provide copy of -noboundscheck. You stated that nobody seemed interested in turning off safety features, so I provided a counterexample. As a matter of fact, I am interested in -noboundscheck switch. The motivation is so that people can easily confirm bound checks overhead is zero by themselves, because it seems many people find this hard to believe. I didn't submit a pull request implementing this (it is easy to implement) because I thought it was fait accompli. Was I mistaken and you will support such pull request?
    - pcwalton 11y ago
      It'd need to go through an RFC process, but I would be neutral and not opposed to such an RFC.
    - kibwen 11y ago
      I actually intend to benchmark this myself in the future and write a comprehensive blog post on my findings. Personally, I would oppose any RFC that attempted to add such a compiler flag, especially if its only purpose was to prove a point.

dkersten 11y ago

because safety I'd rather play a game that performs a little poorly than a game that crashes. I gave up on Dragon Age Origins due to how buggy it was, for example. I've also refrained from buying games that looked great due to bug reports. I can't tolerate a broken product, but I can tolerate one that doesn't perform quite as well as I'd like. Therefore, I think giving up on safety in favour of performance is a bad idea. Sure, its possible to write good code in any language, but the fact is people make mistakes, a lot and software is, in general, extremely buggy. Of course, I understand that not everyone thinks like me and the "average gamer" is possibly much less forgiving for performance problems than I am, so Blow of course is doing what he feels best serves his goals for the market he's in.

pjmlp 11y ago

The CVE database is full of proofs of what happens when a language that disregards safety like C gets adopted. Profilers do exist.