4 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

> 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.
    - dbaupp 10y ago
      > What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it You have that. For example, if you have contiguous memory, the various forms of the [T] slice type can be used, they don't impose any allocation expectations. (And, once the standard library allows pluggable allocators, you'll likely be able to use Vec directly, for a growable vector type.) If you don't have contiguous memory, then it's a bit more work, but one can still use features like generics and privacy to spend a few lines building abstractions that bounds check in the right places. It's not like using a proof language to extract a program that is guaranteed to have no out of bounds accesses, or a compiler that some how deduces what the bounds of your data structure is, but the former has its own complexity downsides, and the latter seems infeasible, in general.

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.
  - dbaupp 10y ago
    > What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it You have that. For example, if you have contiguous memory, the various forms of the [T] slice type can be used, they don't impose any allocation expectations. (And, once the standard library allows pluggable allocators, you'll likely be able to use Vec directly, for a growable vector type.) If you don't have contiguous memory, then it's a bit more work, but one can still use features like generics and privacy to spend a few lines building abstractions that bounds check in the right places. It's not like using a proof language to extract a program that is guaranteed to have no out of bounds accesses, or a compiler that some how deduces what the bounds of your data structure is, but the former has its own complexity downsides, and the latter seems infeasible, in general.