5 ms·

It is interesting that rust goes for a demographic of people coming from scripting languages or functional languages, but it seems like its niche might be much

It is interesting that rust goes for a demographic of people coming from scripting languages or functional languages, but it seems like its niche might be much more suited to the lowest level of larger programs or embedded work where people are using straight C. Straight C seems to be used for transparency and compiler compatibility though, which could be at odds with rust's current workflow. I think pragmatically using rust, modern C++ or even C, any concurrency needs to be done at a generic and separate architectural level that is not part of the day to day refinements and features of a program. I don't think constantly thinking about data races, low level synchronization, or even lifetimes more complex than being returned from the creation scope is ever going to be a recipe for long term success. This is all to say that I think rust's safety strengths are greatest in areas of a program that should actually be as small as possible and changed rarely.

steveklabnik 7y ago
This is partially a thing that happened organically. People who don’t come from a low-level background hear “compiler checks your work!” and think “I need a lot of help, that sounds great!”. People who come from a C or C++ background hear it and think “great, something that will get in my way”, and also sometimes think that they know better when they actually don’t. It used to be pretty common for people to jump on IRC and say “ugh I know I’m right how can I get the borrow checker to shut up” and then have something they were missing pointed out to them. The compiler was right, in the end. (This is of course not true all the time but it is a lot of the time...)
acheron9383 7y ago
Honestly, coming to Rust from C/C++ is/was a breath of fresh air. I work mostly in C++ for my day job, and with Rust I spend so much less time thinking about the implementation because the compiler will check for me. With C++ I'm always scratching my head about whether I've remembered to make all the constructors properly, whether I'm initializing this variable properly, whether I'm invoking the STL correctly to get a shared_pointer or something. Whether this piece of STL is compatible with some other piece of C++. This list goes on and on. With Rust, the compiler will tell me when I forget things, through the strong type system and borrow checker. It is insane the number of times the code works once it compiles. With Rust, after getting over the hump with lifetimes, I spend so much less time thinking about syntax and language specifics, and so much more time thinking about the business logic of the problem. The language acts like a great belay system to keep me much safer.
- BubRoss 7y ago
  I never run into this myself in modern C++ and I think it is about what I don't do. This might be similar on some level to the fact that rust constrains programmers purposely. I think both cases are indicative of better programming through avoiding things that are hard to get right and have little to no upside. I almost never use shared_ptr, since I know the lifetimes of the memory I use. I know the lifetimes because I keep almost all actual memory management within data structures made of mostly STL data structures. The custom data structures don't need destructors because vector<> will take care of it etc. I never use inheritance and never use polymorphism. The core logic then just uses these compound data structures made from STL containers and the lifetimes are frequently trivial.
Animats 7y ago
It is interesting that rust goes for a demographic of people coming from scripting languages or functional languages, but it seems like its niche might be much more suited to the lowest level of larger programs or embedded work where people are using straight C. Yes. Originally Rust seemed to be the answer to the three big questions in C: "How big is it", "Who owns it", and "Who locks it". Those are the cause of most of the vulnerabilities you see in CERT advisories. Rust finally had a working, efficient solution to all those problems. A huge breakthrough. Then the type-theory people, the "metaprogramming" people, and the functional people got in there and mucked up a perfectly good imperative language. They turned writing code into either puzzle-solving or copying forms you don't really understand. That already happened to C++. The "metaprogramming" people complicated templates to the point that "you are not supposed to understand this" is now normal for some standard templates. Now the C++ crowd is trying to emulate Rust features like move semantics without a borrow checker, which doesn't really work. Go was a reaction to that. Go is a mediocre language, but it's good enough for most web back-end stuff, which is why Google developed it.
- pjmlp 7y ago
  > Now the C++ crowd is trying to emulate Rust features like move semantics without a borrow checker, which doesn't really work. Clang tidy and Visual C++ lifetime profile are that borrow checker. If they get good enough results, GCC and other commercial compilers will definitely adopt them as well.
  - steveklabnik 7y ago
    Yes and no. They explicitly do not go as far as Rust does. More safety tooling is very welcome though!
    - pjmlp 7y ago
      I agree, but they are better than nothing and since millions of C and C++ lines of code aren't going to be converted into something else, any improvement is welcomed. For example, I was quite surprised that with all the security sales story, Azure Sphere SDK is C only, which basically torpedoes their sales pitch. At least MSR seems to keep having a go at Checked C.

steveklabnik 7y ago

This is partially a thing that happened organically. People who don’t come from a low-level background hear “compiler checks your work!” and think “I need a lot of help, that sounds great!”. People who come from a C or C++ background hear it and think “great, something that will get in my way”, and also sometimes think that they know better when they actually don’t. It used to be pretty common for people to jump on IRC and say “ugh I know I’m right how can I get the borrow checker to shut up” and then have something they were missing pointed out to them. The compiler was right, in the end. (This is of course not true all the time but it is a lot of the time...)

acheron9383 7y ago

Honestly, coming to Rust from C/C++ is/was a breath of fresh air. I work mostly in C++ for my day job, and with Rust I spend so much less time thinking about the implementation because the compiler will check for me. With C++ I'm always scratching my head about whether I've remembered to make all the constructors properly, whether I'm initializing this variable properly, whether I'm invoking the STL correctly to get a shared_pointer or something. Whether this piece of STL is compatible with some other piece of C++. This list goes on and on. With Rust, the compiler will tell me when I forget things, through the strong type system and borrow checker. It is insane the number of times the code works once it compiles. With Rust, after getting over the hump with lifetimes, I spend so much less time thinking about syntax and language specifics, and so much more time thinking about the business logic of the problem. The language acts like a great belay system to keep me much safer.

BubRoss 7y ago
I never run into this myself in modern C++ and I think it is about what I don't do. This might be similar on some level to the fact that rust constrains programmers purposely. I think both cases are indicative of better programming through avoiding things that are hard to get right and have little to no upside. I almost never use shared_ptr, since I know the lifetimes of the memory I use. I know the lifetimes because I keep almost all actual memory management within data structures made of mostly STL data structures. The custom data structures don't need destructors because vector<> will take care of it etc. I never use inheritance and never use polymorphism. The core logic then just uses these compound data structures made from STL containers and the lifetimes are frequently trivial.

Animats 7y ago

It is interesting that rust goes for a demographic of people coming from scripting languages or functional languages, but it seems like its niche might be much more suited to the lowest level of larger programs or embedded work where people are using straight C. Yes. Originally Rust seemed to be the answer to the three big questions in C: "How big is it", "Who owns it", and "Who locks it". Those are the cause of most of the vulnerabilities you see in CERT advisories. Rust finally had a working, efficient solution to all those problems. A huge breakthrough. Then the type-theory people, the "metaprogramming" people, and the functional people got in there and mucked up a perfectly good imperative language. They turned writing code into either puzzle-solving or copying forms you don't really understand. That already happened to C++. The "metaprogramming" people complicated templates to the point that "you are not supposed to understand this" is now normal for some standard templates. Now the C++ crowd is trying to emulate Rust features like move semantics without a borrow checker, which doesn't really work. Go was a reaction to that. Go is a mediocre language, but it's good enough for most web back-end stuff, which is why Google developed it.

pjmlp 7y ago
> Now the C++ crowd is trying to emulate Rust features like move semantics without a borrow checker, which doesn't really work. Clang tidy and Visual C++ lifetime profile are that borrow checker. If they get good enough results, GCC and other commercial compilers will definitely adopt them as well.
- steveklabnik 7y ago
  Yes and no. They explicitly do not go as far as Rust does. More safety tooling is very welcome though!
  - pjmlp 7y ago
    I agree, but they are better than nothing and since millions of C and C++ lines of code aren't going to be converted into something else, any improvement is welcomed. For example, I was quite surprised that with all the security sales story, Azure Sphere SDK is C only, which basically torpedoes their sales pitch. At least MSR seems to keep having a go at Checked C.