9 ms·

You are ignoring the fact that many problems can't be solved in the higher level languages. Also, for some, having the c/c++ level of control is prefered.

bluejekyll 9y ago
This doesn't have to be zero sum. We don't need to choose between safe and unsafe. Safety should be a default, with unsafety being something you opt into. C/C++ are both unsafe. Rust is safe by default, and for the cases where you want/need the C/C++ level of access to the system, you can opt into unsafe. I believe Rust is more safe than Go and Java as well, because of the type safety in the threading model. There are existing applications in C out there, there will be for a long time. Personally I frown upon anyone starting a new project in C or C++, or any unsafe language, especially when you have such a strong language in Rust that exists with a very healthy and growing community around it.
- gens 9y ago
  I don't like to be told what programming language i should use. You can scoff all you want, but i will be using C for most of my projects.
  - bluejekyll 9y ago
    I don't "tell" people, what language to use. But I do encourage them to look at new languages, especially ones that fit in the same place as one that they like. I love C. It was my first programming language. I love the syntax, I love the semantics. Years ago, I left it though, because I could deliver higher quality applications with fewer unknown bugs with Java, but I always wanted to find a reason to go back to C. And for some projects I did, and it was important (and in each case I'd run into some error or bug that took weeks to track down). When I grabbed Rust 2 years ago, it was like getting everything I loved about C paired with everything I love about Java, and none of the stuff I hate in either. Feel free to use whatever language you wish, and I hope schools continue to teach C (though that seems to be dwindling), but I highly encourage people to checkout Rust and see what it's like to not worry about pointer management all the time.
    - Const-me 9y ago
      When I checked out Rust a year ago, I immediately discovered it has no SIMD (SSE, AVX, Neon). That it has no sane ways to implement a graph structure. Also that it’s hard to compose data structures into higher-level specialized ones. Also, I highly encourage people who worry about pointer management all the time to checkout modern C++.
      - pcwalton 9y ago
        > That it has no sane ways to implement a graph structure. Sure it does. I work with graphs in Rust all the time. They may not be "sane" in your view because they're different from the way you implement them in C++, but I could equally well say that there's no "sane" way to implement a safe owning pointer in C++ (since there's no memory-safe way to do so). > Also, I highly encourage people who worry about pointer management all the time to checkout modern C++. Modern C++ has no protection against the most pernicious memory management errors, particularly use-after-free.
        Const-me 9y ago
        > They may not be "sane" in your view because they're different from the way you implement them in C++ I saw two kinds of Rust graphs. One is safe, easy to understand, but slow (e.g. reference counting). Another one (unsafe Rust) is very hard to implement, thousands lines of code. Also, modern C++ is much safer than unsafe rust. > C++ has no protection against the most pernicious memory management errors, particularly use-after-free CRT debug heap / MALLOC_CHECK_ / libefence, depending on the platform/compiler
        cesarb 9y ago
        > I saw two kinds of Rust graphs. There's a third kind, which uses indexes into arrays containing the nodes and edges, instead of direct pointers to the node/edge. > CRT debug heap / MALLOC_CHECK_ / libefence, depending on the platform/compiler Can any of these protect against the scenario where a block of memory is freed, allocated again for another purpose, but still accessed through the old dangling pointer? Also, are they always present at runtime, or are they used only on debug builds and turned off on production? The use-after-free might happen only after a specific sequence of uncommon operations confuses the code enough that it either frees something before its time, or keeps and uses a stale pointer.
  - Jtsummers 9y ago
    That's one of the main reasons Ada lost to C and C++ in the DoD world. The other (and more significant) being cost of implementations. Personally, I prefer my work to be in the language or languages which suit it best rather than making my choice to spite others for a perceived and, usually, non-existent slight.
- planteen 9y ago
  You sure would frown a lot in the embedded world. Rust isn't even a contender for most hard-real time or safety critical projects. Is it even supported by any RTOS today?
  - bluejekyll 9y ago
    Recently I had the pleasure of learning how to develop for this https://www.tockos.org/ https://www.tockos.org/, which was a lot of fun. But yes, I can still frown at the C in the embedded world, and bite my tongue when forced to use it. It's only a matter of time IMO before Rust gets onto more of these devices.
- blahman2 9y ago
  i don't know why, but every time someone says stuff like 'such a strong X in Y that exists with a very healthy and growing community around it' i feel the need to puke.
- jstewartmobile 9y ago
  Notice that "scoff at" turned to "frown upon" here, but same difference. I like Rust, but the kind of attitude you've shown in this comment is a) distressingly common among Rustaceans, and b) makes everyone in the embedded world who would like to get away from C/C++ keep the whole Rust ecosystem at arms-length.
  - bluejekyll 9y ago
    Scoff: speak to someone or about something in a scornfully derisive or mocking way. Frown: furrow one's brow in an expression of disapproval, displeasure, or concentration. Those are definitely not the same thing. Language is deliberate. I'd prefer it if you don't change mine to mean something I do not. I frown at a lot of things in software I review, then someone explains to me why they decided to do something the way they did, in which case they may convince me that they are correct. In the case of C/C++, you can convince me easily in the embedded space that C is still the best choice, and I'd agree. I wouldn't even debate it, I might personally go try and see if there is an option there, but it's clearly a space that Rust is still getting bootstrapped into.
    - jstewartmobile 9y ago
      You wrote "scoff" first before you edited it, that's why gens wrote "You can scoff all you want". From the tone of your comments, I think that's what you're really doing.
      - bluejekyll 9y ago
        hmm... I did not. But ok.
      - gens 9y ago
        No, he did not. Not as far as i remember. I am not British, and i did want to dramatize it a bit. In my defense, words are to convey meaning as much as to describe action. (you don't literally "beat a dead horse" or "fart in your general direction") EDIT: In bluejekyll's defense, we here are a bit chafed (hehe) by extreme fans of certain programming languages (IMO even some functional programming fans get a tad too.. unrealistic in their talks)
- deleted 9y ago
  [deleted]

bluejekyll 9y ago

This doesn't have to be zero sum. We don't need to choose between safe and unsafe. Safety should be a default, with unsafety being something you opt into. C/C++ are both unsafe. Rust is safe by default, and for the cases where you want/need the C/C++ level of access to the system, you can opt into unsafe. I believe Rust is more safe than Go and Java as well, because of the type safety in the threading model. There are existing applications in C out there, there will be for a long time. Personally I frown upon anyone starting a new project in C or C++, or any unsafe language, especially when you have such a strong language in Rust that exists with a very healthy and growing community around it.

gens 9y ago
I don't like to be told what programming language i should use. You can scoff all you want, but i will be using C for most of my projects.
- bluejekyll 9y ago
  I don't "tell" people, what language to use. But I do encourage them to look at new languages, especially ones that fit in the same place as one that they like. I love C. It was my first programming language. I love the syntax, I love the semantics. Years ago, I left it though, because I could deliver higher quality applications with fewer unknown bugs with Java, but I always wanted to find a reason to go back to C. And for some projects I did, and it was important (and in each case I'd run into some error or bug that took weeks to track down). When I grabbed Rust 2 years ago, it was like getting everything I loved about C paired with everything I love about Java, and none of the stuff I hate in either. Feel free to use whatever language you wish, and I hope schools continue to teach C (though that seems to be dwindling), but I highly encourage people to checkout Rust and see what it's like to not worry about pointer management all the time.
  - Const-me 9y ago
    When I checked out Rust a year ago, I immediately discovered it has no SIMD (SSE, AVX, Neon). That it has no sane ways to implement a graph structure. Also that it’s hard to compose data structures into higher-level specialized ones. Also, I highly encourage people who worry about pointer management all the time to checkout modern C++.
    - pcwalton 9y ago
      > That it has no sane ways to implement a graph structure. Sure it does. I work with graphs in Rust all the time. They may not be "sane" in your view because they're different from the way you implement them in C++, but I could equally well say that there's no "sane" way to implement a safe owning pointer in C++ (since there's no memory-safe way to do so). > Also, I highly encourage people who worry about pointer management all the time to checkout modern C++. Modern C++ has no protection against the most pernicious memory management errors, particularly use-after-free.
      - Const-me 9y ago
        > They may not be "sane" in your view because they're different from the way you implement them in C++ I saw two kinds of Rust graphs. One is safe, easy to understand, but slow (e.g. reference counting). Another one (unsafe Rust) is very hard to implement, thousands lines of code. Also, modern C++ is much safer than unsafe rust. > C++ has no protection against the most pernicious memory management errors, particularly use-after-free CRT debug heap / MALLOC_CHECK_ / libefence, depending on the platform/compiler
        cesarb 9y ago
        > I saw two kinds of Rust graphs. There's a third kind, which uses indexes into arrays containing the nodes and edges, instead of direct pointers to the node/edge. > CRT debug heap / MALLOC_CHECK_ / libefence, depending on the platform/compiler Can any of these protect against the scenario where a block of memory is freed, allocated again for another purpose, but still accessed through the old dangling pointer? Also, are they always present at runtime, or are they used only on debug builds and turned off on production? The use-after-free might happen only after a specific sequence of uncommon operations confuses the code enough that it either frees something before its time, or keeps and uses a stale pointer.
- Jtsummers 9y ago
  That's one of the main reasons Ada lost to C and C++ in the DoD world. The other (and more significant) being cost of implementations. Personally, I prefer my work to be in the language or languages which suit it best rather than making my choice to spite others for a perceived and, usually, non-existent slight.
planteen 9y ago
You sure would frown a lot in the embedded world. Rust isn't even a contender for most hard-real time or safety critical projects. Is it even supported by any RTOS today?
- bluejekyll 9y ago
  Recently I had the pleasure of learning how to develop for this https://www.tockos.org/ https://www.tockos.org/, which was a lot of fun. But yes, I can still frown at the C in the embedded world, and bite my tongue when forced to use it. It's only a matter of time IMO before Rust gets onto more of these devices.
blahman2 9y ago
i don't know why, but every time someone says stuff like 'such a strong X in Y that exists with a very healthy and growing community around it' i feel the need to puke.
jstewartmobile 9y ago
Notice that "scoff at" turned to "frown upon" here, but same difference. I like Rust, but the kind of attitude you've shown in this comment is a) distressingly common among Rustaceans, and b) makes everyone in the embedded world who would like to get away from C/C++ keep the whole Rust ecosystem at arms-length.
- bluejekyll 9y ago
  Scoff: speak to someone or about something in a scornfully derisive or mocking way. Frown: furrow one's brow in an expression of disapproval, displeasure, or concentration. Those are definitely not the same thing. Language is deliberate. I'd prefer it if you don't change mine to mean something I do not. I frown at a lot of things in software I review, then someone explains to me why they decided to do something the way they did, in which case they may convince me that they are correct. In the case of C/C++, you can convince me easily in the embedded space that C is still the best choice, and I'd agree. I wouldn't even debate it, I might personally go try and see if there is an option there, but it's clearly a space that Rust is still getting bootstrapped into.
  - jstewartmobile 9y ago
    You wrote "scoff" first before you edited it, that's why gens wrote "You can scoff all you want". From the tone of your comments, I think that's what you're really doing.
    - bluejekyll 9y ago
      hmm... I did not. But ok.
    - gens 9y ago
      No, he did not. Not as far as i remember. I am not British, and i did want to dramatize it a bit. In my defense, words are to convey meaning as much as to describe action. (you don't literally "beat a dead horse" or "fart in your general direction") EDIT: In bluejekyll's defense, we here are a bit chafed (hehe) by extreme fans of certain programming languages (IMO even some functional programming fans get a tad too.. unrealistic in their talks)
deleted 9y ago
[deleted]