7 ms·

After writing primarily no standard library C for 15 years, I have to say that I find Rust just as ugly and cumbersome as C++ (not debating its safety guarantee

After writing primarily no standard library C for 15 years, I have to say that I find Rust just as ugly and cumbersome as C++ (not debating its safety guarantees). It seems like languages that add sufficiently advanced type/macros systems always spiral into unwieldy beasts where you spend a bunch of your time arguing with the type systems and writing blog posts about some new piece of type theory to solve a problem you would have never have had with C. People just get greedier with deriving code and wanting more "magic" until every program only makes sense to its author. I don't think I will ever like kitchen sink languages. Experience has taught me that the most effective tool is the simplest one, which for most use cases today would be Go. For systems programming I just shudder to think how convoluted and hard to read things will become when we take already extremely complex code written in the simplest terms in C and port it to Rust.

cumshitpiss 3y ago
[dead]
rascul 3y ago
> I don't think I will ever like kitchen sink languages. What makes a kitchen sink language?
- matthewaveryusa 3y ago
  I would describe it as a language where there is more than one strong idiom For C and Go, there really is only one prevailing idiom on how to write code (for C one could argue that static vs. dynamic allocation are two idioms, and multiple ways of doing concurrency) For C++, whenever you have the chance to abstract some code into an interface you'll have the choice to create a template or use polymorphism, concurrency can now be done with an event loop, co-routines, threads... Rust has the same bug/feature where there's more than one idiomatic way of doing things.
  - Capricorn2481 3y ago
    I feel like people have been saying this about Go for a while and I don't see how it's true. The only real idioms out of Go are explicit error handling, types implementing interfaces, and the formatter. Otherwise, you can kinda do whatever you want in Go, and I have yet to feel at home reading a Go codebase.
  - rascul 3y ago
    Thank you for the explanation.
  - bluejekyll 3y ago
    “For C…, there really is only one prevailing idiom on how to write code” You can look at single projects that have changed the way they write C code over time, introducing new idioms all the time. OpenSSL is a perfect example of that in regards to their work to reduce memory related bugs. C’s idioms have changed so many times over it’s life it’s hard to keep track or even read it from one era to the next.
  - madmoose 3y ago
    > For C and Go, there really is only one prevailing idiom on how to write code What’s the one idiomatic idiom in C for a growable list of items? Because I must have a seen a hundred of those in my time. What’s the one idiomatic idiom in C for a hashmap? I’ve seen about a hundred of those too.
    - throwaway17_17 3y ago
      I would think you are referring to implementations of the one prevailing idiom as opposed to seeing multiple idioms for the concept. The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it.
      - madmoose 3y ago
        Of course I'm talking about an idiomatic implementation, what else would I be talking about in this context? > The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it. That sounds like a long-winded way to say "there's no one idiomatic growable list in C".
wg0 3y ago
Point of higher level languages is and was productivity. Now some languages have Turing complete type systems and I have seen some clever usage of types where really even the author might not know how it works given enough time passes without touching the code base.
brigadier132 3y ago
> 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)
gnuvince 3y ago
Bravo!
avgcorrection 3y ago
> After writing primarily no standard library C for 15 years, I have to say that I find Rust just as ugly and cumbersome as C++ (not debating its safety guarantees). The safety guarantees are the whole point compared to C. So what’s the point of complaining about how things are cumbersome when you just elide that whole side of the debate? I could complain about how C is too cumbersome with the proviso that I don’t care about portability or efficiency. But then what would the point be?
Weebs 3y ago
There's definitely tradeoffs to some things, and I think in particular Rust's static guarantees can cause additional friction, but in general I've found ML derived languages to be extremely practical because it's a good local maximum on the graph in terms of complexity vs runtime safety (where languages like Java add too much friction without enough benefit compared to something like Python) I've found in software development the 80/20 rule is extremely true, but when you need something from that last 20%, it can really mess up your architecture trying to work around it. To me this is why others love LISP so much, and I appreciate F#/OCaml for getting me as close to that potential as possible while keeping static analysis reasonable. Clever use of type systems is great for RAD and making sure critical components make certain classes of bugs a compile time error, and it can turn into undecipherable magic, but the additional information and guarantees advanced type systems provide allow me to focus on my immediate problem instead of the interplay with a larger system.
PartiallyTyped 3y ago
> where you spend a bunch of your time arguing with the type systems That’s the point. It’s a feature, not a bug. The type system exists to reduce the space of unsound programs. The trade off is dev time for runtime errors.

cumshitpiss 3y ago

[dead]

rascul 3y ago

> I don't think I will ever like kitchen sink languages. What makes a kitchen sink language?

matthewaveryusa 3y ago
I would describe it as a language where there is more than one strong idiom For C and Go, there really is only one prevailing idiom on how to write code (for C one could argue that static vs. dynamic allocation are two idioms, and multiple ways of doing concurrency) For C++, whenever you have the chance to abstract some code into an interface you'll have the choice to create a template or use polymorphism, concurrency can now be done with an event loop, co-routines, threads... Rust has the same bug/feature where there's more than one idiomatic way of doing things.
- Capricorn2481 3y ago
  I feel like people have been saying this about Go for a while and I don't see how it's true. The only real idioms out of Go are explicit error handling, types implementing interfaces, and the formatter. Otherwise, you can kinda do whatever you want in Go, and I have yet to feel at home reading a Go codebase.
- rascul 3y ago
  Thank you for the explanation.
- bluejekyll 3y ago
  “For C…, there really is only one prevailing idiom on how to write code” You can look at single projects that have changed the way they write C code over time, introducing new idioms all the time. OpenSSL is a perfect example of that in regards to their work to reduce memory related bugs. C’s idioms have changed so many times over it’s life it’s hard to keep track or even read it from one era to the next.
- madmoose 3y ago
  > For C and Go, there really is only one prevailing idiom on how to write code What’s the one idiomatic idiom in C for a growable list of items? Because I must have a seen a hundred of those in my time. What’s the one idiomatic idiom in C for a hashmap? I’ve seen about a hundred of those too.
  - throwaway17_17 3y ago
    I would think you are referring to implementations of the one prevailing idiom as opposed to seeing multiple idioms for the concept. The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it.
    - madmoose 3y ago
      Of course I'm talking about an idiomatic implementation, what else would I be talking about in this context? > The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it. That sounds like a long-winded way to say "there's no one idiomatic growable list in C".

wg0 3y ago

Point of higher level languages is and was productivity. Now some languages have Turing complete type systems and I have seen some clever usage of types where really even the author might not know how it works given enough time passes without touching the code base.

brigadier132 3y ago

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

gnuvince 3y ago

Bravo!

avgcorrection 3y ago

> After writing primarily no standard library C for 15 years, I have to say that I find Rust just as ugly and cumbersome as C++ (not debating its safety guarantees). The safety guarantees are the whole point compared to C. So what’s the point of complaining about how things are cumbersome when you just elide that whole side of the debate? I could complain about how C is too cumbersome with the proviso that I don’t care about portability or efficiency. But then what would the point be?

Weebs 3y ago

There's definitely tradeoffs to some things, and I think in particular Rust's static guarantees can cause additional friction, but in general I've found ML derived languages to be extremely practical because it's a good local maximum on the graph in terms of complexity vs runtime safety (where languages like Java add too much friction without enough benefit compared to something like Python) I've found in software development the 80/20 rule is extremely true, but when you need something from that last 20%, it can really mess up your architecture trying to work around it. To me this is why others love LISP so much, and I appreciate F#/OCaml for getting me as close to that potential as possible while keeping static analysis reasonable. Clever use of type systems is great for RAD and making sure critical components make certain classes of bugs a compile time error, and it can turn into undecipherable magic, but the additional information and guarantees advanced type systems provide allow me to focus on my immediate problem instead of the interplay with a larger system.

PartiallyTyped 3y ago

> where you spend a bunch of your time arguing with the type systems That’s the point. It’s a feature, not a bug. The type system exists to reduce the space of unsound programs. The trade off is dev time for runtime errors.