5 ms·

Yep, a lot of people have noticed that. He's mentioned Rust in a few of his videos (and the compiler devs are always taking notes about his grievances) but he d

Yep, a lot of people have noticed that. He's mentioned Rust in a few of his videos (and the compiler devs are always taking notes about his grievances) but he doesn't seem interested in working with the Rust community in any way. He considers Rust too ideologically opinionated to be of use to him.

dkersten 11y ago
Jai also seems rather "ideologically opinionated" to me (which isn't a bad thing in my opinion).
PopeOfNope 11y ago
> 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.
- 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.
0xcde4c3db 11y ago
From the perspective of someone like Blow, Rust's concept of safety is like childproofing a house by putting latches on all the cabinets while ignoring the loaded gun on the coffee table.
- humanrebar 11y ago
  I don't follow the analogy. What's Rust's loaded gun?
  - 0xcde4c3db 11y ago
    It's not Rust's loaded gun, which is sort of the problem. Basically, I'm talking about the sorts of relatively low-level APIs whose use is somewhat obligatory for Getting Stuff Done in a performant way, and for which higher-level interfaces typically deny sufficient control and/or hurt performance by heavily wrapping (and often quietly copying/rearranging) the critical data structures and operations. Things like ioctl() calls, OpenGL/DirectX, and so on. Misusing these (or just encountering bugs in them) can pretty easily trash your application -- and sometimes even your kernel -- in really messy ways.
    - pcwalton 11y ago
      > Basically, I'm talking about the sorts of relatively low-level APIs whose use is somewhat obligatory for Getting Stuff Done in a performant way, and for which higher-level interfaces typically deny sufficient control and/or hurt performance by heavily wrapping (and often quietly copying/rearranging) the critical data structures and operations. Things like ioctl() calls, OpenGL/DirectX, and so on. Misusing these (or just encountering bugs in them) can pretty easily trash your application -- and sometimes even your kernel -- in really messy ways. OK, but that's why glium is so popular (quite possibly the preferred OpenGL binding in the community nowadays?), which has very low overhead while maintaining OpenGL safety. ioctls have similar wrappers for the important ones.
      - 0xcde4c3db 11y ago
cturner 11y ago
When you do new things, one of the challenges is other people's mental prototyping process. Crowds line up to say, "it's like x," when it's not. They just don't grok you yet. It takes time for people to get used to unfamiliar ideas. Rust is a multi-purpose language, with an emphasis on clever type systems. That's not Blow's focus. He wants there to be a clear path between simple code he's writing and the fast compiled code that results. He likes C, specifically this quality: you can reason about what the hardware is doing, and write C, and count on it doing exactly what you want. His emphasis in the work he's doing is to make a memory-foundry language that stresses this kind of power, with less of C's warts (and non of C++'s). Mundane example: he has created a not-annoying function pointer syntax. Less obvious: he has created a high-level syntax that appears to be array-of-structs, but which you can /reason/ will be compiled to struct-of-arrays for caching purposes.
- deleted 11y ago
  [deleted]
  - deleted 11y ago
    [deleted]

dkersten 11y ago

Jai also seems rather "ideologically opinionated" to me (which isn't a bad thing in my opinion).

PopeOfNope 11y ago

> 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.
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.

0xcde4c3db 11y ago

From the perspective of someone like Blow, Rust's concept of safety is like childproofing a house by putting latches on all the cabinets while ignoring the loaded gun on the coffee table.

humanrebar 11y ago
I don't follow the analogy. What's Rust's loaded gun?
- 0xcde4c3db 11y ago
  It's not Rust's loaded gun, which is sort of the problem. Basically, I'm talking about the sorts of relatively low-level APIs whose use is somewhat obligatory for Getting Stuff Done in a performant way, and for which higher-level interfaces typically deny sufficient control and/or hurt performance by heavily wrapping (and often quietly copying/rearranging) the critical data structures and operations. Things like ioctl() calls, OpenGL/DirectX, and so on. Misusing these (or just encountering bugs in them) can pretty easily trash your application -- and sometimes even your kernel -- in really messy ways.
  - pcwalton 11y ago
    > Basically, I'm talking about the sorts of relatively low-level APIs whose use is somewhat obligatory for Getting Stuff Done in a performant way, and for which higher-level interfaces typically deny sufficient control and/or hurt performance by heavily wrapping (and often quietly copying/rearranging) the critical data structures and operations. Things like ioctl() calls, OpenGL/DirectX, and so on. Misusing these (or just encountering bugs in them) can pretty easily trash your application -- and sometimes even your kernel -- in really messy ways. OK, but that's why glium is so popular (quite possibly the preferred OpenGL binding in the community nowadays?), which has very low overhead while maintaining OpenGL safety. ioctls have similar wrappers for the important ones.
    - 0xcde4c3db 11y ago

cturner 11y ago

When you do new things, one of the challenges is other people's mental prototyping process. Crowds line up to say, "it's like x," when it's not. They just don't grok you yet. It takes time for people to get used to unfamiliar ideas. Rust is a multi-purpose language, with an emphasis on clever type systems. That's not Blow's focus. He wants there to be a clear path between simple code he's writing and the fast compiled code that results. He likes C, specifically this quality: you can reason about what the hardware is doing, and write C, and count on it doing exactly what you want. His emphasis in the work he's doing is to make a memory-foundry language that stresses this kind of power, with less of C's warts (and non of C++'s). Mundane example: he has created a not-annoying function pointer syntax. Less obvious: he has created a high-level syntax that appears to be array-of-structs, but which you can /reason/ will be compiled to struct-of-arrays for caching purposes.

deleted 11y ago
[deleted]
- deleted 11y ago
  [deleted]