3 ms·

Agreed. C++ is far safer than C and just as safe as rust. If the rust crowd was really serious about convincing C and C++ devs to move to rust, then they ought

by w8rbt 10y ago

Agreed. C++ is far safer than C and just as safe as rust. If the rust crowd was really serious about convincing C and C++ devs to move to rust, then they ought to have made the syntax identical (or at least much closer) to C than it currently is. That's the primary reason Java took off. If you know C, you can write working C++ and Java programs straight away. For rust, we have to stop and relearn how to apply the logic (thus slow/no adoption). And, I'm really sick of the constant HN sales pitches for rust. Make the transition easy and rust will stand on its own/sell itself (or not).

catnaroek 10y ago
When did C++ add a language-enforced mechanism for ruling out dangling references, data races, uses after `std::move()`, etc.?
- pjmlp 10y ago
  They didn't, but had Java and .NET been AOT compiled to native code since the beginning and you would see less C and C++ code around. So now that even them have got the AOT memo, and Go and Swift also exist, I think the 2017's focus on productivity is very important. The work done in the borrow check is incredibly and has already influenced decisions on the D, Swift and C++ communities. Yet they all agree that they don't want to make it as hard as Rust. Chris Lattner mentioned the feature in Swift should be exposed to expert programmers doing kernel and driver related programming. I imagine Rust's image should be better than a language from experts for experts.
  - catnaroek 10y ago
    > I think the 2017's focus on productivity is very important. If the yardstick of “productivity” is how fast you can write incorrect programs, I'm not terribly interested in “productivity”. I'm sick of being a defensive user, having to refrain from probing how systems work in undocumented and likely unforeseen scenarios, lest I completely break them in unrecoverable ways. I'd rather see an axiomatic semantics for unsafe Rust, so that I can formally prove that my unsafe Rust code doesn't break safe Rust's integrity guarantees. > So now that even them have got the AOT memo, and Go and Swift also exist Support for running in an unmanaged environment is a red herring. If you want to manage resources correctly, you have to care about ownership and lifetimes, regardless of whether you are doing systems programming (user programs manage resources too), need AOT compilation (JIT-compiled programs manage resources too) or need a GC-less environment (GC doesn't work for resources that need to be reclaimed eager and deterministically). > I imagine Rust's image should be better than a language from experts for experts. I have no idea. I'm not a member of any community (not a “Rustacean”, not a “Haskeller”, not anything), and I have no personal interest (financial or emotional) in any specific technology becoming popular. I only care about technical facts. Are facts for experts only?
    - pjmlp 10y ago
      > GC doesn't work for resources that need to be reclaimed eager and deterministically Which is why usually there are other language or runtime features for deterministicaly managing resources besides just the GC. The question is how to keep the way of Rust memory management, while e.g. making it easier to write cyclic graphs, or reducing even further the cases where one has to explicity type lifetimes.
      - catnaroek 10y ago
        > Which is why usually there are other language or runtime features for deterministicaly managing resources besides just the GC. Other than what Rust (and its research ancestors) uses, I haven't seen any alternative that isn't fundamentally broken in some way or another. > making it easier to write cyclic graphs I'd do it the same way I do it in any other language: initially create a DAG, then mutate it to create the cycles. This needs reference cells or something like that. Rust can do it already. > reducing even further the cases where one has to explicity type lifetimes. I don't see any way to do that in the vicinity of where Rust lies in the design space. What Rust has settled for (explicit lifetimes in type definitions, elision at use site) seems perfectly sensible to me. Of course, if a better alternative is found, that's a great thing.
    - steveklabnik 10y ago
      > I'm not terribly interested in “productivity”. > I'd rather see an axiomatic semantics for unsafe Rust Luckily, this isn't an either-or! There are several groups of academics working with us on #2, while we work on #1. (among other things)
      - catnaroek 10y ago
        I have no idea why you got downvoted. The only questionable thing in your comment is the use of 1 and 2, instead of 0 and 1. Downvoting for this reason seems petty. :-p
        steveklabnik 10y ago
caconym_ 10y ago
Being easy to use for people who don't want to learn new things is not a good driver for language design unless the primary motivation for the language's development is education. If you want to use C or C++, use them. Rust is its own thing and it will either succeed or fail to break into the mainstream but I can tell you that if it was just C or C++ with lifetime stuff bolted on then I would never have bothered learning it. Criticizing it because C/C++ programmers can't just drop into it and start productively writing production-quality code is very short-sighted, IMO, and it's amazing how much it happens around here.

by w8rbt 10y ago

catnaroek 10y ago

When did C++ add a language-enforced mechanism for ruling out dangling references, data races, uses after `std::move()`, etc.?

pjmlp 10y ago
They didn't, but had Java and .NET been AOT compiled to native code since the beginning and you would see less C and C++ code around. So now that even them have got the AOT memo, and Go and Swift also exist, I think the 2017's focus on productivity is very important. The work done in the borrow check is incredibly and has already influenced decisions on the D, Swift and C++ communities. Yet they all agree that they don't want to make it as hard as Rust. Chris Lattner mentioned the feature in Swift should be exposed to expert programmers doing kernel and driver related programming. I imagine Rust's image should be better than a language from experts for experts.
- catnaroek 10y ago
  > I think the 2017's focus on productivity is very important. If the yardstick of “productivity” is how fast you can write incorrect programs, I'm not terribly interested in “productivity”. I'm sick of being a defensive user, having to refrain from probing how systems work in undocumented and likely unforeseen scenarios, lest I completely break them in unrecoverable ways. I'd rather see an axiomatic semantics for unsafe Rust, so that I can formally prove that my unsafe Rust code doesn't break safe Rust's integrity guarantees. > So now that even them have got the AOT memo, and Go and Swift also exist Support for running in an unmanaged environment is a red herring. If you want to manage resources correctly, you have to care about ownership and lifetimes, regardless of whether you are doing systems programming (user programs manage resources too), need AOT compilation (JIT-compiled programs manage resources too) or need a GC-less environment (GC doesn't work for resources that need to be reclaimed eager and deterministically). > I imagine Rust's image should be better than a language from experts for experts. I have no idea. I'm not a member of any community (not a “Rustacean”, not a “Haskeller”, not anything), and I have no personal interest (financial or emotional) in any specific technology becoming popular. I only care about technical facts. Are facts for experts only?
  - pjmlp 10y ago
    > GC doesn't work for resources that need to be reclaimed eager and deterministically Which is why usually there are other language or runtime features for deterministicaly managing resources besides just the GC. The question is how to keep the way of Rust memory management, while e.g. making it easier to write cyclic graphs, or reducing even further the cases where one has to explicity type lifetimes.
    - catnaroek 10y ago
      > Which is why usually there are other language or runtime features for deterministicaly managing resources besides just the GC. Other than what Rust (and its research ancestors) uses, I haven't seen any alternative that isn't fundamentally broken in some way or another. > making it easier to write cyclic graphs I'd do it the same way I do it in any other language: initially create a DAG, then mutate it to create the cycles. This needs reference cells or something like that. Rust can do it already. > reducing even further the cases where one has to explicity type lifetimes. I don't see any way to do that in the vicinity of where Rust lies in the design space. What Rust has settled for (explicit lifetimes in type definitions, elision at use site) seems perfectly sensible to me. Of course, if a better alternative is found, that's a great thing.
  - steveklabnik 10y ago
    > I'm not terribly interested in “productivity”. > I'd rather see an axiomatic semantics for unsafe Rust Luckily, this isn't an either-or! There are several groups of academics working with us on #2, while we work on #1. (among other things)
    - catnaroek 10y ago
      I have no idea why you got downvoted. The only questionable thing in your comment is the use of 1 and 2, instead of 0 and 1. Downvoting for this reason seems petty. :-p
      - steveklabnik 10y ago

caconym_ 10y ago

Being easy to use for people who don't want to learn new things is not a good driver for language design unless the primary motivation for the language's development is education. If you want to use C or C++, use them. Rust is its own thing and it will either succeed or fail to break into the mainstream but I can tell you that if it was just C or C++ with lifetime stuff bolted on then I would never have bothered learning it. Criticizing it because C/C++ programmers can't just drop into it and start productively writing production-quality code is very short-sighted, IMO, and it's amazing how much it happens around here.