4 ms·

I've seen as many of the tech geek stereotype where there's some level of masochistic appeal of C (especially C89) to them where "if it's hard and some people c

by Macha 4y ago

I've seen as many of the tech geek stereotype where there's some level of masochistic appeal of C (especially C89) to them where "if it's hard and some people can't do it, then clearly it must be good and only for the best". Especially among hobbyists who've never had to maintain a production codebase or deal with changing user needs.

mlindner 4y ago
Indeed, the changing user needs aspect is inevitably the cause of so many memory corruption issues when old code, that's only really understood by that one or two grey beard still at the company and about to retire (or have already retired), needs to be changed. The change is put in and everything looks fine and then it's given to the customer who eventually complains of rare crashes on their previously-working-just-fine hardware. (Oh and you don't find out about the crashes until almost a year later given the long release cycle so have long forgotten what you did a year ago.) Inevitably it's used as an avenue for the sales engineers to upsell the customer on new hardware claiming their hardware is out of date. The software engineers all know this is a white lie given that the same software runs on both pieces of hardware and the hardware didn't actually change much. It just ruins you over time and makes you wish you never had to work in this business.
zozbot234 4y ago
It's a bit ironic because Rust is also hard, but in a totally different way than C89 is hard. For instance, plenty of novice devs got started with C89 (or even C++) as their first "serious" programming language, but we're not even sure how Rust could be adapted to fit the same role. (Probably it would involve teaching the basics of Rust as if it was a quasi-Haskell, or at least a deeply weird ML. So quite different from how C89 is taught!)
- allisdust 4y ago
  On the contrary, I feel rust could be a great language for students because the borrow checker will slap sense into them from early on and each error it throws teaches them a little more on memory, data safety.
  - nneonneo 4y ago
    I already teach borrowing and ownership semantics as ways to avoid memory issues in C. While Rust is a more complex language on the whole, the fundamentals of borrowing and ownership are more broadly applicable concepts.
  - nyanpasu64 4y ago
    Being allowed to mutate an integer (or object) through two different pointers on the same thread is perfectly safe and even useful (in the general case, for non-tree-shaped problems) on a CPU. Rust adds unpleasant syntax to achieve it through Cell, unpleasant syntax and undefined behavior footguns to do it through raw pointers, and guaranteed undefined behavior to do it through aliasing &mut, so I no longer treat Rust as a general-purpose programming language. And when teaching beginners, this would give the incorrect impression that it's somehow undefined behavior to access memory through multiple pointers on the same thread (rather than merely a tradeoff which increases code flexibility at the cost of local reasoning). And on a more personal level, I dislike the Rust community (and language, eg. for loops depend on trait resolution)'s heavy use of functional, generic, and higher-order function abstractions (rather than explicit imperative code amenable to sequential reasoning). I feel heavy use of generics is confusing in a language used to teach programming to students (and I think usefully learning mainstream programming revolves around algorithmic reasoning from the level of memory and bytes through structured programming, rather than pure functions and iterator combinators).
    - zozbot234 4y ago
      > Being allowed to mutate an integer (or object) through two different pointers on the same thread is perfectly safe Not safe in the presence of variant records (i.e. enums in Rust), since one pointer might be used to derive a pointer to a field of one variant, and the object might concurrently be switched to a different variant. This is why Cell<> only relies on explicit get and set methods in the general case, where the entire object gets replaced. It's a well-known problem in temporal safety.
      - nyanpasu64 4y ago

by Macha 4y ago

mlindner 4y ago

Indeed, the changing user needs aspect is inevitably the cause of so many memory corruption issues when old code, that's only really understood by that one or two grey beard still at the company and about to retire (or have already retired), needs to be changed. The change is put in and everything looks fine and then it's given to the customer who eventually complains of rare crashes on their previously-working-just-fine hardware. (Oh and you don't find out about the crashes until almost a year later given the long release cycle so have long forgotten what you did a year ago.) Inevitably it's used as an avenue for the sales engineers to upsell the customer on new hardware claiming their hardware is out of date. The software engineers all know this is a white lie given that the same software runs on both pieces of hardware and the hardware didn't actually change much. It just ruins you over time and makes you wish you never had to work in this business.

zozbot234 4y ago

It's a bit ironic because Rust is also hard, but in a totally different way than C89 is hard. For instance, plenty of novice devs got started with C89 (or even C++) as their first "serious" programming language, but we're not even sure how Rust could be adapted to fit the same role. (Probably it would involve teaching the basics of Rust as if it was a quasi-Haskell, or at least a deeply weird ML. So quite different from how C89 is taught!)

allisdust 4y ago
On the contrary, I feel rust could be a great language for students because the borrow checker will slap sense into them from early on and each error it throws teaches them a little more on memory, data safety.
- nneonneo 4y ago
  I already teach borrowing and ownership semantics as ways to avoid memory issues in C. While Rust is a more complex language on the whole, the fundamentals of borrowing and ownership are more broadly applicable concepts.
- nyanpasu64 4y ago
  Being allowed to mutate an integer (or object) through two different pointers on the same thread is perfectly safe and even useful (in the general case, for non-tree-shaped problems) on a CPU. Rust adds unpleasant syntax to achieve it through Cell, unpleasant syntax and undefined behavior footguns to do it through raw pointers, and guaranteed undefined behavior to do it through aliasing &mut, so I no longer treat Rust as a general-purpose programming language. And when teaching beginners, this would give the incorrect impression that it's somehow undefined behavior to access memory through multiple pointers on the same thread (rather than merely a tradeoff which increases code flexibility at the cost of local reasoning). And on a more personal level, I dislike the Rust community (and language, eg. for loops depend on trait resolution)'s heavy use of functional, generic, and higher-order function abstractions (rather than explicit imperative code amenable to sequential reasoning). I feel heavy use of generics is confusing in a language used to teach programming to students (and I think usefully learning mainstream programming revolves around algorithmic reasoning from the level of memory and bytes through structured programming, rather than pure functions and iterator combinators).
  - zozbot234 4y ago
    > Being allowed to mutate an integer (or object) through two different pointers on the same thread is perfectly safe Not safe in the presence of variant records (i.e. enums in Rust), since one pointer might be used to derive a pointer to a field of one variant, and the object might concurrently be switched to a different variant. This is why Cell<> only relies on explicit get and set methods in the general case, where the entire object gets replaced. It's a well-known problem in temporal safety.
    - nyanpasu64 4y ago