3 ms·

Good question then: how is the "occasianal's programmer" experience compare between Rust and C++? I used to write games in C++ as a teenager, and using it dail

Good question then: how is the "occasianal's programmer" experience compare between Rust and C++? I used to write games in C++ as a teenager, and using it daily was fine. Now I find, every time I try to write something in it, it's a massive pain, as I forget the myriad of tiny rules, the very specific ways to write types etc. And that's before I even think about dependency management. Is Rust substantially better at this? When I read frustrations about Rust, it seems to be mostly about the Borrow Checker... does that affect "pedestrian" code, like "take this 4-dimensional array and munge it with an arcane for-loop"? Or, here's a basic immutable class with some fields and some methods, make it available in Python? I'm liking the look of Nim because it is concise, safe and fast-ish, so a good companion to Python. I dislike C++ as that companion because, even though once you've written your code, it integrates very well with Python, it's a lot of pain to get there. Where would Rust fit in this picture?

rapsey 4y ago
Rust users are very enthusiastic about Rust, because it fixes so much annoying shit you have to deal with in C/C++. It really brings back a lot of joy to programming. The borrow checker is an issue when you are a beginner and have to unlearn all the bad practices you were doing in C/C++.
- rob74 4y ago
  I would say the borrow checker is an issue if you come from most other mainstream languages, because Rust's approach of trying to automate memory management without having a garbage collector is quite unique. Also, as a person interested in Rust, but who hasn't yet found the time (and strength of mind) to really commit to learning it: the main difference between C++ and Rust is the cruft that C++ has accumulated over the decades, which Rust doesn't have because it's much younger. But seeing the pace of new features introduced into Rust, I'm a bit worried that some of the older features will soon be declared "non-best practice" and turn into C++-style cruft.
  - timeon 4y ago
    > But seeing the pace of new features introduced into Rust, I'm a bit worried that some of the older features will soon be declared "non-best practice" and turn into C++-style cruft. Is it just because you see additions of new features in general or there are some specific issues? For me new features do not make 'bad practice' from old ways. As example in older versions you had to be more explicit with lifetimes, but that is just convenience.
  - tialaramex 4y ago
    Rust's Edition system allows it to deprecate and eventually remove syntax that's now considered a mistake, yet that syntax still exists (forever!) for anybody who doesn't want to learn the modern way to write it. Let's take two serious C++ proposals I've looked at over the past years and imagine if it had Editions (it doesn't, Vittorio's similar Epochs proposal was shot down and won't be coming back). First a try operator. C++ doesn't have one of these, it would be usual to spell it ? but that's prohibited in C++ by the existence of a ? character as part of the ternary operator ?:. If you had Editions you could abolish ?: in a new Edition or change the way it is parsed so that some weird utterances now don't work because ? is the try operator, without them the proposers instead reluctantly suggest ?? (which is already an operator in some languages and it isn't try...) Second, pattern matching with _ as a wildcard in the pattern. C++ doesn't do that today. Unfortunately _ is a valid identifier in C++ and people use it. Not a lot of people, but enough for it to be a real pain if this stopped working. So the proposers reluctantly suggest you could write __ in this case. If you had Editions you could forbid _ in a new Edition and in that Edition have the nicer _ while __ is provided in older Editions if they want new pattern matching. Editions only cover syntax (they're actually mutating the Abstract Syntax Tree at compile time) but because this affords some great opportunities for backward compatible changes, it encourages people to get creative and do even more. For example Rust's arrays learned to be IntoIterator. But that's not a syntax change, so how did that remain compatible? Well, there's a hack, if you have an edition prior to 2021 Edition, then one function from IntoIterator is hidden from resolution by the hack, so that array.into_iter() does what it did in your edition before arrays were IntoIterator. But every other feature works, so you can write "for thing in array", you can pass arrays to functions which need an iterator, and so on, and in newer editions the hack isn't used so array.into_iter() does what you'd expect given arrays are now IntoIterator.
pizza234 4y ago
> Is Rust substantially better at this? When I read frustrations about Rust, it seems to be mostly about the Borrow Checker... does that affect "pedestrian" code, like "take this 4-dimensional array and munge it with an arcane for-loop"? Or, here's a basic immutable class with some fields and some methods, make it available in Python? I think language complexity in general is not a problem; language consistency is. I find Rust complex, but not inconsistent or surprising (with exceptions). I'd say that yes, it is substantially better in this regard. Regarding the "pedestrian code", it depends. Rust is very unergonomic for algorithms, due to its handling of bidirectional references. However, some algorithms/data structures may work fine; the matrix operation you refer to can be very easy to work with, if the elements are Clone/Copy, which numbers are. I'm a Rust fan, but the article seems to be a puff piece; it takes one case and generalizes it. I also think that Rust is not productive [than other easy, compiled, languages] for generic programming, at least, without significant experience. Relatively small programs (I don't know the size of the typical scientific programs in academia) may be easier, but once a program grows, it definitely requires an amount of design (due to ownership) that other languages don't require.
- rich_sasha 4y ago
  > I think language complexity in general is not a problem; language consistency is. With C++ I do find human medium-term cache capacity to be an issue. By the time I use C++ again, I forget some of the many little things I need just to compile a glorified "fizz-buzz". Things like, is this a pointer to a const or a const pointer? What's the syntax for a move/copy constructor? Keeping headers and cpp files in sync. What's the flag to enable modern C++ extensions? How do I write this lambda? Or make a pointer to a function? And so on...
- Animats 4y ago
  > the article seems to be a puff piece; it takes one case and generalizes it. Agreed. I write mostly in Rust, but I don't recommend it unless you have a hard problem. If you need C/C++ speed, and there's enough complicated state coordination that you need safe threading and allocation control, Rust is useful. For typical webcrap, use Go. That's the job for which Google created Go.
qsort 4y ago
> the Borrow Checker... does that affect "pedestrian" code Unfortunately, the reason why you hear complaints is because it does affect even normal code. Writing code in a setting where you have a strict type system is like writing a mathematical proof. You know that the thing you want to do is safe/correct/valid, but you have to find a way to write it formally, which is itself kind of a puzzle. Don't get me wrong, I think stricter type systems are the future of programming, except maybe for very high level stuff like Python and Js, but there's definitely some friction involved when the language is a "puzzle language" that insists you do things in a specific way. With Python or C++, most experienced programmers will be able to bang out just about anything. With Haskell, Rust, Idris, OCaml and the like, there's this additional step of writing a very detailed math proof that your code is actually allowed. Which makes a lot of sense when you think about those languages' goals. > Where would Rust fit in this picture? There's PyO3, not as stable as pybind11 but it's getting there. Honestly Python is just great for stuff like this. You have a lot of ways to gradually speed it up (types -> cython, C++, Rust). It's about as elegant as an octopus made stapling extra legs to a dog, but it's hard to argue it's not effective.
- smolder 4y ago
  > With Python or C++, most experienced programmers will be able to bang out just about anything. I think the trade off you often get with Rust compared to C++ is that easy things get harder to do and harder things get easier to do correctly. This won't be true for every problem or person but I think it's a fine rule of thumb. Python is a lot more straightforward than either for most problems of any complexity but of course you don't get the same performance potential where you're not grafting it onto a different language.
JoshTriplett 4y ago
I'd say that Rust is better in many regards (the kinds of things you described will mostly Just Work), but there's still enough surface area that you might forget bits if you haven't touched it in a while. One notable difference, though: in C++, if you forget a detail, you might get a compilation error or you might get a runtime crash and need to pull out something like valgrind. In Rust, if you forget a detail, you're extremely likely to get a compilation error, not a runtime crash.
orwin 4y ago
If you want to hack something fast without frustrations and don't need performance yet, and still use rust, there is a way: just declare your variable mutable, clone() a lot and return values. Tbh most of the time the borrow checker was easy to use, and at the time (circa 2014) it was allegedly harder to use than it is now, according to a friend who still use it professionally.

rapsey 4y ago

Rust users are very enthusiastic about Rust, because it fixes so much annoying shit you have to deal with in C/C++. It really brings back a lot of joy to programming. The borrow checker is an issue when you are a beginner and have to unlearn all the bad practices you were doing in C/C++.

rob74 4y ago
I would say the borrow checker is an issue if you come from most other mainstream languages, because Rust's approach of trying to automate memory management without having a garbage collector is quite unique. Also, as a person interested in Rust, but who hasn't yet found the time (and strength of mind) to really commit to learning it: the main difference between C++ and Rust is the cruft that C++ has accumulated over the decades, which Rust doesn't have because it's much younger. But seeing the pace of new features introduced into Rust, I'm a bit worried that some of the older features will soon be declared "non-best practice" and turn into C++-style cruft.
- timeon 4y ago
  > But seeing the pace of new features introduced into Rust, I'm a bit worried that some of the older features will soon be declared "non-best practice" and turn into C++-style cruft. Is it just because you see additions of new features in general or there are some specific issues? For me new features do not make 'bad practice' from old ways. As example in older versions you had to be more explicit with lifetimes, but that is just convenience.
- tialaramex 4y ago
  Rust's Edition system allows it to deprecate and eventually remove syntax that's now considered a mistake, yet that syntax still exists (forever!) for anybody who doesn't want to learn the modern way to write it. Let's take two serious C++ proposals I've looked at over the past years and imagine if it had Editions (it doesn't, Vittorio's similar Epochs proposal was shot down and won't be coming back). First a try operator. C++ doesn't have one of these, it would be usual to spell it ? but that's prohibited in C++ by the existence of a ? character as part of the ternary operator ?:. If you had Editions you could abolish ?: in a new Edition or change the way it is parsed so that some weird utterances now don't work because ? is the try operator, without them the proposers instead reluctantly suggest ?? (which is already an operator in some languages and it isn't try...) Second, pattern matching with _ as a wildcard in the pattern. C++ doesn't do that today. Unfortunately _ is a valid identifier in C++ and people use it. Not a lot of people, but enough for it to be a real pain if this stopped working. So the proposers reluctantly suggest you could write __ in this case. If you had Editions you could forbid _ in a new Edition and in that Edition have the nicer _ while __ is provided in older Editions if they want new pattern matching. Editions only cover syntax (they're actually mutating the Abstract Syntax Tree at compile time) but because this affords some great opportunities for backward compatible changes, it encourages people to get creative and do even more. For example Rust's arrays learned to be IntoIterator. But that's not a syntax change, so how did that remain compatible? Well, there's a hack, if you have an edition prior to 2021 Edition, then one function from IntoIterator is hidden from resolution by the hack, so that array.into_iter() does what it did in your edition before arrays were IntoIterator. But every other feature works, so you can write "for thing in array", you can pass arrays to functions which need an iterator, and so on, and in newer editions the hack isn't used so array.into_iter() does what you'd expect given arrays are now IntoIterator.

pizza234 4y ago

> Is Rust substantially better at this? When I read frustrations about Rust, it seems to be mostly about the Borrow Checker... does that affect "pedestrian" code, like "take this 4-dimensional array and munge it with an arcane for-loop"? Or, here's a basic immutable class with some fields and some methods, make it available in Python? I think language complexity in general is not a problem; language consistency is. I find Rust complex, but not inconsistent or surprising (with exceptions). I'd say that yes, it is substantially better in this regard. Regarding the "pedestrian code", it depends. Rust is very unergonomic for algorithms, due to its handling of bidirectional references. However, some algorithms/data structures may work fine; the matrix operation you refer to can be very easy to work with, if the elements are Clone/Copy, which numbers are. I'm a Rust fan, but the article seems to be a puff piece; it takes one case and generalizes it. I also think that Rust is not productive [than other easy, compiled, languages] for generic programming, at least, without significant experience. Relatively small programs (I don't know the size of the typical scientific programs in academia) may be easier, but once a program grows, it definitely requires an amount of design (due to ownership) that other languages don't require.

rich_sasha 4y ago
> I think language complexity in general is not a problem; language consistency is. With C++ I do find human medium-term cache capacity to be an issue. By the time I use C++ again, I forget some of the many little things I need just to compile a glorified "fizz-buzz". Things like, is this a pointer to a const or a const pointer? What's the syntax for a move/copy constructor? Keeping headers and cpp files in sync. What's the flag to enable modern C++ extensions? How do I write this lambda? Or make a pointer to a function? And so on...
Animats 4y ago
> the article seems to be a puff piece; it takes one case and generalizes it. Agreed. I write mostly in Rust, but I don't recommend it unless you have a hard problem. If you need C/C++ speed, and there's enough complicated state coordination that you need safe threading and allocation control, Rust is useful. For typical webcrap, use Go. That's the job for which Google created Go.

qsort 4y ago

> the Borrow Checker... does that affect "pedestrian" code Unfortunately, the reason why you hear complaints is because it does affect even normal code. Writing code in a setting where you have a strict type system is like writing a mathematical proof. You know that the thing you want to do is safe/correct/valid, but you have to find a way to write it formally, which is itself kind of a puzzle. Don't get me wrong, I think stricter type systems are the future of programming, except maybe for very high level stuff like Python and Js, but there's definitely some friction involved when the language is a "puzzle language" that insists you do things in a specific way. With Python or C++, most experienced programmers will be able to bang out just about anything. With Haskell, Rust, Idris, OCaml and the like, there's this additional step of writing a very detailed math proof that your code is actually allowed. Which makes a lot of sense when you think about those languages' goals. > Where would Rust fit in this picture? There's PyO3, not as stable as pybind11 but it's getting there. Honestly Python is just great for stuff like this. You have a lot of ways to gradually speed it up (types -> cython, C++, Rust). It's about as elegant as an octopus made stapling extra legs to a dog, but it's hard to argue it's not effective.

smolder 4y ago
> With Python or C++, most experienced programmers will be able to bang out just about anything. I think the trade off you often get with Rust compared to C++ is that easy things get harder to do and harder things get easier to do correctly. This won't be true for every problem or person but I think it's a fine rule of thumb. Python is a lot more straightforward than either for most problems of any complexity but of course you don't get the same performance potential where you're not grafting it onto a different language.

JoshTriplett 4y ago

I'd say that Rust is better in many regards (the kinds of things you described will mostly Just Work), but there's still enough surface area that you might forget bits if you haven't touched it in a while. One notable difference, though: in C++, if you forget a detail, you might get a compilation error or you might get a runtime crash and need to pull out something like valgrind. In Rust, if you forget a detail, you're extremely likely to get a compilation error, not a runtime crash.

orwin 4y ago

If you want to hack something fast without frustrations and don't need performance yet, and still use rust, there is a way: just declare your variable mutable, clone() a lot and return values. Tbh most of the time the borrow checker was easy to use, and at the time (circa 2014) it was allegedly harder to use than it is now, according to a friend who still use it professionally.