4 ms·

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that

by whazor 4y ago

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far to be doing this in Rust, whereas I would not want to try this in C++. The code I am writing is much simpler than the existing C++ code.

blub 4y ago
Where's the proof that Rust makes it easier and faster to create applications? In my experience it's harder and slower compared to other languages like Go and even C++, but you get memory-safety in return while keeping a very good runtime performance profile.
- tcfhgj 4y ago
  I have been way more productive with Rust than with C++. For instance, I haven't yet had to debug weirdly muting memory, deal with the immense nuanced possibilities of doing the same thing (there's a reason for CPP core guidelines), stuff like the rule of five, writing cross platform cmake files that include various libraries, ... Not proof for a general statement, but another example from a Rust adaptor
  - deleted 4y ago
    [deleted]
- crabbygrabby 4y ago
  Rust removes a lot of the debugging and performance tuning, that happens later in production. Is it easier/faster while you are learning. Nope. When you understand it, sure it could be. This depends on the person. Just like how someone might be faster or slower at a specific framework within the same language. Imo I write programs faster than other languages because the compiler helps me out. Your mileage may vary.
lenkite 4y ago
"Things that are hard in Rust, are even harder in C and C++." Incorrect. This handler-dispatcher problem illustrated in the article is utterly trivial in C++ and many programming languages. No need to struggle and stretch your brain as if you are in the Math olympiad. I am learning Rust myself and I think Rust fans are spreading misinformation and propaganda by saying Rust makes things easier than other languages. No, Rust makes things VERY difficult - and you need to study and learn the Rust way of doing things - which is significantly different from other programming languages. We need a BIG design patterns for Rust book - which takes lots of common design problems and shows the idiomatic Rust way of doing it. But just stating that C++ code for a given design problem is harder than Rust is utterly wrong and demonstrably false. Rust tooling is definitely simpler. Rust coding is definitely not.
- pkolaczk 4y ago
  This handler dispatcher problem gets trivial if you do it in unsafe mode. Just transmute all lifetimes to 'static and call it a day. That is what you do in C++ all the time (implicitly). So C++ version of it would be easier to get compiling, but harder to get right - because you'd have to prove lifetimes are correct anyways.
- crabbygrabby 4y ago
  Would you agree that it is "easier to do it correctly?" Because rust makes lifetimes explicit? I think that's what rustaceans are trying to say generally. I don't think anyone is trying to claim that rust is some trivial language. It's not. But it makes systems level concerns explicit, flying blind is much harder in my opinion. The complexity is technically the same, but the language has training wheels that other languages don't.
  - preseinger 4y ago
    "Correct" isn't a boolean condition of a program.
logicchains 4y ago
>Things that are hard in Rust, are even harder in C and C++ This is absolutely not true. Something hard in Rust but almost trivial in C++ (via fold expressions): mapping or folding a function or operator over a tuple of heterogeneous types. E.g. to sum over a tuple of arbitrary numeric types: auto mySum = std::apply([](auto... x){ return (x + ...); }, myTuple);
- Shikadi 4y ago
  Wouldn't this be a nearly identical call, but specifying the add trait? I'm still learning so I'm not sure if I'm missing something
- crabbygrabby 4y ago
  This is a pretty weird example. Why do you want to sum over a tuple of different data types in the first place? This kind of has a code smell I can't put my finger on... Fwiw rust doesn't let you dynamically index tuples, because rusts' take on tuples is different. Should your tuple actually be a struct with a "sum" method on it? Imo probably. Or should you have your numeric types be the same type for better memory layout, maybe... Just because another language let's you do something doesn't mean you should do it. Kind of like in js, does it make sense to divide a number by a string(not sure if you can do this but guessing it's valid js), probably not, is it a feature or a bug, you decide. Should this be part of say the kotlin standard, probably not.
jandrewrogers 4y ago
> Things that are hard in Rust, are even harder in C and C++. That is not true of C++. There are many valuable things that are much easier to express in C++ than Rust, owing to C++ being a significantly more expressive language. Rust also doesn't make it easy to write software where ownership is intrinsically ambiguous and must be algorithmically resolved at runtime without wrapping the object, a common case e.g. for high-performance storage. I would agree that everything is harder in C, though.

by whazor 4y ago

blub 4y ago

Where's the proof that Rust makes it easier and faster to create applications? In my experience it's harder and slower compared to other languages like Go and even C++, but you get memory-safety in return while keeping a very good runtime performance profile.

tcfhgj 4y ago
I have been way more productive with Rust than with C++. For instance, I haven't yet had to debug weirdly muting memory, deal with the immense nuanced possibilities of doing the same thing (there's a reason for CPP core guidelines), stuff like the rule of five, writing cross platform cmake files that include various libraries, ... Not proof for a general statement, but another example from a Rust adaptor
- deleted 4y ago
  [deleted]
crabbygrabby 4y ago
Rust removes a lot of the debugging and performance tuning, that happens later in production. Is it easier/faster while you are learning. Nope. When you understand it, sure it could be. This depends on the person. Just like how someone might be faster or slower at a specific framework within the same language. Imo I write programs faster than other languages because the compiler helps me out. Your mileage may vary.

lenkite 4y ago

"Things that are hard in Rust, are even harder in C and C++." Incorrect. This handler-dispatcher problem illustrated in the article is utterly trivial in C++ and many programming languages. No need to struggle and stretch your brain as if you are in the Math olympiad. I am learning Rust myself and I think Rust fans are spreading misinformation and propaganda by saying Rust makes things easier than other languages. No, Rust makes things VERY difficult - and you need to study and learn the Rust way of doing things - which is significantly different from other programming languages. We need a BIG design patterns for Rust book - which takes lots of common design problems and shows the idiomatic Rust way of doing it. But just stating that C++ code for a given design problem is harder than Rust is utterly wrong and demonstrably false. Rust tooling is definitely simpler. Rust coding is definitely not.

pkolaczk 4y ago
This handler dispatcher problem gets trivial if you do it in unsafe mode. Just transmute all lifetimes to 'static and call it a day. That is what you do in C++ all the time (implicitly). So C++ version of it would be easier to get compiling, but harder to get right - because you'd have to prove lifetimes are correct anyways.
crabbygrabby 4y ago
Would you agree that it is "easier to do it correctly?" Because rust makes lifetimes explicit? I think that's what rustaceans are trying to say generally. I don't think anyone is trying to claim that rust is some trivial language. It's not. But it makes systems level concerns explicit, flying blind is much harder in my opinion. The complexity is technically the same, but the language has training wheels that other languages don't.
- preseinger 4y ago
  "Correct" isn't a boolean condition of a program.

logicchains 4y ago

>Things that are hard in Rust, are even harder in C and C++ This is absolutely not true. Something hard in Rust but almost trivial in C++ (via fold expressions): mapping or folding a function or operator over a tuple of heterogeneous types. E.g. to sum over a tuple of arbitrary numeric types: auto mySum = std::apply([](auto... x){ return (x + ...); }, myTuple);

Shikadi 4y ago
Wouldn't this be a nearly identical call, but specifying the add trait? I'm still learning so I'm not sure if I'm missing something
crabbygrabby 4y ago
This is a pretty weird example. Why do you want to sum over a tuple of different data types in the first place? This kind of has a code smell I can't put my finger on... Fwiw rust doesn't let you dynamically index tuples, because rusts' take on tuples is different. Should your tuple actually be a struct with a "sum" method on it? Imo probably. Or should you have your numeric types be the same type for better memory layout, maybe... Just because another language let's you do something doesn't mean you should do it. Kind of like in js, does it make sense to divide a number by a string(not sure if you can do this but guessing it's valid js), probably not, is it a feature or a bug, you decide. Should this be part of say the kotlin standard, probably not.

jandrewrogers 4y ago

> Things that are hard in Rust, are even harder in C and C++. That is not true of C++. There are many valuable things that are much easier to express in C++ than Rust, owing to C++ being a significantly more expressive language. Rust also doesn't make it easy to write software where ownership is intrinsically ambiguous and must be algorithmically resolved at runtime without wrapping the object, a common case e.g. for high-performance storage. I would agree that everything is harder in C, though.