3 ms·

To me, this line of thought is backwards. It stems from seeing the people issues as small stuff and the tech issues as the "real deal"... At the end of the da

To me, this line of thought is backwards. It stems from seeing the people issues as small stuff and the tech issues as the "real deal"... At the end of the day new features for popular language X are not that life-or-death (although I'm sure some Rust evangelist will claim the safety of it means it could save lives, ignoring things like MISRA) - If someone is being an asshole and damaging moral for real "meatspace" humans, that's way more of a problem than any loss of productivity that might result from dealing with them head on. Contrary to popular belief, the world will not end if language X doesn't do Y right this second. So it's better to clean house as needed, rather than let things get to the point where everyone is burned out on interacting with your fiefdom .

q1w2 5y ago
You see - this comment is so vague, I still have no idea what (in the tech) they're fighting about.
- BoorishBears 5y ago
  What? My comment is vague because this is a common line of thought: "Project X is having people problems" "What is this childish drama distracting from the technical stuff they should be accomplishing" - Their post is vague because they're mature enough to not want to turn this into a public lynching. It's on their replacements to handle it. There's a certain irony in the fact you don't realize that...
- CRConrad 5y ago
  What on Earth gave you the idea they're fighting about anything "in the tech"?
tialaramex 5y ago
> ignoring things like MISRA Not so much ignoring, as recognising that much of what MISRA requires mechanically (ie that MISRA tools will let you check for a Continuous Integration setup automatically) is baked into Rust itself, and much of what MISRA asks beyond that is built into Rust's way of doing things. My favourite this week: MISRA tells you never to use the result of an assignment operator. In Rust you can't because the assignment operators don't have a result.
- BoorishBears 5y ago
  MISRA goes further than Rust can and still be a widely useful language. You'd need to define a very specific subset of Rust to approach its level of regulation and the additional layers added by ISO standards where it's often used
  - tialaramex 5y ago
    Do you have some examples of MISRA rules you think would need "a very specific subset of Rust" rather than for example, #![forbid(unused)] to obey MISRA's rejection of unused stuff ? A lot of MISRA is concerned with defects in C - or in its standard library and the usual C idiom - that simply aren't present in Rust and so need zero work to eliminate. For example MISRA forbids trigraphs. Rust of course doesn't have trigraphs. A bunch more is stuff Rust warns about, that you can tell it to outright forbid, such as #![forbid(unused)] to obey various MISRA rules about using things. In a few places MISRA obliges you to either squint hard at the rules, or agree that it is contradictory and you must grant yourself a deviation from the rules, while Rust just solves the underlying conundrum entirely. For example MISRA wants exhaustive matching, it has rules for switches to try to achieve that but in the process it introduces dead code it has already forbidden. Rust only has exhaustive matching anyway - if your match compiles it was exhaustive - thus there is no need to introduce dead code "just in case".
    - BoorishBears 5y ago
      I think you're understimating how far MISRA goes. Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc. Rust might get the big stuff but MISRA is adhered to exactly in contexts where things that would be "nitpicky" or over-opinionated for a general use language improve safety. Pure Rust would never be a replacement for that without additional static analysis.
      - tialaramex 5y ago
        I asked you for some example rules, and you provided some > Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc. #![forbid(clippy::shadow_reuse)] ... is a Clippy lint denying shadowing to re-use variables. There are a couple more Clippy lints to deny other types of shadowing. Whether all, some or none of these are actually a good idea depends whether your goal is to just do what MISRA says no matter, or actually write better code. #![forbid(clippy::default_numeric_fallback)] ... is a lint requiring that you specifically say what type numbers are rather than relying on the inference to conclude they're i32 if there's no reason they should be anything else. #![forbid(unused)] ... I already mentioned, it outright forbids your code from not using things, function parameters, variables, whatever. If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea". I suppose this might help to rein in some "Real programmer" types at an embedded systems firm using C by giving their manager a tool that says e.g. no, actually redefining size_t is not a clever trick, but it means all those rules are entirely irrelevant for any modern language, not just Rust.

q1w2 5y ago

You see - this comment is so vague, I still have no idea what (in the tech) they're fighting about.

BoorishBears 5y ago
What? My comment is vague because this is a common line of thought: "Project X is having people problems" "What is this childish drama distracting from the technical stuff they should be accomplishing" - Their post is vague because they're mature enough to not want to turn this into a public lynching. It's on their replacements to handle it. There's a certain irony in the fact you don't realize that...
CRConrad 5y ago
What on Earth gave you the idea they're fighting about anything "in the tech"?

tialaramex 5y ago

> ignoring things like MISRA Not so much ignoring, as recognising that much of what MISRA requires mechanically (ie that MISRA tools will let you check for a Continuous Integration setup automatically) is baked into Rust itself, and much of what MISRA asks beyond that is built into Rust's way of doing things. My favourite this week: MISRA tells you never to use the result of an assignment operator. In Rust you can't because the assignment operators don't have a result.

BoorishBears 5y ago
MISRA goes further than Rust can and still be a widely useful language. You'd need to define a very specific subset of Rust to approach its level of regulation and the additional layers added by ISO standards where it's often used
- tialaramex 5y ago
  Do you have some examples of MISRA rules you think would need "a very specific subset of Rust" rather than for example, #![forbid(unused)] to obey MISRA's rejection of unused stuff ? A lot of MISRA is concerned with defects in C - or in its standard library and the usual C idiom - that simply aren't present in Rust and so need zero work to eliminate. For example MISRA forbids trigraphs. Rust of course doesn't have trigraphs. A bunch more is stuff Rust warns about, that you can tell it to outright forbid, such as #![forbid(unused)] to obey various MISRA rules about using things. In a few places MISRA obliges you to either squint hard at the rules, or agree that it is contradictory and you must grant yourself a deviation from the rules, while Rust just solves the underlying conundrum entirely. For example MISRA wants exhaustive matching, it has rules for switches to try to achieve that but in the process it introduces dead code it has already forbidden. Rust only has exhaustive matching anyway - if your match compiles it was exhaustive - thus there is no need to introduce dead code "just in case".
  - BoorishBears 5y ago
    I think you're understimating how far MISRA goes. Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc. Rust might get the big stuff but MISRA is adhered to exactly in contexts where things that would be "nitpicky" or over-opinionated for a general use language improve safety. Pure Rust would never be a replacement for that without additional static analysis.
    - tialaramex 5y ago
      I asked you for some example rules, and you provided some > Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc. #![forbid(clippy::shadow_reuse)] ... is a Clippy lint denying shadowing to re-use variables. There are a couple more Clippy lints to deny other types of shadowing. Whether all, some or none of these are actually a good idea depends whether your goal is to just do what MISRA says no matter, or actually write better code. #![forbid(clippy::default_numeric_fallback)] ... is a lint requiring that you specifically say what type numbers are rather than relying on the inference to conclude they're i32 if there's no reason they should be anything else. #![forbid(unused)] ... I already mentioned, it outright forbids your code from not using things, function parameters, variables, whatever. If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea". I suppose this might help to rein in some "Real programmer" types at an embedded systems firm using C by giving their manager a tool that says e.g. no, actually redefining size_t is not a clever trick, but it means all those rules are entirely irrelevant for any modern language, not just Rust.