9 ms·

I don't get all the C "hate" either. Sure, C is a source of many "interesting" things - but it's also a natural part of control systems in avionics, space craft

I don't get all the C "hate" either. Sure, C is a source of many "interesting" things - but it's also a natural part of control systems in avionics, space craft and nuclear power plants. I don't want someone who just read that "Rust is a great, safe language" to rewrite those. I really don't.

fiedzia 10y ago
And I do. Planes crashed and people died because of buggy software. We have lost Mars climate orbiter due to not using type-safe language. In the cases of software that works fine, we are just relying on ridiculous amount of manual verification, and this is both risky and expensive.
- mikulas_florek 10y ago
  Mars Climate Orbiter was lost because they forgot to convert units between different systems. That's an error that can (and probably would) be done in all type-safe languages I know of.
  - fiedzia 10y ago
    It could be prevented if you could express units in the type system. Declare numeric_value_in_meters and numeric_value_in_yards as types and problem solved. Sure, it still possible that someone would not do that, but having this option is statistically better than not having.
    - mikulas_florek 10y ago
      You can do that in C struct Meters { int value; }
      - fiedzia 10y ago
        Yes, but nothing will stop you from casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. You also cannot override operators for combining those units. And the value is still just int.
        mikulas_florek 10y ago
        > casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. What C feature forces or encourages casting Meters* to Yards*? > You also cannot override operators for combining those units. The lack of operator overloads has nothing to do with typesafety. There are languages which are considered typesafe and which do not have operator overloading.
      - jasode 10y ago
        No, it's not statically checked for correctness. Example of successful compilation in C Language which is semantically wrong: http://ideone.com/Hdd4Sh http://ideone.com/Hdd4Sh (No casts required.)
        mikulas_florek 10y ago
        It's hard to discuss this without using any specific "type-safe" language. 1. you can have the same problem in type-safe language, since it will probably have cast to int too 2. do not use builtin operators in C for that, instead create new functions, e.g. addMeters(Meters a, Meters b); 3. hide the int in *.c file
        fiedzia 10y ago
        > you can have the same problem in type-safe language Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. > do not use builtin operators in C for that No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer.
        mikulas_florek 10y ago
        > Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. I highly doubt that this specific bug would not happen in any typesafe language. The only way I see this not happening is if there is no native float-like type. Is there such language? They could have make it safe in C, and they did not, probably because it's convenient to use float. > No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer. It can be implemented in C so it's forced by compiler.
        jasode 10y ago
        Look at the common theme among your suggestions: - do not use builtin operators in C for that, - instead create new functions, e.g. addMeters() - hide the int in *.c file Those are "best practices" instead of compiler-enforced type-check errors. Likewise, suggesting a best practice such as "don't free() memory twice" is not the same as a GC-language (Lisp/Java/C#/Go) freeing memory on the programmer's behalf or a static-ownership checker (Rust) preventing a programmer from making that mistake.
      - JoachimSchipper 10y ago
        Yes, although you should probably do struct value_in_meters { int in_meters; }, so that e.g. x.in_meters / y.in_inches (will compile, but) looks as wrong as it is.
  - muraiki 10y ago
    F# supports units of measure: https://fsharpforfunandprofit.com/posts/units-of-measure/ https://fsharpforfunandprofit.com/posts/units-of-measure/
    - mikulas_florek 10y ago
      That looks useful. I do not know F#, but can't you still use ordinary float and have the same bug?
      - kazagistar 10y ago
        Sure, unit wrappers are much more like "memory safety checks" in C, in that they are incomplete and can be bypassed. In that sense, the war against raw types is necessarily a cultural one.
- buserror 10y ago
  No amount of 'type safety' will prevent idiots from being idiots, and with all the other languages, the problem is very often sitting on the chair. People will screw up creatively in any language, and trying to 'hide' that behind a language runtime overhead is idiotic. The good thing with C is that it will catch the worst idiots quickly, so you know not to hire them to write avionics for you. What is NOT idiotic iswhat you discribe as 'ridiculous amount of verification' as it's often the only thing that will really work to catch mistakes.
  - fiedzia 10y ago
    > No amount of 'type safety' will prevent idiots from being idiots But it will limit the damage they do considerably. Having bit of space or trees between lanes on a road saves a lot of lives, even if people drive as idiotically as they would without it. > What is NOT idiotic is what you discribe as 'ridiculous amount of verification' Designing systems that rely only on that is idiotic when there are better options.
- zuzun 10y ago
  > We have lost Mars climate orbiter due to not using type-safe language. One company creates a closed-source component that produces a float, another company creates a closed-source component that receives a float. Units differ. Crash. No type-safe language will prevent that bug from happening. Let 100 programmers write these programs in your type-safe language of choice and all will be vulnerable to this. "Oh no", I hear you say, "we'll give every unit its own type" and it still won't stop your programmers from deserializing a 4 byte value in English units into the metric value they think it is. "So we'll make all the IO typed as well!" You don't need a type safe language to do that. And why would you do it in the first place? If your API spec says you receive a float in metric units, you write your program accordingly. When you're writing mission critical software, would you really want to replace a > read(sensor, &value, sizeof(float)) with 100k lines of even buggier code to prevent a bug from happening that shouldn't happen in the first place?
  - fiedzia 10y ago
    > Let 100 programmers write these programs in your type-safe language of choice and all will be vulnerable to this. Some will be, some will define inteface as float_meters and define automatic conversion from yards, avoiding whole issue.
  - lkitching 10y ago
    All bugs "shouldn't happen in the first place", the use of types is to reduce the surface area for where errors can be introduced. If you read some value from an external source and subsequently use measure types then you've isolated the scope for the introduction of errors to the read function instead of every location in the program that uses the value.
- deleted 10y ago
  [deleted]
throwaway9475 10y ago
I do. We have compilers that can verify seemingly perfectly (as far as we can tell) that a program won't do something silly like reference memory it doesn't own or try to use memory after freeing it (and not just languages like Rust, but any language that doesn't make you allocate and free memory). The best C programmer out there will still make mistakes because it's simply impossible to ensure that large programs won't do something they shouldn't. It boggles my mind that programmers seem to love better tooling and better abstractions, but when it comes to a certain class of languages, everything stopped improving in the 1970s with the PDP-11 and we just can't get past it.

fiedzia 10y ago

And I do. Planes crashed and people died because of buggy software. We have lost Mars climate orbiter due to not using type-safe language. In the cases of software that works fine, we are just relying on ridiculous amount of manual verification, and this is both risky and expensive.

mikulas_florek 10y ago
Mars Climate Orbiter was lost because they forgot to convert units between different systems. That's an error that can (and probably would) be done in all type-safe languages I know of.
- fiedzia 10y ago
  It could be prevented if you could express units in the type system. Declare numeric_value_in_meters and numeric_value_in_yards as types and problem solved. Sure, it still possible that someone would not do that, but having this option is statistically better than not having.
  - mikulas_florek 10y ago
    You can do that in C struct Meters { int value; }
    - fiedzia 10y ago
      Yes, but nothing will stop you from casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. You also cannot override operators for combining those units. And the value is still just int.
      - mikulas_florek 10y ago
        > casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. What C feature forces or encourages casting Meters* to Yards*? > You also cannot override operators for combining those units. The lack of operator overloads has nothing to do with typesafety. There are languages which are considered typesafe and which do not have operator overloading.
    - jasode 10y ago
      No, it's not statically checked for correctness. Example of successful compilation in C Language which is semantically wrong: http://ideone.com/Hdd4Sh http://ideone.com/Hdd4Sh (No casts required.)
      - mikulas_florek 10y ago
        It's hard to discuss this without using any specific "type-safe" language. 1. you can have the same problem in type-safe language, since it will probably have cast to int too 2. do not use builtin operators in C for that, instead create new functions, e.g. addMeters(Meters a, Meters b); 3. hide the int in *.c file
        fiedzia 10y ago
        > you can have the same problem in type-safe language Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. > do not use builtin operators in C for that No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer.
        mikulas_florek 10y ago
        > Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. I highly doubt that this specific bug would not happen in any typesafe language. The only way I see this not happening is if there is no native float-like type. Is there such language? They could have make it safe in C, and they did not, probably because it's convenient to use float. > No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer. It can be implemented in C so it's forced by compiler.
        jasode 10y ago
        Look at the common theme among your suggestions: - do not use builtin operators in C for that, - instead create new functions, e.g. addMeters() - hide the int in *.c file Those are "best practices" instead of compiler-enforced type-check errors. Likewise, suggesting a best practice such as "don't free() memory twice" is not the same as a GC-language (Lisp/Java/C#/Go) freeing memory on the programmer's behalf or a static-ownership checker (Rust) preventing a programmer from making that mistake.
    - JoachimSchipper 10y ago
      Yes, although you should probably do struct value_in_meters { int in_meters; }, so that e.g. x.in_meters / y.in_inches (will compile, but) looks as wrong as it is.
- muraiki 10y ago
  F# supports units of measure: https://fsharpforfunandprofit.com/posts/units-of-measure/ https://fsharpforfunandprofit.com/posts/units-of-measure/
  - mikulas_florek 10y ago
    That looks useful. I do not know F#, but can't you still use ordinary float and have the same bug?
    - kazagistar 10y ago
      Sure, unit wrappers are much more like "memory safety checks" in C, in that they are incomplete and can be bypassed. In that sense, the war against raw types is necessarily a cultural one.
buserror 10y ago
No amount of 'type safety' will prevent idiots from being idiots, and with all the other languages, the problem is very often sitting on the chair. People will screw up creatively in any language, and trying to 'hide' that behind a language runtime overhead is idiotic. The good thing with C is that it will catch the worst idiots quickly, so you know not to hire them to write avionics for you. What is NOT idiotic iswhat you discribe as 'ridiculous amount of verification' as it's often the only thing that will really work to catch mistakes.
- fiedzia 10y ago
  > No amount of 'type safety' will prevent idiots from being idiots But it will limit the damage they do considerably. Having bit of space or trees between lanes on a road saves a lot of lives, even if people drive as idiotically as they would without it. > What is NOT idiotic is what you discribe as 'ridiculous amount of verification' Designing systems that rely only on that is idiotic when there are better options.
zuzun 10y ago
> We have lost Mars climate orbiter due to not using type-safe language. One company creates a closed-source component that produces a float, another company creates a closed-source component that receives a float. Units differ. Crash. No type-safe language will prevent that bug from happening. Let 100 programmers write these programs in your type-safe language of choice and all will be vulnerable to this. "Oh no", I hear you say, "we'll give every unit its own type" and it still won't stop your programmers from deserializing a 4 byte value in English units into the metric value they think it is. "So we'll make all the IO typed as well!" You don't need a type safe language to do that. And why would you do it in the first place? If your API spec says you receive a float in metric units, you write your program accordingly. When you're writing mission critical software, would you really want to replace a > read(sensor, &value, sizeof(float)) with 100k lines of even buggier code to prevent a bug from happening that shouldn't happen in the first place?
- fiedzia 10y ago
  > Let 100 programmers write these programs in your type-safe language of choice and all will be vulnerable to this. Some will be, some will define inteface as float_meters and define automatic conversion from yards, avoiding whole issue.
- lkitching 10y ago
  All bugs "shouldn't happen in the first place", the use of types is to reduce the surface area for where errors can be introduced. If you read some value from an external source and subsequently use measure types then you've isolated the scope for the introduction of errors to the read function instead of every location in the program that uses the value.
deleted 10y ago
[deleted]

throwaway9475 10y ago

I do. We have compilers that can verify seemingly perfectly (as far as we can tell) that a program won't do something silly like reference memory it doesn't own or try to use memory after freeing it (and not just languages like Rust, but any language that doesn't make you allocate and free memory). The best C programmer out there will still make mistakes because it's simply impossible to ensure that large programs won't do something they shouldn't. It boggles my mind that programmers seem to love better tooling and better abstractions, but when it comes to a certain class of languages, everything stopped improving in the 1970s with the PDP-11 and we just can't get past it.