4 ms·

> Beauty is a useless concept in a programing language. Maybe not aesthetic beauty, but readability in many contexts matters more than performance. Code that i

> Beauty is a useless concept in a programing language. Maybe not aesthetic beauty, but readability in many contexts matters more than performance. Code that isn't readable hides bugs and can't be maintained (FYI Rust doesn't stop you from writing bugs into your code). A language like C or Go where you can fit most of the syntax and mechanisms into your head are simply easier to read and reason about than a language where you need a PhD in type theory to understand one signature. > If it is not memory safe, does not support static typing with algebraic data types, and does not have null safety it does not meet those minimum requirements and is not suitable for use. You'd better stop interacting with technology then, because the vast majority of it is still running something compiled from C. We're talking about control systems, life saving technology, technology that's running in outer space.

brigadier132 3y ago
> Rust doesn't stop you from writing bugs into your code Obviously. It's not about Rust specifically. It's about accurately representing state which is extremely difficult to do in programming languages that do not have algebraic data types. In Golang how do I represent that a type is either type A or type B and then in a type safe way perform logic if it's type A or perform logic if it's type B? Algebraic data types also allow for things like the result and option type. Throw in the borrow checker which prevents a host of aliasing and concurrency bugs (not all). You are more likely to write correct Rust than other languages. > You'd better stop interacting with technology then, because the vast majority of it is still running something compiled from C. Thank you for another lesson I already know. I clearly meant I don't think it's suitable for use in new programs. People will still use it regardless as they are free to do so.
- preseinger 3y ago
  > In Golang how do I represent that a type is either type A or type B generics provide one approach to this, but, in general, you don't -- you find another solution to your problem
- softirq 3y ago
  > extremely difficult to do in programming languages that do not have algebraic data types. And this is why people like me avoid ML based languages, type astronauts, and shiny new toys. You're misrepresenting inconveniences as fatal flaws when we've been successfully running all of modern society on kernels written in C for fifty years. Most of the kernel subsystem maintainers aren't even considering Rust as anything more than an experiment at this point. No one cares about ADTs and the perfect representation of state transitions in the type system when we have actual problems to solve, and we can and have been solving them in C.
  - brigadier132 3y ago
    > And this is why people like me avoid ML based languages, type astronauts, and shiny new toys Instead you get things like this in GO `var _ litestream.ReplicaClient = (*ReplicaClient)(nil)` And every single variable is implicitly Type or null because obviously the alternative is more complex
  - biorach 3y ago
    > And this is why people like me avoid ML based languages, type astronauts, and shiny new toys. There's nothing new or shiny about the ML family. And the growing interest in ADT's is about their very real advantages in representing state and solving real problems in a less error prone manner than C
    - vpastore 3y ago
      Don’t argue with him. He is just and old man doing what all old man do: find excuses to not learn new stuff and convince himself that he didn’t have to do it
      - dcow 3y ago
        Yeah I find it really hard to see how they're being charitable. Just an old fart arguing for the continued relevance of curmudgeon-y technology instead of actually responding to the points being argued. What people who still care about writing C are doing is starting to use tools to bring some of what Rust offers to C, because they acknowledge that avoiding entire categories of bugs is actually really good, despite which language you use. But... no mention of that here, it seems.
satvikpendem 3y ago
> FYI Rust doesn't stop you from writing bugs into your code You are committing the perfect solution fallacy [0]. Rust won't make you have no bugs in your code but don't conflate some number of bugs with a reduced number of bugs, a reduction is still a meaningful outcome, otherwise we'd still be writing in assembly. > We're talking about control systems, life saving technology, technology that's running in outer space. Indeed, that's why we should use more memory safe languages, because we are dealing with critical systems. Just because they were written in C does not mean that they should continue to be. It's like digging a hole with a stick, and when someone suggests a shovel or backhoe, you mention that all previous holes were made with a stick. There is no relationship between the previous work and what should be done in the future. [0] https://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solution_fallacy https://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_soluti...
- softirq 3y ago
  > You are committing the perfect solution fallacy. Rust is also not a perfect solution. You have to prove that the benefits of solving for the bugs Rust can prevent outweighs the downsides of asking a bunch of C experts who are currently developing kernel subsystems in C to stop what they are doing and rewrite millions of lines in C in a language that has very low marketshare in the space and is far, far more complex in terms of abstracting over assembly. People write systems software in C not because they have a fetish for bugs, but because we do in fact still have to stay close to the hardware and not get lost in a minefield of abstractions.
  - satvikpendem 3y ago
    > Rust is also not a perfect solution. Yes? That's explicitly what I said. C is successful despite all the bugs, not because of it. If there are newer methodologies that solve bugs, one should use them, rather than sticking to their "tried and true way" while suffering through segmentation faults. Already parts of the Linux kernel as well as Windows are being written in Rust, so if it's good enough for them, it should be good enough for those bunch of C experts. They also don't have to rewrite millions of lines, they can incrementally improve the codebase. All this to say that even in your above comment you're still committing the perfect solution fallacy. You are still talking about how Rust is not perfect even though no one said it was, and you mention trying to convince all of those C experts to rewrite millions of lines of code when, again, no one said they have to do.
golergka 3y ago
> readability in many contexts matters more than performance I completely, whole heartedly agree. Not just in many, but in most contexts. And Rust or C shouldn't be used in these contexts. Use typescript or python instead.
plandis 3y ago
C is not what I would call a very readable language. I don’t think you could drop someone who newly learned C and have them be effective looking at glibc for example.
- queuebert 3y ago
  Because of the use or abuse of macros, different C codebases can look very different, and to learn it you have to figure out all the quirky macros. If people stick to standard C with few macros and verbose variable names, it's really not bad.
  - duped 3y ago
    void* (*identifier) (void*); typedef struct { /* ... */ } my_struct_t; static return_type name_of_function (type *restrict argument) { int a, b, c; /* body */ } Just some examples of illegible syntax that's "standard" C. C is not a pretty language. It's small, but it's ugly as sin.
    - dcow 3y ago
      It's nearly impossible to actually parse anything more complex than a pointer to a struct in C because it wasn't written for humans, it is a relic of using a convenient recursive descent parser to parse C's syntax that we end up with `void* (*id) (void*)`...
shpongled 3y ago
Readability is a function of familiarity though. I have been programming in Rust for > 5 years, I find it to be an incredibly readable language, because I am so familiar with it.
Certhas 3y ago
Are you familiar with the lengths people go to to make C work in the "life saving technology" contexts? Your argument is essentially: My thinking is clear and correct, I just can't explain to the compiler why it's correct, so just trust me. People _very_ easily delude themselves into thinking their thinking is clear. When they are forced to spell it out in excruciating detail it often turns out otherwise.

brigadier132 3y ago

> Rust doesn't stop you from writing bugs into your code Obviously. It's not about Rust specifically. It's about accurately representing state which is extremely difficult to do in programming languages that do not have algebraic data types. In Golang how do I represent that a type is either type A or type B and then in a type safe way perform logic if it's type A or perform logic if it's type B? Algebraic data types also allow for things like the result and option type. Throw in the borrow checker which prevents a host of aliasing and concurrency bugs (not all). You are more likely to write correct Rust than other languages. > You'd better stop interacting with technology then, because the vast majority of it is still running something compiled from C. Thank you for another lesson I already know. I clearly meant I don't think it's suitable for use in new programs. People will still use it regardless as they are free to do so.

preseinger 3y ago
> In Golang how do I represent that a type is either type A or type B generics provide one approach to this, but, in general, you don't -- you find another solution to your problem
softirq 3y ago
> extremely difficult to do in programming languages that do not have algebraic data types. And this is why people like me avoid ML based languages, type astronauts, and shiny new toys. You're misrepresenting inconveniences as fatal flaws when we've been successfully running all of modern society on kernels written in C for fifty years. Most of the kernel subsystem maintainers aren't even considering Rust as anything more than an experiment at this point. No one cares about ADTs and the perfect representation of state transitions in the type system when we have actual problems to solve, and we can and have been solving them in C.
- brigadier132 3y ago
  > And this is why people like me avoid ML based languages, type astronauts, and shiny new toys Instead you get things like this in GO `var _ litestream.ReplicaClient = (*ReplicaClient)(nil)` And every single variable is implicitly Type or null because obviously the alternative is more complex
- biorach 3y ago
  > And this is why people like me avoid ML based languages, type astronauts, and shiny new toys. There's nothing new or shiny about the ML family. And the growing interest in ADT's is about their very real advantages in representing state and solving real problems in a less error prone manner than C
  - vpastore 3y ago
    Don’t argue with him. He is just and old man doing what all old man do: find excuses to not learn new stuff and convince himself that he didn’t have to do it
    - dcow 3y ago
      Yeah I find it really hard to see how they're being charitable. Just an old fart arguing for the continued relevance of curmudgeon-y technology instead of actually responding to the points being argued. What people who still care about writing C are doing is starting to use tools to bring some of what Rust offers to C, because they acknowledge that avoiding entire categories of bugs is actually really good, despite which language you use. But... no mention of that here, it seems.

satvikpendem 3y ago

> FYI Rust doesn't stop you from writing bugs into your code You are committing the perfect solution fallacy [0]. Rust won't make you have no bugs in your code but don't conflate some number of bugs with a reduced number of bugs, a reduction is still a meaningful outcome, otherwise we'd still be writing in assembly. > We're talking about control systems, life saving technology, technology that's running in outer space. Indeed, that's why we should use more memory safe languages, because we are dealing with critical systems. Just because they were written in C does not mean that they should continue to be. It's like digging a hole with a stick, and when someone suggests a shovel or backhoe, you mention that all previous holes were made with a stick. There is no relationship between the previous work and what should be done in the future. [0] https://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solution_fallacy https://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_soluti...

softirq 3y ago
> You are committing the perfect solution fallacy. Rust is also not a perfect solution. You have to prove that the benefits of solving for the bugs Rust can prevent outweighs the downsides of asking a bunch of C experts who are currently developing kernel subsystems in C to stop what they are doing and rewrite millions of lines in C in a language that has very low marketshare in the space and is far, far more complex in terms of abstracting over assembly. People write systems software in C not because they have a fetish for bugs, but because we do in fact still have to stay close to the hardware and not get lost in a minefield of abstractions.
- satvikpendem 3y ago
  > Rust is also not a perfect solution. Yes? That's explicitly what I said. C is successful despite all the bugs, not because of it. If there are newer methodologies that solve bugs, one should use them, rather than sticking to their "tried and true way" while suffering through segmentation faults. Already parts of the Linux kernel as well as Windows are being written in Rust, so if it's good enough for them, it should be good enough for those bunch of C experts. They also don't have to rewrite millions of lines, they can incrementally improve the codebase. All this to say that even in your above comment you're still committing the perfect solution fallacy. You are still talking about how Rust is not perfect even though no one said it was, and you mention trying to convince all of those C experts to rewrite millions of lines of code when, again, no one said they have to do.

golergka 3y ago

> readability in many contexts matters more than performance I completely, whole heartedly agree. Not just in many, but in most contexts. And Rust or C shouldn't be used in these contexts. Use typescript or python instead.

plandis 3y ago

C is not what I would call a very readable language. I don’t think you could drop someone who newly learned C and have them be effective looking at glibc for example.

queuebert 3y ago
Because of the use or abuse of macros, different C codebases can look very different, and to learn it you have to figure out all the quirky macros. If people stick to standard C with few macros and verbose variable names, it's really not bad.
- duped 3y ago
  void* (*identifier) (void*); typedef struct { /* ... */ } my_struct_t; static return_type name_of_function (type *restrict argument) { int a, b, c; /* body */ } Just some examples of illegible syntax that's "standard" C. C is not a pretty language. It's small, but it's ugly as sin.
  - dcow 3y ago
    It's nearly impossible to actually parse anything more complex than a pointer to a struct in C because it wasn't written for humans, it is a relic of using a convenient recursive descent parser to parse C's syntax that we end up with `void* (*id) (void*)`...

shpongled 3y ago

Readability is a function of familiarity though. I have been programming in Rust for > 5 years, I find it to be an incredibly readable language, because I am so familiar with it.

Certhas 3y ago

Are you familiar with the lengths people go to to make C work in the "life saving technology" contexts? Your argument is essentially: My thinking is clear and correct, I just can't explain to the compiler why it's correct, so just trust me. People _very_ easily delude themselves into thinking their thinking is clear. When they are forced to spell it out in excruciating detail it often turns out otherwise.