5 ms·

>This means that I get many of the advantages of Rust Arguably, you don't. The big difference is whether your compiler enforces and tracks your documentation,

>This means that I get many of the advantages of Rust Arguably, you don't. The big difference is whether your compiler enforces and tracks your documentation, assumptions used by your code, often critically important for correctness. Unfortunately, Rust is far from being perfect in this regard (e.g. SPARK probably does a better job here), but it significantly improves on C/C++ in this regard. >I Work Alone Unfortunately, even if you are the only soul touching the code, it often quickly becomes false. On a big enough project, "alone" inevitably becomes "me and that guy who wrote this part of the code". This also can be formulated as "me and 2-years-ago-me". In other words, we quickly forget a lot of context used for writing a piece of code. >Rust is too big for my small brain, unfortunately. I think the lack of hubris, the understanding that small human brains are not enough to keep track of all necessary context required for writing correct software is the key element for liking Rust and similar languages. Rust is not about building ivory towers of abstractions for the sake of it (though some people try to walk in this direction), but about offloading as much as possible of the context on compiler. Unlike humans, the compiler does not get tired, it does not forget. Yes, it's limited and because of those limitations it requires to restructure our code and sprinkle it with additional information, but more often than note it's a good thing. As sel4 and other formally verified software demonstrates, it absolutely can be done in C. But one could say that C used in sel4 is not a C language anymore. After all, you can not take a random C library and use it in sel4.

thrwawy74 4y ago
There are 2 things I've obsessed about in C & C++ land: 1) Why are we explicitly directing a loop forward or backward most of the time when it's not necessary. The compiler should direct the loop unless we want to explicitly do this for the body of the loop. My thinking is that there may be performance reasons to reverse a loop or even split it into separate threads. (unlikely) 2) In C++, I've always wondered how template types get instantiated for POD that is represented the same at the bit level. Does the compiler duplicate the templated code or is it smart enough to say "this std::vector<int> is the same as that std::vector<intalias>". Rust prides itself on zero-cost abstractions, I have wondered if they reduce binary bloat in this area. (as a naive C++ person)
- mike_hock 4y ago
  1) The compiler is already allowed to reorder loop evaluation if it can prove that it can't have any observable side effects. If it can't, there could be subtle dependencies on the order of evaluation that the person writing the code and tests wasn't aware of, so you're just asking for subtle bugs that are missed by tests and could even turn into vulnerabilities in production. 2) It duplicates, and the standard even comes with asinine "guarantees" that actively sabotage deduplication, such as requiring all functions to have different addresses. Which means the compiler can reuse the same function, but only one function label can start right at the code and the others need to NOP-slide or JMP into it. Which unduly pessimizes precisely those functions that are most likely candidates for deduplication: Those that themselves only consist of 2-3 ALU instructions.
  - menaerus 4y ago
    Nr (2) is not correct. Compilers have been inlining functions for decades so the argument of "all functions to have different addresses" does not hold. Compiler can even _merge_ two different but similarly looking functions into a single one. And that's just part of the code transformations compilers can do. And this goes without even mentioning LTO, which has been explicitly designed for optimizing the code layout and size during the linking phase. So, code deduplication is a real thing and happens regularly with your code. Templates are no much different than the non-templated code written for the same purpose.
    - ynik 4y ago
      If you take the address of different functions, the standard requires those to compare unequal. However if you merely call functions and never take their address, the standard doesn't put any requirements on that, so inlining etc. is legal. But without LTO, it's impossible for the compiler to know whether a non-inline function with external linkage will be called or have its address taken, so the compiler must ensure that it has a unique address.
      - leni536 4y ago
saghm 4y ago
I think they may have buried the lede a bit: > I’ve written code in so many languages: [omitted list of a couple dozen languages] > and many more. > When it comes to the enjoyment of programming, I hate all of them. With a passion. > Except for C. I get the sense that this is the real reason, and the rest of it is justification that they understand the risks involved but choose to do it anyways. And honestly, I think this it's fine? I'd argue that it's a little inconsistent with their statement above that avoiding C/C++ in lieu of memory safe languages and should be followed by default, but they subsequently admit to being hypocritical about this, so I'm not really concerned that they don't understand the benefits of memory safety. When it comes down to it, I have middling confidence that I would be able convince someone who still at this point doubts that Rust is safer than C, but I have absolutely no illusions that I can convince someone to change a personal preference. If anything, it's a bit refreshing to see it freely admitted, given how often it seems to be the real reason for a lot of choices of what language to use (and I don't just mean this for C/C++, but for any language, including Rust).
- santoshalper 4y ago
  I think he's fairly transparent that it is the only reason. "I program in C because I enjoy it even though I know objectively it is not a terribly good choice for building software" is pretty much the entire article.

thrwawy74 4y ago

There are 2 things I've obsessed about in C & C++ land: 1) Why are we explicitly directing a loop forward or backward most of the time when it's not necessary. The compiler should direct the loop unless we want to explicitly do this for the body of the loop. My thinking is that there may be performance reasons to reverse a loop or even split it into separate threads. (unlikely) 2) In C++, I've always wondered how template types get instantiated for POD that is represented the same at the bit level. Does the compiler duplicate the templated code or is it smart enough to say "this std::vector<int> is the same as that std::vector<intalias>". Rust prides itself on zero-cost abstractions, I have wondered if they reduce binary bloat in this area. (as a naive C++ person)

mike_hock 4y ago
1) The compiler is already allowed to reorder loop evaluation if it can prove that it can't have any observable side effects. If it can't, there could be subtle dependencies on the order of evaluation that the person writing the code and tests wasn't aware of, so you're just asking for subtle bugs that are missed by tests and could even turn into vulnerabilities in production. 2) It duplicates, and the standard even comes with asinine "guarantees" that actively sabotage deduplication, such as requiring all functions to have different addresses. Which means the compiler can reuse the same function, but only one function label can start right at the code and the others need to NOP-slide or JMP into it. Which unduly pessimizes precisely those functions that are most likely candidates for deduplication: Those that themselves only consist of 2-3 ALU instructions.
- menaerus 4y ago
  Nr (2) is not correct. Compilers have been inlining functions for decades so the argument of "all functions to have different addresses" does not hold. Compiler can even _merge_ two different but similarly looking functions into a single one. And that's just part of the code transformations compilers can do. And this goes without even mentioning LTO, which has been explicitly designed for optimizing the code layout and size during the linking phase. So, code deduplication is a real thing and happens regularly with your code. Templates are no much different than the non-templated code written for the same purpose.
  - ynik 4y ago
    If you take the address of different functions, the standard requires those to compare unequal. However if you merely call functions and never take their address, the standard doesn't put any requirements on that, so inlining etc. is legal. But without LTO, it's impossible for the compiler to know whether a non-inline function with external linkage will be called or have its address taken, so the compiler must ensure that it has a unique address.
    - leni536 4y ago

saghm 4y ago

I think they may have buried the lede a bit: > I’ve written code in so many languages: [omitted list of a couple dozen languages] > and many more. > When it comes to the enjoyment of programming, I hate all of them. With a passion. > Except for C. I get the sense that this is the real reason, and the rest of it is justification that they understand the risks involved but choose to do it anyways. And honestly, I think this it's fine? I'd argue that it's a little inconsistent with their statement above that avoiding C/C++ in lieu of memory safe languages and should be followed by default, but they subsequently admit to being hypocritical about this, so I'm not really concerned that they don't understand the benefits of memory safety. When it comes down to it, I have middling confidence that I would be able convince someone who still at this point doubts that Rust is safer than C, but I have absolutely no illusions that I can convince someone to change a personal preference. If anything, it's a bit refreshing to see it freely admitted, given how often it seems to be the real reason for a lot of choices of what language to use (and I don't just mean this for C/C++, but for any language, including Rust).

santoshalper 4y ago
I think he's fairly transparent that it is the only reason. "I program in C because I enjoy it even though I know objectively it is not a terribly good choice for building software" is pretty much the entire article.