23 ms·

I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in

by dreta 10y ago

I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Rust doesn’t even have support for modern features like wide registers, or any features that help you deal with raw memory, it just marks it as “unsafe”. There aren’t even any basic meta programming features like struct introspection. What problems does Rust actually solve that C and its copycats have been suffering from since the 70s.

pcwalton 10y ago
> I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. A quick analysis I did showed that half of the critical security vulnerabilities in Gecko would have been prevented by writing content and layout code in Rust. The other half were mostly JS issues, often having to do with built-in APIs that would also be safe if appropriately written in Rust (or self-hosted). > For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Well, this definition of a systems programming language excludes C. > Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Nope. Rust defines signed overflow. http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ http://huonw.github.io/blog/2016/04/myths-and-legends-about-... > Rust doesn’t even have support for modern features like wide registers What is a "wide register"? Do you mean SIMD? If so, it sure does [1]. > or any features that help you deal with raw memory, it just marks it as “unsafe”. Sure it does. Rust helps you deal with raw memory by freeing you from the need to deal with raw memory in the vast majority of occasions. For example, in C you have to mess around with char pointers to operate on strings. In Rust you don't. > There aren’t even any basic meta programming features like struct introspection. That's what custom derive is for. [1]: https://huonw.github.io/simd/simd/ https://huonw.github.io/simd/simd/
- dreta 10y ago
  Alright, thanks for clearing that up. I missed those in the documentation, since it doesn’t specify any of this directly. Though, still wide registers aren’t a language feature. I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. It doesn’t. The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. The problem is writing custom allocators for the data you have, and needing some basic bounds checking. Problem is working with structures of arrays instead of arrays of structures, because that can get messy and introduce basic typing bugs. I’d love to see any modern programming language at least make an attempt at making working with raw memory easier.
  - pcwalton 10y ago
    > I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. I do. Am I a bad programmer? > The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. Buffer overflows aren't problems?
    - dreta 10y ago
      I’m not saying you’re bad. I’m saying there’s always a point where you want to go down to managing your own memory when performance is an issue, and no amount of language features is going to change that. What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it. Writing my own growable data type using malloc and free is something i can do once, and i just have it, it’s not something that i have to worry about for more than 5 minutes at the beginning of a project.
      - pjmlp 10y ago
        Not everyone has the privilege to be a single C coder owning the code without anyone else from different skill levels coding in it and without any additional use of third party libraries.
vvanders 10y ago
You've never hit a NPE or null pointer? Data races or use after free? Const is nothing like references, not even close. I would suggest you spend a bit more time with the language to better understand exactly what Rust brings to the table.
- dreta 10y ago
  The number of cases where i have to use a generic memory allocator like malloc in a typical project are extremely rare, so no. I never said that const is like anything, i just used it as an example.
  - dbaupp 10y ago
    One can get all of the problems mentioned with allocators other than malloc, up to and including using only the stack. Also, sure the implementation of another allocator might use a smattering of `unsafe`, but I'm guess that it will be less than you probably expect: one of Rust's biggest is strengths is the ability to build safe interfaces for things without performance cost. One can see an example for this in http://os.phil-opp.com/ http://os.phil-opp.com/ where the author is slowly describing creating an operating system, all while concentrating on how to exploit Rust features to let the compiler help the programmer, such as http://os.phil-opp.com/modifying-page-tables.html http://os.phil-opp.com/modifying-page-tables.html .
  - Retra 10y ago
    What does malloc have to do with anything? Returning a pointer to the stack is just as likely to break everything if done improperly. Moving or copying a struct that points at itself is also going to break. In fact, "how to to either of these things" is such a common question for new rust programmers trying to solve their borrow checker complaints that it constitutes pretty good evidence people are doing these things all the time with little understanding of why they are problematic. And even if you _do_ know better, circumventing the borrow checker is fairly trivial.
    - vardump 10y ago
sidlls 10y ago
I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion. To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &' and such. Arguably until move semantics were standardized with C++11 it was a challenge to write safe code. I will agree that Rust's developers have perhaps come down too far on the side of "YOU ARE DOING SOMETHING DANGEROUS BY USING A POINTER." But I think you're exaggerating a bit about how hard it is.
- dreta 10y ago
  My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.
  - sidlls 10y ago
    I haven't, either. I've come across plenty that would save me from having painful gdb sessions to fix code inexperienced (or lazy) developers write.
  - Manishearth 10y ago
    Rust isn't a panacea, nor does it claim to be. It doesn't prevent bugs. It prevents memory safety bugs.
    - sidlls 10y ago
      > nor does it claim to be. "It" doesn't do anything. But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it. Besides, right now a lot of the "memory safety" of Rust has much more to do with selection bias (it is used primarily by people who are explicitly interested in using its safety features). When one uses exclusively (or almost exclusively) the "memory safe" features of the language, of course things implemented in it will be free of "memory safety" bugs. Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things. Here's how I see Rust: it's far and away already superior than C++ for a certain class of systems application programming (e.g. performant desktop/native application code that sits at the systems boundary). Rust code that seriously competes with C or C++ for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. If it gains traction "in the wild," my prediction is we'll start seeing plenty of "memory safety" bugs in that area. The question then is how easily they're spotted and rectified.
burntsushi 10y ago
I published a regex library for Rust a few years ago. Since then, it's been downloaded a million times and used in over 300 published crates. I've had 0 reports of seg faults or buffer overflows. Can regex libraries written in C say the same? I don't think so.[1] [1] - https://www.cvedetails.com/vulnerability-list/vendor_id-3265/opdos-1/Pcre.html https://www.cvedetails.com/vulnerability-list/vendor_id-3265...

by dreta 10y ago

pcwalton 10y ago

> I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. A quick analysis I did showed that half of the critical security vulnerabilities in Gecko would have been prevented by writing content and layout code in Rust. The other half were mostly JS issues, often having to do with built-in APIs that would also be safe if appropriately written in Rust (or self-hosted). > For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Well, this definition of a systems programming language excludes C. > Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Nope. Rust defines signed overflow. http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ http://huonw.github.io/blog/2016/04/myths-and-legends-about-... > Rust doesn’t even have support for modern features like wide registers What is a "wide register"? Do you mean SIMD? If so, it sure does [1]. > or any features that help you deal with raw memory, it just marks it as “unsafe”. Sure it does. Rust helps you deal with raw memory by freeing you from the need to deal with raw memory in the vast majority of occasions. For example, in C you have to mess around with char pointers to operate on strings. In Rust you don't. > There aren’t even any basic meta programming features like struct introspection. That's what custom derive is for. [1]: https://huonw.github.io/simd/simd/ https://huonw.github.io/simd/simd/

dreta 10y ago
Alright, thanks for clearing that up. I missed those in the documentation, since it doesn’t specify any of this directly. Though, still wide registers aren’t a language feature. I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. It doesn’t. The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. The problem is writing custom allocators for the data you have, and needing some basic bounds checking. Problem is working with structures of arrays instead of arrays of structures, because that can get messy and introduce basic typing bugs. I’d love to see any modern programming language at least make an attempt at making working with raw memory easier.
- pcwalton 10y ago
  > I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. I do. Am I a bad programmer? > The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. Buffer overflows aren't problems?
  - dreta 10y ago
    I’m not saying you’re bad. I’m saying there’s always a point where you want to go down to managing your own memory when performance is an issue, and no amount of language features is going to change that. What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it. Writing my own growable data type using malloc and free is something i can do once, and i just have it, it’s not something that i have to worry about for more than 5 minutes at the beginning of a project.
    - pjmlp 10y ago
      Not everyone has the privilege to be a single C coder owning the code without anyone else from different skill levels coding in it and without any additional use of third party libraries.

vvanders 10y ago

You've never hit a NPE or null pointer? Data races or use after free? Const is nothing like references, not even close. I would suggest you spend a bit more time with the language to better understand exactly what Rust brings to the table.

dreta 10y ago
The number of cases where i have to use a generic memory allocator like malloc in a typical project are extremely rare, so no. I never said that const is like anything, i just used it as an example.
- dbaupp 10y ago
  One can get all of the problems mentioned with allocators other than malloc, up to and including using only the stack. Also, sure the implementation of another allocator might use a smattering of `unsafe`, but I'm guess that it will be less than you probably expect: one of Rust's biggest is strengths is the ability to build safe interfaces for things without performance cost. One can see an example for this in http://os.phil-opp.com/ http://os.phil-opp.com/ where the author is slowly describing creating an operating system, all while concentrating on how to exploit Rust features to let the compiler help the programmer, such as http://os.phil-opp.com/modifying-page-tables.html http://os.phil-opp.com/modifying-page-tables.html .
- Retra 10y ago
  What does malloc have to do with anything? Returning a pointer to the stack is just as likely to break everything if done improperly. Moving or copying a struct that points at itself is also going to break. In fact, "how to to either of these things" is such a common question for new rust programmers trying to solve their borrow checker complaints that it constitutes pretty good evidence people are doing these things all the time with little understanding of why they are problematic. And even if you _do_ know better, circumventing the borrow checker is fairly trivial.
  - vardump 10y ago

sidlls 10y ago

I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion. To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &' and such. Arguably until move semantics were standardized with C++11 it was a challenge to write safe code. I will agree that Rust's developers have perhaps come down too far on the side of "YOU ARE DOING SOMETHING DANGEROUS BY USING A POINTER." But I think you're exaggerating a bit about how hard it is.

dreta 10y ago
My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.
- sidlls 10y ago
  I haven't, either. I've come across plenty that would save me from having painful gdb sessions to fix code inexperienced (or lazy) developers write.
- Manishearth 10y ago
  Rust isn't a panacea, nor does it claim to be. It doesn't prevent bugs. It prevents memory safety bugs.
  - sidlls 10y ago
    > nor does it claim to be. "It" doesn't do anything. But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it. Besides, right now a lot of the "memory safety" of Rust has much more to do with selection bias (it is used primarily by people who are explicitly interested in using its safety features). When one uses exclusively (or almost exclusively) the "memory safe" features of the language, of course things implemented in it will be free of "memory safety" bugs. Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things. Here's how I see Rust: it's far and away already superior than C++ for a certain class of systems application programming (e.g. performant desktop/native application code that sits at the systems boundary). Rust code that seriously competes with C or C++ for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. If it gains traction "in the wild," my prediction is we'll start seeing plenty of "memory safety" bugs in that area. The question then is how easily they're spotted and rectified.

burntsushi 10y ago

I published a regex library for Rust a few years ago. Since then, it's been downloaded a million times and used in over 300 published crates. I've had 0 reports of seg faults or buffer overflows. Can regex libraries written in C say the same? I don't think so.[1] [1] - https://www.cvedetails.com/vulnerability-list/vendor_id-3265/opdos-1/Pcre.html https://www.cvedetails.com/vulnerability-list/vendor_id-3265...