4 ms·

I appreciate that you're trying to frame this as areas where all of these languages can be successful in these spaces, but for Rust in particular, this is an od

I appreciate that you're trying to frame this as areas where all of these languages can be successful in these spaces, but for Rust in particular, this is an odd take: "In order to be a system language AND also do everything that people want a system language to do (games, embedded, high performance) you need (I assert) to have rough edges and dangerous pit falls. "Rust will eventually beat C/C++ on making web browsers and similar technologies because that's what it was built to do. However, Rust probably won't be able to beat C/C++ in game development and total OS development (although it can probably be partially used for both)." Rust has all the necessary escape hatches (through unsafe) required for these spaces. There are people working in these spaces with Rust successfully, today. So, while, the other languages you mention might find success here as well, there is no reason (from a technical perspective) that Rust will not.

jandrewrogers 7y ago
The caveat here is that some correct software architectures require littering so much "unsafe" in the code (due to incompatible safety models, not actual unsafe-ness) that it largely defeats the purpose, and a software architecture that lets you avoid most "unsafe" produces a worse product while requiring more lines of code to accomplish the same thing. Rust will always leave plenty of room for C++ to the extent that it tacitly encourages suboptimal software architecture for some types of applications, such as database engines, that commonly rely on safety models Rust was not designed to express. I do see Rust potentially replacing a lot of backend Java, eventually.
- Verdex 7y ago
  I'm glad you commented because this is what I wanted to say, but couldn't think of a good way to lead into it. IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. Uniqueness is really useful for most applications, but there are times that you want data structures that allow multiple pointers to the same data. Having to do this in Rust is going to be a bigger chore than doing it in a language that doesn't support uniqueness. It will be possible for Rust to still participate in these areas (especially because you can use Rust for only part of your project, so you can use it where you don't have allocation or nonuniqueness constraints in your problem space). However, other options are going to offer a better programmer experience.
  - steveklabnik 7y ago
    > IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. So, sort of yes, and sort of no. Like, you can swap the global allocator, but there's no way to parameterize standard library stuff over anything but the given allocator. But for your own code, you can write and use allocators however you want. Arenas are often popular, for example.
- bluejekyll 7y ago
  > such as database engines, that commonly rely on safety models Rust was not designed to express. Do you think you could expand on this? From my experience Rust facilitates all the same operations as either C or C++, and generally without even needing to turn to unsafe. What I've found in my own (not DB, but networking) work, is that Rust generally asks you to restate the problem in a way that will allow it to be best expressed in Rust. This often differs from the down the middle of the road implementations people have grown used to in other languages, but it doesn't in any meaningful way prevent you from solving the problem, in a safe way.
  - jandrewrogers 7y ago
    There are a couple common architectural patterns that are easy to express in C++ but tend to violate assumptions in Rust's safety model. Database engines run into them frequently due to the nature of their core operations, and this ignores that most data structures are intrinsically globals (which Rust doesn't like) due to tight hardware coupling. Rust assumes that all references to memory are visible at compile-time, and the safety analysis can be applied in cases where this is true with the usual caveats around borrow-checking. The "unsafe" facility is designed to interface with code written in other languages that don't respect Rust's model, and it works well for that. But how do you express the case, common in database engines (because direct storage-backed), where hardware can hold mutable references to most of your address space? There is no way to determine at compile-time if a mutable reference will be unique at runtime or to even sandbox it to a small bit of code. As a consequence, most memory reference are effectively mutable. There are workarounds that will minimize the quantity of unsafe code in Rust if you are willing to sacrifice performance and elegance. In databases, having many mutable references to the same memory has few safety implications because ownership of memory is dynamically assigned at runtime by a scheduler that guarantees safe access without locking or blocking. This safety model solves the hardware ownership problem, which is why it is used, but it also enables quite a bit of dynamic optimization even if all your references are in software so you'd want to do things this way anyway. In C++, you can make all of this largely transparent on top of explicitly mutable references to memory. Again, you can produce a minimally unsafe version of this in Rust but it is going to be significantly uglier and slower. As more server software moves to userspace I/O and scheduling models (for performance and scale reasons) it will be interesting to see how this impedance mismatch problem is addressed in Rust.
- apta 7y ago
  > I do see Rust potentially replacing a lot of backend Java, eventually. I'm not quite so sure. Rust can be a good fit for services that need to be very optimized for memory or CPU usage. Java brings so many other extremely important benefits like introspection, management, profiling, hot swapping, and being generally more productive due to the fact that it's a GC'd language. Not to mention the huge ecosystem behind it.
- nickpsecurity 7y ago
  That's all or nothing thinking. Enough people do it that what you say will probably happen. Thing is, one can always use multiple tools to achieve their goal. Anything Rust's safety model can't handle might be done with a different model, analyzer, etc. One recommendation I keep at is using "unsafe" Rust, porting it to identical C, throwing every tool we have in C ecosystem at it, and port what passes back to Rust with safe wrappers if possible. Rust couldn't prove it safe, it's externally proven safe (or safe enough), and optionally has protections during interactions via wrappers. You get Rust's benefits on everything else you code in the app plus whatever you include that others manage to get past borrow checker. I call this general concept Brute-Force Assurance where you just modify the form of a program to fit existing tools to get their benefits. Just throw every sound and/or complete analyzer plus a lot of test generators at it. Also, code in a way that helps those tools wherever possible. If one can't, then use them on a version designed for verification first to get the algorithm right, step it toward optimized version, equivalence tests, repeat, etc.
pron 7y ago
There's one escape hatch that Rust doesn't have: a hatch to escape its complexity. These days I do most of my programming in C++, and my first requirement from the language that will replace it for me is that it be simple rather than a shrine to accidental complexity. So I'm looking at Zig and liking what I see so far. I also think its approach to correctness is ultimately less disappointing than Rust's (as it is now) but that's a whole other discussion. Of course, these are personal preferences rather than some universal claims, although when I bet on a programming language I also care about future popularity, and complex languages tend to never gain more than small niche adoption. Anyway, Rust and Zig have such diametrically opposed design philosophies for low-level (AKA systems) programming, that it will be interesting to see their respective adoption dynamics. If, despite my prediction, Rust ends up being more popular, I'll probably prefer it to C++ and use it.
- Verdex 7y ago
  I'm a huge proponent of static typing systems. However, that being said, I always keep in mind that everything has a cost. * Just because I'm more comfortable with types doesn't mean that everyone else is. * Someone may want to do something in a type system which is well typed, but only in a different type system. * Someone may want to do something in a a type system which is well typed, but which has some bad compilation characteristics for the given type system. Even if Rust is objectively better, you still have to get used to the things about it that make it objectively better. And you have to keep up with the changes that are made to it. And you have to understand where those better things fail down (for example Non Lexical Lifetimes ... in which case you have to get used to the NLL acronym that people use). A simpler language, even if objectively worse, can yield better results if it is used with discipline. Discipline that might be easier to hone with less things that need to be considered. And sometimes better results don't actually matter because the goal isn't the best results tomorrow but reasonably adequate results today.
  - pron 7y ago
    As, despite our efforts, we haven't been able to find big differences between different languages (considering reasonable choices for the appropriate domain) in any important bottom-line metrics, neither in research nor in industry, I don't think there's much point in even mentioning objective value. The only scientifically acceptable working assumption at this point is that language choice (with the caveat above) makes no significant objective difference. It's like saying, even if rum-raisin ice cream gives us the ability to see through walls I still prefer pizza; we have no reason to believe rum-raisin ice cream does that, so why even mention it? As far as we know, it's all about personal preference -- we have no reason whatsoever to believe that either Rust or Zig are objectively better or worse than the other -- as well as some easily observable secondary objective differences such as popularity.

jandrewrogers 7y ago

The caveat here is that some correct software architectures require littering so much "unsafe" in the code (due to incompatible safety models, not actual unsafe-ness) that it largely defeats the purpose, and a software architecture that lets you avoid most "unsafe" produces a worse product while requiring more lines of code to accomplish the same thing. Rust will always leave plenty of room for C++ to the extent that it tacitly encourages suboptimal software architecture for some types of applications, such as database engines, that commonly rely on safety models Rust was not designed to express. I do see Rust potentially replacing a lot of backend Java, eventually.

Verdex 7y ago
I'm glad you commented because this is what I wanted to say, but couldn't think of a good way to lead into it. IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. Uniqueness is really useful for most applications, but there are times that you want data structures that allow multiple pointers to the same data. Having to do this in Rust is going to be a bigger chore than doing it in a language that doesn't support uniqueness. It will be possible for Rust to still participate in these areas (especially because you can use Rust for only part of your project, so you can use it where you don't have allocation or nonuniqueness constraints in your problem space). However, other options are going to offer a better programmer experience.
- steveklabnik 7y ago
  > IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. So, sort of yes, and sort of no. Like, you can swap the global allocator, but there's no way to parameterize standard library stuff over anything but the given allocator. But for your own code, you can write and use allocators however you want. Arenas are often popular, for example.
bluejekyll 7y ago
> such as database engines, that commonly rely on safety models Rust was not designed to express. Do you think you could expand on this? From my experience Rust facilitates all the same operations as either C or C++, and generally without even needing to turn to unsafe. What I've found in my own (not DB, but networking) work, is that Rust generally asks you to restate the problem in a way that will allow it to be best expressed in Rust. This often differs from the down the middle of the road implementations people have grown used to in other languages, but it doesn't in any meaningful way prevent you from solving the problem, in a safe way.
- jandrewrogers 7y ago
  There are a couple common architectural patterns that are easy to express in C++ but tend to violate assumptions in Rust's safety model. Database engines run into them frequently due to the nature of their core operations, and this ignores that most data structures are intrinsically globals (which Rust doesn't like) due to tight hardware coupling. Rust assumes that all references to memory are visible at compile-time, and the safety analysis can be applied in cases where this is true with the usual caveats around borrow-checking. The "unsafe" facility is designed to interface with code written in other languages that don't respect Rust's model, and it works well for that. But how do you express the case, common in database engines (because direct storage-backed), where hardware can hold mutable references to most of your address space? There is no way to determine at compile-time if a mutable reference will be unique at runtime or to even sandbox it to a small bit of code. As a consequence, most memory reference are effectively mutable. There are workarounds that will minimize the quantity of unsafe code in Rust if you are willing to sacrifice performance and elegance. In databases, having many mutable references to the same memory has few safety implications because ownership of memory is dynamically assigned at runtime by a scheduler that guarantees safe access without locking or blocking. This safety model solves the hardware ownership problem, which is why it is used, but it also enables quite a bit of dynamic optimization even if all your references are in software so you'd want to do things this way anyway. In C++, you can make all of this largely transparent on top of explicitly mutable references to memory. Again, you can produce a minimally unsafe version of this in Rust but it is going to be significantly uglier and slower. As more server software moves to userspace I/O and scheduling models (for performance and scale reasons) it will be interesting to see how this impedance mismatch problem is addressed in Rust.
apta 7y ago
> I do see Rust potentially replacing a lot of backend Java, eventually. I'm not quite so sure. Rust can be a good fit for services that need to be very optimized for memory or CPU usage. Java brings so many other extremely important benefits like introspection, management, profiling, hot swapping, and being generally more productive due to the fact that it's a GC'd language. Not to mention the huge ecosystem behind it.
nickpsecurity 7y ago
That's all or nothing thinking. Enough people do it that what you say will probably happen. Thing is, one can always use multiple tools to achieve their goal. Anything Rust's safety model can't handle might be done with a different model, analyzer, etc. One recommendation I keep at is using "unsafe" Rust, porting it to identical C, throwing every tool we have in C ecosystem at it, and port what passes back to Rust with safe wrappers if possible. Rust couldn't prove it safe, it's externally proven safe (or safe enough), and optionally has protections during interactions via wrappers. You get Rust's benefits on everything else you code in the app plus whatever you include that others manage to get past borrow checker. I call this general concept Brute-Force Assurance where you just modify the form of a program to fit existing tools to get their benefits. Just throw every sound and/or complete analyzer plus a lot of test generators at it. Also, code in a way that helps those tools wherever possible. If one can't, then use them on a version designed for verification first to get the algorithm right, step it toward optimized version, equivalence tests, repeat, etc.

pron 7y ago

There's one escape hatch that Rust doesn't have: a hatch to escape its complexity. These days I do most of my programming in C++, and my first requirement from the language that will replace it for me is that it be simple rather than a shrine to accidental complexity. So I'm looking at Zig and liking what I see so far. I also think its approach to correctness is ultimately less disappointing than Rust's (as it is now) but that's a whole other discussion. Of course, these are personal preferences rather than some universal claims, although when I bet on a programming language I also care about future popularity, and complex languages tend to never gain more than small niche adoption. Anyway, Rust and Zig have such diametrically opposed design philosophies for low-level (AKA systems) programming, that it will be interesting to see their respective adoption dynamics. If, despite my prediction, Rust ends up being more popular, I'll probably prefer it to C++ and use it.

Verdex 7y ago
I'm a huge proponent of static typing systems. However, that being said, I always keep in mind that everything has a cost. * Just because I'm more comfortable with types doesn't mean that everyone else is. * Someone may want to do something in a type system which is well typed, but only in a different type system. * Someone may want to do something in a a type system which is well typed, but which has some bad compilation characteristics for the given type system. Even if Rust is objectively better, you still have to get used to the things about it that make it objectively better. And you have to keep up with the changes that are made to it. And you have to understand where those better things fail down (for example Non Lexical Lifetimes ... in which case you have to get used to the NLL acronym that people use). A simpler language, even if objectively worse, can yield better results if it is used with discipline. Discipline that might be easier to hone with less things that need to be considered. And sometimes better results don't actually matter because the goal isn't the best results tomorrow but reasonably adequate results today.
- pron 7y ago
  As, despite our efforts, we haven't been able to find big differences between different languages (considering reasonable choices for the appropriate domain) in any important bottom-line metrics, neither in research nor in industry, I don't think there's much point in even mentioning objective value. The only scientifically acceptable working assumption at this point is that language choice (with the caveat above) makes no significant objective difference. It's like saying, even if rum-raisin ice cream gives us the ability to see through walls I still prefer pizza; we have no reason to believe rum-raisin ice cream does that, so why even mention it? As far as we know, it's all about personal preference -- we have no reason whatsoever to believe that either Rust or Zig are objectively better or worse than the other -- as well as some easily observable secondary objective differences such as popularity.