4 ms·

One of, in my opinion, the largest problem with Rust is that they sought to solve two problems: 1. Memory / thread safety 2. They didn't like C/C++ And often

One of, in my opinion, the largest problem with Rust is that they sought to solve two problems: 1. Memory / thread safety 2. They didn't like C/C++ And often times it feels like there is more focus on problem two than problem one. Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting. I'd focus more on converting C/C++ to languages nearing the safety of Rust but without it being such a huge shift. Like converting C++ to C#.

adastra22 1y ago
Examples?
- pizlonator 1y ago
  Doubly linked lists. Any cyclic data structure.
  - hackyhacky 1y ago
    Both of those are a direct consequence of Rust's memory model, not a result of animus against C++.
  - JoshTriplett 1y ago
    That's not at all a "we don't like C++" problem. That's "the chosen borrow-checking model makes cyclic structures hard, you have to do Rc/Arc and some manual management, or use unsafe and raw pointers". (Frankly, the latter is easier.)
    - pizlonator 1y ago
      Ref counting doesn’t work for cyclic data structures
      - JoshTriplett 1y ago
        It doesn't fully handle the memory management, but it handles having shared references. You can use weak references or manually break the links when you want to free something. Or you can use unsafe raw pointers, which frankly seem simpler. Either way you're going to wrap it in a data structure that encapsulates all the details.
      - NobodyNada 1y ago
        Sure it does. Make the backreferences weak, or use a library that provides cycle detection (or even full-on tracing GC if you really want).
        pizlonator 1y ago
        That changes the semantics. It won’t work for a graph for example.
        NobodyNada 1y ago
        Right. The comment you replied to said "Rc/Arc and some manual management" -- "some manual management" implying that you need to account for the change to semantics in the manner appropriate for your application.
        JoshTriplett 1y ago
        (Note that I edited my comment for clarity since the original reply. My original comment just said "reference counting".)
        pizlonator 1y ago
        The key part I agree with most in your edited comment is that unsafe raw pointers are the easiest way to deal with cycles. I think this is key. RC pointers don’t give you the ability to say: ok, I now know that this subset of the graph is dead because reasons so delete it. In RC, you’d have to walk the graph to break cycles. That’s a rather important difference from how you’d manage a cyclic data structure in C, C++, Java, C#, or any GC’d language. In C/C++, you’d delete what you know to be dead; in Java et al it would be enough to kill the references that point at the outer edges of the dead subgraph. But you wouldn’t have to walk the subgraph to detangle the cycle. I think it really is worse than that; ie as you say, folks will just do anything but RC in that case. In Rust the safe bet would be to just shove all the nodes into an array and use indices (yuck!!!). But likely a lot of code with use raw pointers instead (also yuck). The whole thing where you reference count cyclic data structures is just too painful for sensible people
  - jnwatson 1y ago
    While I think this is Rust's biggest flaw, this doesn't stem from any particular hatred of C/C++. This is related to memory safety, as it is very difficult to reason about memory lifetimes of object graphs with cycles.
  - adastra22 1y ago
    The easiest way to implement these is with Weak references in one of the directions. This requires some checking and/or locks, but the fact it is not trivial to do is kinda the point: the integrity of a cyclic data structure depends on managing multiple pointers in multiple structs simultaneously, and with that comes concurrency dragons.
  - treyd 1y ago
    There are doubly-linked list libraries in Rust. They are safe and well-designed. It's rare for a project to actually need a doubly-linked list. When you need it, you should use those instead of reimplementing your own.
- actionfromafar 1y ago
  Syntax is different any many places for no apparent reason
- bangaladore 1y ago
  My best example of a "real" and not more artificial example (like XYZ data structure) is Game development / game engines & UI. For reference: https://news.ycombinator.com/item?id=40172033 https://news.ycombinator.com/item?id=40172033
  - adastra22 1y ago
    A bit surprised that you didn’t mention Bevy in your post. Have you worked with it?
    - bangaladore 1y ago
      Not my post, but I've heard the same concerns with Bevy as with the others. And the actual blog post linked by that post does mention Bevy many times. Infact Bevy might be a perfect example of my gripe(s) with Rust. Completely throwing a standard object system out the window in-favor of ECS which still hasn't caught on in even the most used game engines like Unity hurts adoption and usability.
      - adastra22 1y ago
        I thought Unity and Unreal were transiting to ECS? I was under the impression at least that Bevy was adopting what the industry was moving towards, not exploring virgin territory.
        bangaladore 1y ago
        I'd very much consider ECS virgin territory. DOTS (ECS) in Unity has been out for 5+ years with little to no real adoption. I'm unaware of any pretty much any use of ECS in Unreal (I think what exists is mostly focused on internal graphics / animation, not gameplay).
convolvatron 1y ago
I don't think #2 is at all fair. I'm certainly of two minds about Rust and its ergonomics. But #2 seems to assume that C is some kind of default and canonical programming model, and to the extent that I like rust, its because they made different and internally consistent design choices.
- bangaladore 1y ago
  C/C++ is the "default" language they are/were trying to replace with Rust. So I think it's fair to point out that Rust made design decisions explicitly contrary to design decisions of C/C++ style languages even though Rust is meant to replace it. That's going to (and does cause) problems.
  - kibwen 1y ago
    > design decisions explicitly contrary to design decisions of C/C++ style languages even though Rust is meant to replace it Yes, but that doesn't have to do with whether they "like" C++ or not. What they "liked" is a programming model that could possibly be theoretically proven safe by any sort of tractable static analysis, and that inevitably means making decisions contrary to C/C++. Achieving their design goals was more important than adhering to C++'s mistakes for sentimental reasons.
    - bangaladore 1y ago
      You are confusing problem 1 (memory / thread safety) with problem 2 (being distinct from C/C++). I'm not here to argue about changes made that are necessary to solve problem 1, but I'm also not here to pretend that all the differences Rust has compared to a C-style language like C/C++/C# is largely due to supporting memory / thread safety.
      - kibwen 1y ago
        You continue vaguely asserting "differences" and then retreating when challenged. So please be specific: what differences?
Ygg2 1y ago
> They didn't like C/C++ Riiiight. You do realize they made syntax similar to C/C++ on purpose to ease Mozilla's C/C++ programmers into it. It's not that they didn't like it; it's that C/C++ is about as disinterested in memory/thread safety as you can get. It's been what, ten years since Rust became 1.0? And the safety needle of C++ hasn't budged a femtometer. > Quite a bit of idiomatic and safe (yes that does exist) C++ Sure, so does legible Brainfuck. However, it's extremely challenging to write it. It usually takes years and years of effort, chasing down obscure bugs. > Like converting C++ to C#. If you can take GC pause and not wince, sure, go for it. Not everyone can take that luxury.
- tialaramex 1y ago
  > And the safety needle of C++ hasn't budged a femtometer. That's not fair. C++ 26 gets from the uninitialized primitives by default being a massive footgun to only slightly worse than using Rust's unsafe core::mem::uninitialized function - which was deprecated in 2019. Now, sure, in a good language this mistake shouldn't even compile, so C++ moved from "Reprehensibly awful, do not use" to "Very bad". But that's more than a femtometer.
- array_key_first 1y ago
  C++ is much more safe than C and has numerous safety contracts that are impossible to represent in C. Its always weird when C and C++ are thrown together. Barne has talked about it, but one of the primary reasons he created C++ was to address safety issues in C. And he's talked about this since the early 90s. Like access modifiers and private by default. Something we take for granted now, but something which is impossible in C. Or std::vector. Unlike array in C, it won't blow up if you add too much stuff to it. Again, obvious, but at the time, revolutionary. Or exceptions! We take them for granted to! No more forgetting to check errno! No, if you don't catch an exception your program terminates, so you have to handle errors. Or, the biggest one of all: RAII and ownership. Might sound familiar to rust devs! Point is, C++ is not C. That's why C++ exists. Its not safe, but it's much, much safer.
  - Ygg2 1y ago
    > C++ is much more safe than C The issue Mozilla faced wasn't that it wasn't safer than C. It's that it was not safe enough for their needs. A chainsaw is safer than a saw blade; you still don't want to trim your beard with it. And the C++ working group, to this day, hasn't even moved one inch to accommodate those needs. As another commenter noted, they added a feature for C++26 that Rust abandoned circa 2019. They couldn't multithread the components like compositor and renderer as much as they would have liked, even with all the caveats.
the__alchemist 1y ago
Unfortunately, I don't think that's avoidable. This is equivalent to lamenting not being able to use Haskell-style pure FP, nor object inheritance. There are C++ (and C) design patterns that will just not work in rust, or won't work in an ergonomic way. The solution is to solve the problem in a different way. I will add a #3 to your list: Make an all-around nice language I think playing up rust as the memory-safe language underplays its value.
jchw 1y ago
To be honest I don't buy it. The biggest problem with translating programs to Rust, IMO anyway, isn't actually dealing with the chasm between mentalities regarding programming language design. I don't disagree that Rust intentionally goes a different way in many regards; obviously it focuses on composition over inheritance, and takes more inspiration from ML. But still, that isn't really the problem. It really does come down to the fact that appeasing the borrow checker is hard. It only accepts valid, well-formed programs according to its rules, but it rejects a ton of completely safe things in the process. It's a tradeoff. Literally just not being able to easily and efficiently express interior mutability completely changes how you design both code and APIs. Unsurprisingly, since they evolved in parallel, C++ is pretty well-suited for old-school widget toolkits like Qt, but Rust is not. It's not just a matter of having to retool things for composition... The entire view and data model just doesn't work very well. Instead with Rust you wind up seeing the vast majority of toolkits go for immediate mode or functional reactive flow designs that look like React. I'm not Rust expert but this is basically my opinion on what's really going on. I don't think it's a hatred of C/C++, especially since I think C especially translates to Rust perfectly well ignoring the borrow checker. Rust found one way to do safety and it does reject some valid code and make some patterns awkward or necessarily inefficient... There are others but it is clearly an area of open research.
- treyd 1y ago
  > Literally just not being able to easily and efficiently express interior mutability completely changes how you design both code and APIs. The issue is that fundamentally interior mutability is hard to reason about. It requires a lot more temporal reasoning to make sense of and ensure the safety of. Leaning into the type system Rust has does make interior mutability harder when you have "temporally based" safety arguments. It's a lot easier to reason about correctness in the model Rust uses. Have you looked at the godot-rust bindings? They've gone very far to make the Godot object system work well going between C++ Godot code and Rust. I would love to see that model adapted to Gtk.
waterTanuki 1y ago
C++ and C# share a letter only. They operate in entirely different domains. You can certainly try to write PLC logic or a an IMU Sensor in C#, but that's probably not going to be a fun task.
- derefr 1y ago
  C++ is used in many non-low-level domains simply because of performance, due to the many kinds of zero-runtime-overhead abstractions it offers. There are e.g. popular game engines written in C++. LLVM is written in C++. Some DBMSes are written in C++. Etc. C# overlaps C++ in all these “performance-sensitive high-level code” domains.
  - waterTanuki 1y ago
    Given the topic of the thread is DARPA it's unlikely they're going to benefit from the type of overlap C++ and C# have in game engines or DBMSes.
- bangaladore 1y ago
  I'm very familiar with both. My day job in defense is bare metal systems with C & C++ and often integrating them with C#-based test infrastructure. Is C# perfect for every task, no. But it's probably suitable for most of the tasks that DARPA is targeting to support. The reality is that low-level languages were used in the past because generally our computers were less efficient, and the higher-level languages didn't exist. Most things today written in C++ would probably be written in a higher-level language if designed today. Infact, I know of a specific case where a vendor is currently in hot water because a GUI tool running on a standard windows machine is not memory safe when in this case some agencies think it should be. This is probably similar to the vast majority of C++ code DARPA is concerned with.
dymk 1y ago
> They didn't like C/C++ What? > Quite a bit of idiomatic and safe (yes that does exist) C++ Reminds me of the “yes I’m vegan, yes I eat meat, we exist” meme.
- array_key_first 1y ago
  C++ is an unsafe language, but there is lots and lots of safe C++ code. Most C++ code is safe, that's why every other line isn't a segfault. Safety, as a whole, is about catching edge cases.
littlestymaar 1y ago
> Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting. How? If you're writing modern safe-ish (still very unsafe though) C++, then you're going to be avoiding shared mutability and using lots of smart pointers which translate straightforwardly to Rust.

adastra22 1y ago

Examples?

pizlonator 1y ago
Doubly linked lists. Any cyclic data structure.
- hackyhacky 1y ago
  Both of those are a direct consequence of Rust's memory model, not a result of animus against C++.
- JoshTriplett 1y ago
  That's not at all a "we don't like C++" problem. That's "the chosen borrow-checking model makes cyclic structures hard, you have to do Rc/Arc and some manual management, or use unsafe and raw pointers". (Frankly, the latter is easier.)
  - pizlonator 1y ago
    Ref counting doesn’t work for cyclic data structures
    - JoshTriplett 1y ago
      It doesn't fully handle the memory management, but it handles having shared references. You can use weak references or manually break the links when you want to free something. Or you can use unsafe raw pointers, which frankly seem simpler. Either way you're going to wrap it in a data structure that encapsulates all the details.
    - NobodyNada 1y ago
      Sure it does. Make the backreferences weak, or use a library that provides cycle detection (or even full-on tracing GC if you really want).
      - pizlonator 1y ago
        That changes the semantics. It won’t work for a graph for example.
        NobodyNada 1y ago
        Right. The comment you replied to said "Rc/Arc and some manual management" -- "some manual management" implying that you need to account for the change to semantics in the manner appropriate for your application.
        JoshTriplett 1y ago
        (Note that I edited my comment for clarity since the original reply. My original comment just said "reference counting".)
        pizlonator 1y ago
        The key part I agree with most in your edited comment is that unsafe raw pointers are the easiest way to deal with cycles. I think this is key. RC pointers don’t give you the ability to say: ok, I now know that this subset of the graph is dead because reasons so delete it. In RC, you’d have to walk the graph to break cycles. That’s a rather important difference from how you’d manage a cyclic data structure in C, C++, Java, C#, or any GC’d language. In C/C++, you’d delete what you know to be dead; in Java et al it would be enough to kill the references that point at the outer edges of the dead subgraph. But you wouldn’t have to walk the subgraph to detangle the cycle. I think it really is worse than that; ie as you say, folks will just do anything but RC in that case. In Rust the safe bet would be to just shove all the nodes into an array and use indices (yuck!!!). But likely a lot of code with use raw pointers instead (also yuck). The whole thing where you reference count cyclic data structures is just too painful for sensible people
- jnwatson 1y ago
  While I think this is Rust's biggest flaw, this doesn't stem from any particular hatred of C/C++. This is related to memory safety, as it is very difficult to reason about memory lifetimes of object graphs with cycles.
- adastra22 1y ago
  The easiest way to implement these is with Weak references in one of the directions. This requires some checking and/or locks, but the fact it is not trivial to do is kinda the point: the integrity of a cyclic data structure depends on managing multiple pointers in multiple structs simultaneously, and with that comes concurrency dragons.
- treyd 1y ago
  There are doubly-linked list libraries in Rust. They are safe and well-designed. It's rare for a project to actually need a doubly-linked list. When you need it, you should use those instead of reimplementing your own.
actionfromafar 1y ago
Syntax is different any many places for no apparent reason
bangaladore 1y ago
My best example of a "real" and not more artificial example (like XYZ data structure) is Game development / game engines & UI. For reference: https://news.ycombinator.com/item?id=40172033 https://news.ycombinator.com/item?id=40172033
- adastra22 1y ago
  A bit surprised that you didn’t mention Bevy in your post. Have you worked with it?
  - bangaladore 1y ago
    Not my post, but I've heard the same concerns with Bevy as with the others. And the actual blog post linked by that post does mention Bevy many times. Infact Bevy might be a perfect example of my gripe(s) with Rust. Completely throwing a standard object system out the window in-favor of ECS which still hasn't caught on in even the most used game engines like Unity hurts adoption and usability.
    - adastra22 1y ago
      I thought Unity and Unreal were transiting to ECS? I was under the impression at least that Bevy was adopting what the industry was moving towards, not exploring virgin territory.
      - bangaladore 1y ago
        I'd very much consider ECS virgin territory. DOTS (ECS) in Unity has been out for 5+ years with little to no real adoption. I'm unaware of any pretty much any use of ECS in Unreal (I think what exists is mostly focused on internal graphics / animation, not gameplay).

convolvatron 1y ago

I don't think #2 is at all fair. I'm certainly of two minds about Rust and its ergonomics. But #2 seems to assume that C is some kind of default and canonical programming model, and to the extent that I like rust, its because they made different and internally consistent design choices.

bangaladore 1y ago
C/C++ is the "default" language they are/were trying to replace with Rust. So I think it's fair to point out that Rust made design decisions explicitly contrary to design decisions of C/C++ style languages even though Rust is meant to replace it. That's going to (and does cause) problems.
- kibwen 1y ago
  > design decisions explicitly contrary to design decisions of C/C++ style languages even though Rust is meant to replace it Yes, but that doesn't have to do with whether they "like" C++ or not. What they "liked" is a programming model that could possibly be theoretically proven safe by any sort of tractable static analysis, and that inevitably means making decisions contrary to C/C++. Achieving their design goals was more important than adhering to C++'s mistakes for sentimental reasons.
  - bangaladore 1y ago
    You are confusing problem 1 (memory / thread safety) with problem 2 (being distinct from C/C++). I'm not here to argue about changes made that are necessary to solve problem 1, but I'm also not here to pretend that all the differences Rust has compared to a C-style language like C/C++/C# is largely due to supporting memory / thread safety.
    - kibwen 1y ago
      You continue vaguely asserting "differences" and then retreating when challenged. So please be specific: what differences?

Ygg2 1y ago

> They didn't like C/C++ Riiiight. You do realize they made syntax similar to C/C++ on purpose to ease Mozilla's C/C++ programmers into it. It's not that they didn't like it; it's that C/C++ is about as disinterested in memory/thread safety as you can get. It's been what, ten years since Rust became 1.0? And the safety needle of C++ hasn't budged a femtometer. > Quite a bit of idiomatic and safe (yes that does exist) C++ Sure, so does legible Brainfuck. However, it's extremely challenging to write it. It usually takes years and years of effort, chasing down obscure bugs. > Like converting C++ to C#. If you can take GC pause and not wince, sure, go for it. Not everyone can take that luxury.

tialaramex 1y ago
> And the safety needle of C++ hasn't budged a femtometer. That's not fair. C++ 26 gets from the uninitialized primitives by default being a massive footgun to only slightly worse than using Rust's unsafe core::mem::uninitialized function - which was deprecated in 2019. Now, sure, in a good language this mistake shouldn't even compile, so C++ moved from "Reprehensibly awful, do not use" to "Very bad". But that's more than a femtometer.
array_key_first 1y ago
C++ is much more safe than C and has numerous safety contracts that are impossible to represent in C. Its always weird when C and C++ are thrown together. Barne has talked about it, but one of the primary reasons he created C++ was to address safety issues in C. And he's talked about this since the early 90s. Like access modifiers and private by default. Something we take for granted now, but something which is impossible in C. Or std::vector. Unlike array in C, it won't blow up if you add too much stuff to it. Again, obvious, but at the time, revolutionary. Or exceptions! We take them for granted to! No more forgetting to check errno! No, if you don't catch an exception your program terminates, so you have to handle errors. Or, the biggest one of all: RAII and ownership. Might sound familiar to rust devs! Point is, C++ is not C. That's why C++ exists. Its not safe, but it's much, much safer.
- Ygg2 1y ago
  > C++ is much more safe than C The issue Mozilla faced wasn't that it wasn't safer than C. It's that it was not safe enough for their needs. A chainsaw is safer than a saw blade; you still don't want to trim your beard with it. And the C++ working group, to this day, hasn't even moved one inch to accommodate those needs. As another commenter noted, they added a feature for C++26 that Rust abandoned circa 2019. They couldn't multithread the components like compositor and renderer as much as they would have liked, even with all the caveats.

the__alchemist 1y ago

Unfortunately, I don't think that's avoidable. This is equivalent to lamenting not being able to use Haskell-style pure FP, nor object inheritance. There are C++ (and C) design patterns that will just not work in rust, or won't work in an ergonomic way. The solution is to solve the problem in a different way. I will add a #3 to your list: Make an all-around nice language I think playing up rust as the memory-safe language underplays its value.

jchw 1y ago

To be honest I don't buy it. The biggest problem with translating programs to Rust, IMO anyway, isn't actually dealing with the chasm between mentalities regarding programming language design. I don't disagree that Rust intentionally goes a different way in many regards; obviously it focuses on composition over inheritance, and takes more inspiration from ML. But still, that isn't really the problem. It really does come down to the fact that appeasing the borrow checker is hard. It only accepts valid, well-formed programs according to its rules, but it rejects a ton of completely safe things in the process. It's a tradeoff. Literally just not being able to easily and efficiently express interior mutability completely changes how you design both code and APIs. Unsurprisingly, since they evolved in parallel, C++ is pretty well-suited for old-school widget toolkits like Qt, but Rust is not. It's not just a matter of having to retool things for composition... The entire view and data model just doesn't work very well. Instead with Rust you wind up seeing the vast majority of toolkits go for immediate mode or functional reactive flow designs that look like React. I'm not Rust expert but this is basically my opinion on what's really going on. I don't think it's a hatred of C/C++, especially since I think C especially translates to Rust perfectly well ignoring the borrow checker. Rust found one way to do safety and it does reject some valid code and make some patterns awkward or necessarily inefficient... There are others but it is clearly an area of open research.

treyd 1y ago
> Literally just not being able to easily and efficiently express interior mutability completely changes how you design both code and APIs. The issue is that fundamentally interior mutability is hard to reason about. It requires a lot more temporal reasoning to make sense of and ensure the safety of. Leaning into the type system Rust has does make interior mutability harder when you have "temporally based" safety arguments. It's a lot easier to reason about correctness in the model Rust uses. Have you looked at the godot-rust bindings? They've gone very far to make the Godot object system work well going between C++ Godot code and Rust. I would love to see that model adapted to Gtk.

waterTanuki 1y ago

C++ and C# share a letter only. They operate in entirely different domains. You can certainly try to write PLC logic or a an IMU Sensor in C#, but that's probably not going to be a fun task.

derefr 1y ago
C++ is used in many non-low-level domains simply because of performance, due to the many kinds of zero-runtime-overhead abstractions it offers. There are e.g. popular game engines written in C++. LLVM is written in C++. Some DBMSes are written in C++. Etc. C# overlaps C++ in all these “performance-sensitive high-level code” domains.
- waterTanuki 1y ago
  Given the topic of the thread is DARPA it's unlikely they're going to benefit from the type of overlap C++ and C# have in game engines or DBMSes.
bangaladore 1y ago
I'm very familiar with both. My day job in defense is bare metal systems with C & C++ and often integrating them with C#-based test infrastructure. Is C# perfect for every task, no. But it's probably suitable for most of the tasks that DARPA is targeting to support. The reality is that low-level languages were used in the past because generally our computers were less efficient, and the higher-level languages didn't exist. Most things today written in C++ would probably be written in a higher-level language if designed today. Infact, I know of a specific case where a vendor is currently in hot water because a GUI tool running on a standard windows machine is not memory safe when in this case some agencies think it should be. This is probably similar to the vast majority of C++ code DARPA is concerned with.

dymk 1y ago

> They didn't like C/C++ What? > Quite a bit of idiomatic and safe (yes that does exist) C++ Reminds me of the “yes I’m vegan, yes I eat meat, we exist” meme.

array_key_first 1y ago
C++ is an unsafe language, but there is lots and lots of safe C++ code. Most C++ code is safe, that's why every other line isn't a segfault. Safety, as a whole, is about catching edge cases.

littlestymaar 1y ago

> Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting. How? If you're writing modern safe-ish (still very unsafe though) C++, then you're going to be avoiding shared mutability and using lots of smart pointers which translate straightforwardly to Rust.