6 ms·

> I have to say that I find Rust just as ugly and cumbersome as C++ Ok, so you don't like it aesthetically. Do you have problems writing unmaintainable softwar

> I have to say that I find Rust just as ugly and cumbersome as C++ Ok, so you don't like it aesthetically. Do you have problems writing unmaintainable software in it? What about incorrect software? Is there any specific feature in the language that you object to that will cause confusion and lead to people writing bugs? C is a very beautiful and "simple" language, people also write a lot of security vulnerabilities with it. Beauty is a useless concept in a programing language. Most of the time it just relates to someone's bias towards what they are familiar with. A lot of people find Python "beautiful", I'm unfortunately very familiar with python and as I've become more and more familiar with it I find it uglier and uglier. Same with C, I remember all the many hours I've spent in valgrind debugging problems other people have made for me and I find it ugly too. When I look at a programming language, I don't think about aesthetic "beauty" or even "simplicity". I think, does this programming language allow me to represent the concepts I want to represent accurately and correctly? 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. Edit: I want to add, it's not just accuracy and correctness that are important. Performance is very important too and many functional languages absolutely flounder because of strict immutability and the adoption of patterns that have terrible memory access patterns.

jackmott42 3y ago
It isn't a question of aesthetics, the primary pragmatic issue with languages that have many features is how hard it can be to read a new code base. Tools like macros and traits can save you a lot of typing but when someone else comes into your code, it is much harder to come to terms with it than simpler languages like C or Go where the set of features can all be held in your head and the actual code is explicitly stated rather than generated by macros and generics and such. This is a natural tradeoff in language design, do you deal with verbosity and boilerplate because the language has few features, or do you deal with the cognitive overhead of understanding all the features?
- brigadier132 3y ago
  I find Rust extremely easy to read. In comparison, I was trying to read a Go codebase and found it hard to read. Of course, I've spent multiple years writing Rust and almost no time writing Go and I don't know the Go programming language at all. It was very easy to "learn" of course. But I didn't actually learn it given when I started reading code bases I was interested in I started to see weird things like `var _ litestream.ReplicaClient = (*ReplicaClient)(nil)` which I couldn't find an explanation for using normal means so I asked chatgpt and it told me it's an "interface compliance check" "This line is a way of ensuring that a certain type (*ReplicaClient) implements a certain interface (litestream.ReplicaClient)." For some reason this pattern was left out of the official documentation. Am I missing other patterns? I find Traits much easier to understand. Also, like many others I give coding interviews and people writing Go always seem to run into null pointer errors. I'm not making that up. (I have no sample for Rust programmers)
- littlestymaar 3y ago
  But when all the features of the language fit in your head, it usually means the code you're reading keep repeating itself lacking more convenient features (yes Go, I'm talking about your error handling). The needs of our programs are complex, so in the end this complexity has to be somewhere, and it is either in the language itself, or in our code…
- balder1991 3y ago
  I think there’s this concept in language theory that those speaking or writing strive for more complex concepts as it matches better their thoughts, while those receiving strive for more simplicity as it takes more energy to make sense of complex concepts (think about it as adapting the language to your audience). But I think the main problem here is the famous debate of statically-typed languages vs dynamic ones. As statically-typed languages add more and more features to be more expressive, they have to work around the compiler limitations and create very bizarre syntaxes if they want to keep performance. But maybe this is a tooling problem? What if we could see the code in a simpler way even if the actual code involves macros and templates? Swift has just implemented macros that Xcode expand to show the generated code in a collapse/expand way, making it easy to understand what it does.
softirq 3y ago
> 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.

jackmott42 3y ago

It isn't a question of aesthetics, the primary pragmatic issue with languages that have many features is how hard it can be to read a new code base. Tools like macros and traits can save you a lot of typing but when someone else comes into your code, it is much harder to come to terms with it than simpler languages like C or Go where the set of features can all be held in your head and the actual code is explicitly stated rather than generated by macros and generics and such. This is a natural tradeoff in language design, do you deal with verbosity and boilerplate because the language has few features, or do you deal with the cognitive overhead of understanding all the features?

brigadier132 3y ago
I find Rust extremely easy to read. In comparison, I was trying to read a Go codebase and found it hard to read. Of course, I've spent multiple years writing Rust and almost no time writing Go and I don't know the Go programming language at all. It was very easy to "learn" of course. But I didn't actually learn it given when I started reading code bases I was interested in I started to see weird things like `var _ litestream.ReplicaClient = (*ReplicaClient)(nil)` which I couldn't find an explanation for using normal means so I asked chatgpt and it told me it's an "interface compliance check" "This line is a way of ensuring that a certain type (*ReplicaClient) implements a certain interface (litestream.ReplicaClient)." For some reason this pattern was left out of the official documentation. Am I missing other patterns? I find Traits much easier to understand. Also, like many others I give coding interviews and people writing Go always seem to run into null pointer errors. I'm not making that up. (I have no sample for Rust programmers)
littlestymaar 3y ago
But when all the features of the language fit in your head, it usually means the code you're reading keep repeating itself lacking more convenient features (yes Go, I'm talking about your error handling). The needs of our programs are complex, so in the end this complexity has to be somewhere, and it is either in the language itself, or in our code…
balder1991 3y ago
I think there’s this concept in language theory that those speaking or writing strive for more complex concepts as it matches better their thoughts, while those receiving strive for more simplicity as it takes more energy to make sense of complex concepts (think about it as adapting the language to your audience). But I think the main problem here is the famous debate of statically-typed languages vs dynamic ones. As statically-typed languages add more and more features to be more expressive, they have to work around the compiler limitations and create very bizarre syntaxes if they want to keep performance. But maybe this is a tooling problem? What if we could see the code in a simpler way even if the actual code involves macros and templates? Swift has just implemented macros that Xcode expand to show the generated code in a collapse/expand way, making it easy to understand what it does.

softirq 3y ago

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