6 ms·

Rust's type system is complicated for a reason. It makes explicit the reasoning that is necessary to allocate and access memory correctly without reference coun

Rust's type system is complicated for a reason. It makes explicit the reasoning that is necessary to allocate and access memory correctly without reference counting or garbage collection. Sure it is easier to start writing C but I believe it is overall faster to write and debug a Rust program because C requires additional sanitization and fuzzing to catch errors. To quote Grissom from CSI: I've learned that sometimes you can go faster by going slow ;-)

msie 6y ago
I don’t know. Rust has all these high level features that also contribute to it’s complexity too. Strip those out and you may have a simpler language.
hvasilev 6y ago
I think this profession is hard enough as it is. I don't think you need another daily source of annoyance like reading code with a difficult syntax or fighting meaninglessly with the borrow checker. I understand the motivations for this language, but I don't like the tradeoffs on a personal level. Definitely not my cup of tea.
- aldanor 6y ago
  You don't "fight the borrow checker" after a while; rather, you enjoy the fact that it exists. "Difficult syntax" becomes enjoyable as well, and it's all subjective. > I think this profession is hard enough as it is. Exactly, I think so too. Don't think I need another source of annoyance like spending days on digging at obscure segfaults and data races caused by logical mutability mistakes.
- danieldk 6y ago
  But you don’t fight meaninglessly with the borrows checker. For me, this was only the first few weeks. Once you know the (simple) borrowing rules, it is rarely a problem anymore. It only rears its head every now and then when you know something is valid, but the borrows checker is not able to infer it. Another dimension to it is that the borrows checker rules also apply in most other languages if you want to write valid code. They are just not enforced and you have to rely on your own discipline instead (which humans are bad at).
- zozbot234 6y ago
  Memory safety errors are a far bigger "annoyance" to the profession than dealing with a slightly more complex (but still quite elegant) syntax or understanding borrowck diagnostics ("fighting with the borrow checker"). It's not even close. The problem with unsafe programming in the traditional C style (with its heavy reliance on shared, mutable, possibly aliased pointers) is that it's inherently non-compositional: proving safety or correctness of such a piece of code is a 'global' problem that cannot be meaningfully decomposed or modularized. That's why Rust's choice of explicitly restricting these features to "unsafe" blocks feels intuitively right - the "safe" part of Rust is essentially the part that can be worked with in a highly modular way, where safety is checked 'locally' via a type system. Future versions of Rust may well make some currently-unsafe features slightly easier to use, perhaps even more idiomatic in a way that might appeal to C developers, but some inherent constraints will remain.
  - sai_c 6y ago
    I think (for this discussion) we should have a more clear definition of embedded. Yes, ARM processors are used more and more, but there are really A LOT of embedded systems out there, which are still, for example, 8 bit. As an embedded dev, who is using pretty much everything from 8 to 64 bit, the kind of memory safety errors you talk about I have yet to see with on anything based on (say) a 8051 or PIC. On a system without OS and without dynamic memory allocation, the borrow checker does not buy you much. It's a different story with an ARM processor and an OS (real-time or not does not matter). Of course Rust has a more powerful type system, but my experience is, that the preferences for a C type type system dominate the embedded world. Not because it is better or simpler, but because most embedded devs actually like low level. They are simply not interested in type driven development (yes it's just their personal taste) and its benefits. Or let me say it like this. I see two kinds of embedded devs: - Those who abstract way the problem ("It's all just a big char array.", "It's all just ints.", "It's all just data structures"). - Those who abstract away the machine ("It's all just objects.", "It's all just types."). Right now, my observations tell me that the first group is still dominating. Time will tell if this is going to change.
    - SAI_Peregrinus 6y ago
- aplanas 6y ago
  I think that this is a fair argument. When the mental model is already there, changing it is difficult and the trade-offs needs to be in a very advantage position to justify the change. But over the time this argument loose fairness in some direction. Today, in 2020, I would feel awful if in my meetings I argued that creating unit tests is meaningless, as this will point bugs in my code that I need to fight with. Or that QA is a bunch of mean people that do not understand how to use my library and only want to point to "bugs" that is more work to me to "fix". IMHO the borrow checker _is_ this test that I do not want to write, or this QA engineer that exercise the code to find a corner case when I am causing a memory corruption in my not-perfect work.
- baq 6y ago
  it helps you by pointing out potential issues and challenges you to really understand what's going on instead of just winging it. how is that meaningless is beyond me. i understand moving fast and breaking things is how many things get done, but it doesn't have to be like that.
- valand 6y ago
  > difficult syntax My approach of learning any language with "difficult syntax" is to treat those as language features rather than a burden. It is the language bridging the coder to the complexity under the hood (the computer). This comes from Rust's nature of being a low-level PL, and it is really awesome to be able to abstract those minute details so that one can write Rust and "look, it's not that different from JavaScript" Another analogy would be `gerund` in English. English has the `gerund` feature for its speakers to nounify a verb. Other languages don't have that, some even use the same symbols for both the verb and the noun form. Both Rust's "difficult syntax" and English's gerund needs only one-time learning session. Once you're fluent on it the sentences come out on their own.
pjmlp 6y ago
Given that C++ has barely made a dent in some of those domains, after 40 years of trying, any Rust advocacy towards that target market can take a lesson or two from why those engineers are unwilling to move beyond C89 + OEM specific extensions.
- raxxorrax 6y ago
  The problem is that embedded systems today can range from a 1Mhz µC to a complete PC like a Raspberry Pie. While memory management is important for the latter, the former doesn't like any dynamically allocated memory at all. Also many processor manufacturers have hundreds of different models with similar but different port mappings. They often supply C-header files which helps making your software compatible with numerous different processor types. So even while Rust has a macro system, it would need to be adapted by those manufacturers or C will likely stay the more convenient choice for the time being.
- mlindner 6y ago
  Please tell me how I can shut off the heap and still use portions of the C++ standard library? You can do that with Rust. C++ just wasn't designed with embedded in mind.
  - pjmlp 6y ago
    Easy, by actually learning how pros do it. https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default.aspx https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default... https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf https://www.autosar.org/fileadmin/user_upload/standards/adap... https://en.cppreference.com/w/cpp/freestanding https://en.cppreference.com/w/cpp/freestanding Certifications that Rust has yet to achieve.
  - zozbot234 6y ago
    C++ has custom allocators and in-place object construction via placement new. That's even better support than current Rust, which is still limited to a single, global allocator for the entire program.
dustinmoris 6y ago
There’s that saying we have: I dress slowly because I’m in a rush.
sai_c 6y ago
Yeah, but I think there is another saying that is still true in 2020: "Time is money". ;-). Edit: Corrected typo.

msie 6y ago

I don’t know. Rust has all these high level features that also contribute to it’s complexity too. Strip those out and you may have a simpler language.

hvasilev 6y ago

I think this profession is hard enough as it is. I don't think you need another daily source of annoyance like reading code with a difficult syntax or fighting meaninglessly with the borrow checker. I understand the motivations for this language, but I don't like the tradeoffs on a personal level. Definitely not my cup of tea.

aldanor 6y ago
You don't "fight the borrow checker" after a while; rather, you enjoy the fact that it exists. "Difficult syntax" becomes enjoyable as well, and it's all subjective. > I think this profession is hard enough as it is. Exactly, I think so too. Don't think I need another source of annoyance like spending days on digging at obscure segfaults and data races caused by logical mutability mistakes.
danieldk 6y ago
But you don’t fight meaninglessly with the borrows checker. For me, this was only the first few weeks. Once you know the (simple) borrowing rules, it is rarely a problem anymore. It only rears its head every now and then when you know something is valid, but the borrows checker is not able to infer it. Another dimension to it is that the borrows checker rules also apply in most other languages if you want to write valid code. They are just not enforced and you have to rely on your own discipline instead (which humans are bad at).
zozbot234 6y ago
Memory safety errors are a far bigger "annoyance" to the profession than dealing with a slightly more complex (but still quite elegant) syntax or understanding borrowck diagnostics ("fighting with the borrow checker"). It's not even close. The problem with unsafe programming in the traditional C style (with its heavy reliance on shared, mutable, possibly aliased pointers) is that it's inherently non-compositional: proving safety or correctness of such a piece of code is a 'global' problem that cannot be meaningfully decomposed or modularized. That's why Rust's choice of explicitly restricting these features to "unsafe" blocks feels intuitively right - the "safe" part of Rust is essentially the part that can be worked with in a highly modular way, where safety is checked 'locally' via a type system. Future versions of Rust may well make some currently-unsafe features slightly easier to use, perhaps even more idiomatic in a way that might appeal to C developers, but some inherent constraints will remain.
- sai_c 6y ago
  I think (for this discussion) we should have a more clear definition of embedded. Yes, ARM processors are used more and more, but there are really A LOT of embedded systems out there, which are still, for example, 8 bit. As an embedded dev, who is using pretty much everything from 8 to 64 bit, the kind of memory safety errors you talk about I have yet to see with on anything based on (say) a 8051 or PIC. On a system without OS and without dynamic memory allocation, the borrow checker does not buy you much. It's a different story with an ARM processor and an OS (real-time or not does not matter). Of course Rust has a more powerful type system, but my experience is, that the preferences for a C type type system dominate the embedded world. Not because it is better or simpler, but because most embedded devs actually like low level. They are simply not interested in type driven development (yes it's just their personal taste) and its benefits. Or let me say it like this. I see two kinds of embedded devs: - Those who abstract way the problem ("It's all just a big char array.", "It's all just ints.", "It's all just data structures"). - Those who abstract away the machine ("It's all just objects.", "It's all just types."). Right now, my observations tell me that the first group is still dominating. Time will tell if this is going to change.
  - SAI_Peregrinus 6y ago
aplanas 6y ago
I think that this is a fair argument. When the mental model is already there, changing it is difficult and the trade-offs needs to be in a very advantage position to justify the change. But over the time this argument loose fairness in some direction. Today, in 2020, I would feel awful if in my meetings I argued that creating unit tests is meaningless, as this will point bugs in my code that I need to fight with. Or that QA is a bunch of mean people that do not understand how to use my library and only want to point to "bugs" that is more work to me to "fix". IMHO the borrow checker _is_ this test that I do not want to write, or this QA engineer that exercise the code to find a corner case when I am causing a memory corruption in my not-perfect work.
baq 6y ago
it helps you by pointing out potential issues and challenges you to really understand what's going on instead of just winging it. how is that meaningless is beyond me. i understand moving fast and breaking things is how many things get done, but it doesn't have to be like that.
valand 6y ago
> difficult syntax My approach of learning any language with "difficult syntax" is to treat those as language features rather than a burden. It is the language bridging the coder to the complexity under the hood (the computer). This comes from Rust's nature of being a low-level PL, and it is really awesome to be able to abstract those minute details so that one can write Rust and "look, it's not that different from JavaScript" Another analogy would be `gerund` in English. English has the `gerund` feature for its speakers to nounify a verb. Other languages don't have that, some even use the same symbols for both the verb and the noun form. Both Rust's "difficult syntax" and English's gerund needs only one-time learning session. Once you're fluent on it the sentences come out on their own.

pjmlp 6y ago

Given that C++ has barely made a dent in some of those domains, after 40 years of trying, any Rust advocacy towards that target market can take a lesson or two from why those engineers are unwilling to move beyond C89 + OEM specific extensions.

raxxorrax 6y ago
The problem is that embedded systems today can range from a 1Mhz µC to a complete PC like a Raspberry Pie. While memory management is important for the latter, the former doesn't like any dynamically allocated memory at all. Also many processor manufacturers have hundreds of different models with similar but different port mappings. They often supply C-header files which helps making your software compatible with numerous different processor types. So even while Rust has a macro system, it would need to be adapted by those manufacturers or C will likely stay the more convenient choice for the time being.
mlindner 6y ago
Please tell me how I can shut off the heap and still use portions of the C++ standard library? You can do that with Rust. C++ just wasn't designed with embedded in mind.
- pjmlp 6y ago
  Easy, by actually learning how pros do it. https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default.aspx https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default... https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf https://www.autosar.org/fileadmin/user_upload/standards/adap... https://en.cppreference.com/w/cpp/freestanding https://en.cppreference.com/w/cpp/freestanding Certifications that Rust has yet to achieve.
- zozbot234 6y ago
  C++ has custom allocators and in-place object construction via placement new. That's even better support than current Rust, which is still limited to a single, global allocator for the entire program.

dustinmoris 6y ago

There’s that saying we have: I dress slowly because I’m in a rush.

sai_c 6y ago

Yeah, but I think there is another saying that is still true in 2020: "Time is money". ;-). Edit: Corrected typo.