5 ms·

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work w

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (Funnily enough, both these reasons are why I don't like Java either). I don't want to sound too negative, Rust is a very promising language, but even seven(!) years later it still feels like a pre-alpha language.

avgcorrection 4y ago
Why would people be annoyed? Plenty of people have done the same thing in this thread. Except they stayed on the GUI topic. So maybe that’s why you included the sheepish intro sentence.
cturtle 4y ago
Yes I do find it painful. Because rust’s memory safety restricts the number of valid programs, it is (to me) more difficult to write code. That’s not a bad thing though! It’s just not a trade off I’m willing to make most of the time. If my project requires the memory safety that rust offers, I’ll choose rust. But most of the time I’ll pick something else to lower my mental load when coding.
__david__ 4y ago
I don't find that. I was quite familiar with C and C++ before learning Rust and I find the places where Rust requires explicitness are the places where C lets you glide by and inject hidden bugs into your code. When my Rust code finally compiles it has an extremely high percentage chance to _just work_, where when C compiles you still have another whole pass of "find all the segfaults lurking around".
josephg 4y ago
I learned rust a few years ago, and almost all the code I’ve written in the last 18 months has been rust. Rust makes you deal with all the pain of learning it up front. Does that pain ever go away? In my experience, it mostly does. I’m now significantly more productive in rust than C, and I feel much more pleased with the end result. I still find it takes a lot more effort to write rust than javascript though. Both more thinking per line, and it often takes more lines of code. The resulting software is faster and more correct, but it’s not a uniform win. I still reach for javascript for “code as content” - like UI code. Rust’s async story is awful. Pin is confusing. Async doesn’t play nice with other rust features (like traits). There’s no async streams and it’s extremely difficult to code your own. Solutions to these problems (like GAT and TAIT) have been proposed, coded and discussed for 6 years or something but they still haven’t shipped. I’m quite frustrated with how slowly the language is moving to fix obvious problems. And it seems to be getting slower as more people try to “help” (by chiming in on GitHub). But I really like rust-sans-async as a language for infrastructure code. The stuff I’ve built with it is bonkers fast, safe and correct. The crates ecosystem is fantastic. (Much higher quality than npm). And the community is smart and lovely. It’s not the most productive language but it fits the “better C” niche really well.
Starlevel001 4y ago
Rust is a clever language, which wrecks havoc on people's programming ego by making them very inclined to try and write clever code. But if you avoid trying to be really annoying with the type system like the majority of the ecosystem is, and slap Arc/RefCell/heap allocations everywhere, the language turns back into a high-level language again. Unfortunately, stepping outside the realm of ``core`` and ``alloc`` and ``std`` means having to repeatedly step on overly clever landmines everywhere you go.
- melony 4y ago
  The problem is that you can't even build data structures from introductory algos in Rust without pulling your hair out. No linked lists, no graphs.
  - msbarnett 4y ago
    That’s really only a problem if you spend a significant amount of time trying to “build data structures from introductory algos” without reaching for unsafe, though. If you find it easy to build a linked list or graph in C, you can do it just as easily in Rust — use unsafe, and you have your easy linked list, with exactly as much safety as it had in C. Sure, it’s more challenging to build a fully memory and thread safe linked list or graph, but it’s actually hard as hell to do that in C too. Other languages make it easy to build one with these guarantees only by requiring significant runtime support, which is out of scope for Rust. In the end, it’s pretty unrealistic to expect that any language would allow you to write a guaranteed memory and threadsafe graph structure with zero runtime overhead, without a lot of knowledge, time, and attention on your part — there are no silver bullets. And if you’re using Rust for anything real you’re generally not doing sophomore computer science homework like this anyway.
    - nyanpasu64 4y ago
      The problem is that unsafe data structures are often less safe (harder to avoid UB) than in C, because in the presence of pointer aliasing and cycles (found in unsafe data structures including BTreeMap's node.rs https://doc.rust-lang.org/src/alloc/collections/btree/node.rs.html https://doc.rust-lang.org/src/alloc/collections/btree/node.r...), Stacked Borrows places strict conditions on constructing &mut T (they invalidate some but not all aliasing *const T). And the user of an owning or intrusive linked list generally expects to receive &mut T, which is not always safe to construct because of Stacked Borrows. In fact, Gankra, a major contributor to unsafe Rust libraries, standards, and documentation, doesn't solve this problem through axiomatic reasoning, but instead an "oversimplified" "heuristic" (IMO hopes and prayers): https://rust-unofficial.github.io/too-many-lists/fifth-stacked-borrows.html https://rust-unofficial.github.io/too-many-lists/fifth-stack... (written 2022-01). In practice, I find that unsound libraries frequently get written and used unknowingly in the wild. I've commented on this earlier at https://news.ycombinator.com/item?id=31897503 https://news.ycombinator.com/item?id=31897503. In short, I believe that Stacked Borrows places unreasonable and unattainable requirements on authors of unsafe structures and algorithms, which serve as the foundation for practically all safe code (outside of the vanishingly rare case of code operating on tree-shaped fixed-size variables allocated solely on the stack, and never creating aliased mutable pointers).
filleokus 4y ago
I remember reading (on HN I think) that coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code. You feel smart when it works and challenged when it complains. I personally like that aspect, at least for now. On the other end of the spectrum I would say Go is, with its lack of "advanced" or functional language features and sans-syntactic-sugar straight forward approach. I always feel like I have oncoming RSI when I write Go, its just so verbose and un-dense and frankly boring. No room for (too much) cleverness. At the same time I would guess real development teams using Go are more productive (in problem spaces where Go can be used instead of Rust of course). Especially if you factor in mentoring of junior colleges new to the language etc.
- the_duke 4y ago
  > coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code That is mostly only true for very early beginners. There are certain patterns you have to learn and understand, especially for developers not accustomed to thinking about lifetimes ( which applies to most developers that only have experience with GC languages). And sometimes you do have to battle the compiler, even with experience. But most of that goes away pretty quickly once the language clicks for you. After that Rust can still feel restrictive, but that's because there are very few languages that enforce as much correctness at compile time. That very well can mean that Rust just isn't a good fit for certain domains - which is perfectly fine!
- baby 4y ago
  Completely agree with Golang, it is such a nice language as it remains pretty basic/simple and thus extremely readable and easy to use. Sure it's not expressive enough for some applications, but for a lot of applications it really shines. I'm mostly doing Rust nowadays, but if I want to use a beautiful and enjoyable garbage collected language there's Golang.
game-of-throws 4y ago
When I hear you say "Lombok problem", it makes me think you're writing getters and setters and generally treating the language as if it's Java. You might get along better if you try to unlearn some of those habits. There's nothing wrong with public fields or free functions; in fact I'd say most of the time the straightforward approach is preferred.
- CrimsonVoid 4y ago
  It's less about getters and setters specifically and more about how much Java's ecosystem relies on code generation through libraries like Lombok instead of just trying to fix the language. Likewise, Rust's answer to everything seems to be "just make a (proc) macro" instead of trying to extend the language. Proc macros do have their place, serde being a great example, but then there are crates like thiserror and bitflags which exist because Rust provides nothing in the language grammar to actually talk about errors and error handling patterns, or bitmasks (which is an incredibly common thing for a systems programming language). Sure you could write out the From<Error> impls instead of using thiserror, but most people aren't going to because Rust makes something that should be mundane incredibly annoying to write by hand. Side note, Rust best practice seems to be in favor of getters and setters like Java and several popular libraries I've seen don't expose struct fields directly instead opting for set_x() and x() methods. Give it a few years and I'm sure Rust will have its own Lombok crate generating getters, setters, and constructors too.
wokwokwok 4y ago
Not everyone loves rust. I don’t love rust. I think rust has some fair critiques to be made of it. It’s not, and never has, or (probably) will be the answer to all problems. Don’t use it just because it’s popular; why are you trying to use it, and what are you using instead? I’ll eat my hat if you can convince me that rust is more of a pain in the ass than c++. I think cpp is a stupid broken ecosystem, and the fact that rust went all in with a single unified package manager makes the comparison a non-event. So… compare apples to apples right? “pre-alpha” language? I don’t even know what you mean by this; but, it’s ok not to love it. There are things I dislike about it too. It is verbose. I still use it though; it’s better than the alternatives for what I’m doing.
rvz 4y ago
It is good for some use cases, but the hard fact of the matter is, it is not useful as a way for creating cross-platform scalable GUI apps. I have heard all the arguments for using Rust in GUI apps, but realistically they seem to be very weak to convince a serious team of developers to choose between the alternatives.
baby 4y ago
I really really hate Java, in parts due to the verbosity, and find Rust very pleasant to write. I'm not sure I would call Rust verbose at all, although you can look at code that gets verbose due to the expressiveness of the language and the desire for people to over engineer things (versus a language like Golang that remains very readable at all time). But when I write my own code, I tend to avoid the complexity and write pretty clear (I would like to think) Rust code. There's definitely a learning curve (I think everyone agrees with that one), which might be what you're feeling now, but that quickly goes away once you pick up some speed. I would say keep on learning Rust and the language will grow on you.
lakecresva 4y ago
> but even seven(!) years later it still feels like a pre-alpha language. Can you give any concrete examples of things that give you this impression?
- CrimsonVoid 4y ago
  Sure, I kind of hint at it in another comment in this thread but a few more pain points for me: * Rust has no way to talk about heap allocations succinctly other than Box; an actual type I had Option<Box<[Box<[&'a str]>]>>. It's more than just Box and Option being poor abstractions for the heap and nullability respectively, but the fact that Rust is a systems programming language and provides nothing to actually help with even mundane problems that arise in systems programming * there has been almost no iteration in the design space of lifetimes despite being a cornerstone feature of the language * prolific do_x and do_x_mut methods; there has to be a better way than countless *_mut methods for a language where mutability is so important My general impression of Rust is that it ships a MVP version of a feature and never really tries to iterate on it, or iteration happens incredibly slowly (const generics being the only notable exception I can think of where almost every release seems to have something to say about const generics). And I get it, things like GATs are important for the language long term, but the "ivory tower" approach has left the rest of the language feeling neglected IMO.
nu11ptr 4y ago
To be honest, usually the exact opposite. There are some things where I start writing in Rust and it turns out to be a bit of a pain, but this is unusual for the types of stuff I write. Typically this just means I need a crate to do the heavy lifting as I'm trying to do too much. I would say most things are solidly better and easier to write, and given the safety guarantees, often work even without tests (exception being complicated algorithms that I usually get wrong the first time). In summary, yes, I'm a bit of a fanboy, but there is a reason I am - Rust is pragmatic and helps me get things done in a way I have not found in other languages.
shrimp_emoji 4y ago
It was painful for me at first. Many struggles with the borrow checker. I dropped it for a year or two and came back, and, weirdly, my return met smooth sailing -- the borrow checker and I were a well-oiled cybernetic machine. It was like the lessons of my first time burrowed into my subconscious or something. At this point, I kind of feel like, if you're writing safe C or C++, being mindful of where the data goes and why, you're pretty much writing Rust that compiles.
- anon291 4y ago
  > At this point, I kind of feel like, if you're writing safe C or C++, being mindful of where the data goes and why, you're pretty much writing Rust that compiles. Exactly. If you're using modern c++ and you actually know what's undefined behavior and what's not, you're doing rust. The only difference is c++ compilers don't error out on the undefined behavior. Actually it wouldn't be that hard to write a c++ compiler that errored out in this way. unfortunately, it'd break all c++ programs today.
WiSaGaN 4y ago
It depends very much on what type of software you are writing. Whether you are writing an exploratory software that will get tossed a few days after, or a piece of hardware that will be used and modified continuously in order of several years. Whether it is a GUI like mentioned in this article with changing requirements or architecture trends once in a while, or fundamental building blocks with very slow-changing requirements but with high stakes regarding correctness and performance like kernels or cryptotography/security. There is no single tool that can handle all the problems, but rust can be especially productive to use in those latter case, considering the time spent in entire software life-cycle like maintaining and debugging. After some time, it is even possible to be more productive just in writing code itself than Python (for me this is true for command-line client tools)! At the end of day, if you are a C++ programmer that gets constantly bitten by bug either written by youself or by someone else in your team. Bugs like using `foo.to_string().c_str()` after the line that defines it, bugs caused by trying to erase element of an iterator in a `for` loop. Starting to write code in Rust, it will soon be less painful than writing in C++. Especially you are into idiomatic ways to write good software in C++!
deleted 4y ago
[deleted]

avgcorrection 4y ago

Why would people be annoyed? Plenty of people have done the same thing in this thread. Except they stayed on the GUI topic. So maybe that’s why you included the sheepish intro sentence.

cturtle 4y ago

Yes I do find it painful. Because rust’s memory safety restricts the number of valid programs, it is (to me) more difficult to write code. That’s not a bad thing though! It’s just not a trade off I’m willing to make most of the time. If my project requires the memory safety that rust offers, I’ll choose rust. But most of the time I’ll pick something else to lower my mental load when coding.

__david__ 4y ago

I don't find that. I was quite familiar with C and C++ before learning Rust and I find the places where Rust requires explicitness are the places where C lets you glide by and inject hidden bugs into your code. When my Rust code finally compiles it has an extremely high percentage chance to _just work_, where when C compiles you still have another whole pass of "find all the segfaults lurking around".

josephg 4y ago

I learned rust a few years ago, and almost all the code I’ve written in the last 18 months has been rust. Rust makes you deal with all the pain of learning it up front. Does that pain ever go away? In my experience, it mostly does. I’m now significantly more productive in rust than C, and I feel much more pleased with the end result. I still find it takes a lot more effort to write rust than javascript though. Both more thinking per line, and it often takes more lines of code. The resulting software is faster and more correct, but it’s not a uniform win. I still reach for javascript for “code as content” - like UI code. Rust’s async story is awful. Pin is confusing. Async doesn’t play nice with other rust features (like traits). There’s no async streams and it’s extremely difficult to code your own. Solutions to these problems (like GAT and TAIT) have been proposed, coded and discussed for 6 years or something but they still haven’t shipped. I’m quite frustrated with how slowly the language is moving to fix obvious problems. And it seems to be getting slower as more people try to “help” (by chiming in on GitHub). But I really like rust-sans-async as a language for infrastructure code. The stuff I’ve built with it is bonkers fast, safe and correct. The crates ecosystem is fantastic. (Much higher quality than npm). And the community is smart and lovely. It’s not the most productive language but it fits the “better C” niche really well.

Starlevel001 4y ago

Rust is a clever language, which wrecks havoc on people's programming ego by making them very inclined to try and write clever code. But if you avoid trying to be really annoying with the type system like the majority of the ecosystem is, and slap Arc/RefCell/heap allocations everywhere, the language turns back into a high-level language again. Unfortunately, stepping outside the realm of ``core`` and ``alloc`` and ``std`` means having to repeatedly step on overly clever landmines everywhere you go.

melony 4y ago
The problem is that you can't even build data structures from introductory algos in Rust without pulling your hair out. No linked lists, no graphs.
- msbarnett 4y ago
  That’s really only a problem if you spend a significant amount of time trying to “build data structures from introductory algos” without reaching for unsafe, though. If you find it easy to build a linked list or graph in C, you can do it just as easily in Rust — use unsafe, and you have your easy linked list, with exactly as much safety as it had in C. Sure, it’s more challenging to build a fully memory and thread safe linked list or graph, but it’s actually hard as hell to do that in C too. Other languages make it easy to build one with these guarantees only by requiring significant runtime support, which is out of scope for Rust. In the end, it’s pretty unrealistic to expect that any language would allow you to write a guaranteed memory and threadsafe graph structure with zero runtime overhead, without a lot of knowledge, time, and attention on your part — there are no silver bullets. And if you’re using Rust for anything real you’re generally not doing sophomore computer science homework like this anyway.
  - nyanpasu64 4y ago
    The problem is that unsafe data structures are often less safe (harder to avoid UB) than in C, because in the presence of pointer aliasing and cycles (found in unsafe data structures including BTreeMap's node.rs https://doc.rust-lang.org/src/alloc/collections/btree/node.rs.html https://doc.rust-lang.org/src/alloc/collections/btree/node.r...), Stacked Borrows places strict conditions on constructing &mut T (they invalidate some but not all aliasing *const T). And the user of an owning or intrusive linked list generally expects to receive &mut T, which is not always safe to construct because of Stacked Borrows. In fact, Gankra, a major contributor to unsafe Rust libraries, standards, and documentation, doesn't solve this problem through axiomatic reasoning, but instead an "oversimplified" "heuristic" (IMO hopes and prayers): https://rust-unofficial.github.io/too-many-lists/fifth-stacked-borrows.html https://rust-unofficial.github.io/too-many-lists/fifth-stack... (written 2022-01). In practice, I find that unsound libraries frequently get written and used unknowingly in the wild. I've commented on this earlier at https://news.ycombinator.com/item?id=31897503 https://news.ycombinator.com/item?id=31897503. In short, I believe that Stacked Borrows places unreasonable and unattainable requirements on authors of unsafe structures and algorithms, which serve as the foundation for practically all safe code (outside of the vanishingly rare case of code operating on tree-shaped fixed-size variables allocated solely on the stack, and never creating aliased mutable pointers).

filleokus 4y ago

I remember reading (on HN I think) that coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code. You feel smart when it works and challenged when it complains. I personally like that aspect, at least for now. On the other end of the spectrum I would say Go is, with its lack of "advanced" or functional language features and sans-syntactic-sugar straight forward approach. I always feel like I have oncoming RSI when I write Go, its just so verbose and un-dense and frankly boring. No room for (too much) cleverness. At the same time I would guess real development teams using Go are more productive (in problem spaces where Go can be used instead of Rust of course). Especially if you factor in mentoring of junior colleges new to the language etc.

the_duke 4y ago
> coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code That is mostly only true for very early beginners. There are certain patterns you have to learn and understand, especially for developers not accustomed to thinking about lifetimes ( which applies to most developers that only have experience with GC languages). And sometimes you do have to battle the compiler, even with experience. But most of that goes away pretty quickly once the language clicks for you. After that Rust can still feel restrictive, but that's because there are very few languages that enforce as much correctness at compile time. That very well can mean that Rust just isn't a good fit for certain domains - which is perfectly fine!
baby 4y ago
Completely agree with Golang, it is such a nice language as it remains pretty basic/simple and thus extremely readable and easy to use. Sure it's not expressive enough for some applications, but for a lot of applications it really shines. I'm mostly doing Rust nowadays, but if I want to use a beautiful and enjoyable garbage collected language there's Golang.

game-of-throws 4y ago

When I hear you say "Lombok problem", it makes me think you're writing getters and setters and generally treating the language as if it's Java. You might get along better if you try to unlearn some of those habits. There's nothing wrong with public fields or free functions; in fact I'd say most of the time the straightforward approach is preferred.

CrimsonVoid 4y ago
It's less about getters and setters specifically and more about how much Java's ecosystem relies on code generation through libraries like Lombok instead of just trying to fix the language. Likewise, Rust's answer to everything seems to be "just make a (proc) macro" instead of trying to extend the language. Proc macros do have their place, serde being a great example, but then there are crates like thiserror and bitflags which exist because Rust provides nothing in the language grammar to actually talk about errors and error handling patterns, or bitmasks (which is an incredibly common thing for a systems programming language). Sure you could write out the From<Error> impls instead of using thiserror, but most people aren't going to because Rust makes something that should be mundane incredibly annoying to write by hand. Side note, Rust best practice seems to be in favor of getters and setters like Java and several popular libraries I've seen don't expose struct fields directly instead opting for set_x() and x() methods. Give it a few years and I'm sure Rust will have its own Lombok crate generating getters, setters, and constructors too.

wokwokwok 4y ago

Not everyone loves rust. I don’t love rust. I think rust has some fair critiques to be made of it. It’s not, and never has, or (probably) will be the answer to all problems. Don’t use it just because it’s popular; why are you trying to use it, and what are you using instead? I’ll eat my hat if you can convince me that rust is more of a pain in the ass than c++. I think cpp is a stupid broken ecosystem, and the fact that rust went all in with a single unified package manager makes the comparison a non-event. So… compare apples to apples right? “pre-alpha” language? I don’t even know what you mean by this; but, it’s ok not to love it. There are things I dislike about it too. It is verbose. I still use it though; it’s better than the alternatives for what I’m doing.

rvz 4y ago

It is good for some use cases, but the hard fact of the matter is, it is not useful as a way for creating cross-platform scalable GUI apps. I have heard all the arguments for using Rust in GUI apps, but realistically they seem to be very weak to convince a serious team of developers to choose between the alternatives.

baby 4y ago

I really really hate Java, in parts due to the verbosity, and find Rust very pleasant to write. I'm not sure I would call Rust verbose at all, although you can look at code that gets verbose due to the expressiveness of the language and the desire for people to over engineer things (versus a language like Golang that remains very readable at all time). But when I write my own code, I tend to avoid the complexity and write pretty clear (I would like to think) Rust code. There's definitely a learning curve (I think everyone agrees with that one), which might be what you're feeling now, but that quickly goes away once you pick up some speed. I would say keep on learning Rust and the language will grow on you.

lakecresva 4y ago

> but even seven(!) years later it still feels like a pre-alpha language. Can you give any concrete examples of things that give you this impression?

CrimsonVoid 4y ago
Sure, I kind of hint at it in another comment in this thread but a few more pain points for me: * Rust has no way to talk about heap allocations succinctly other than Box; an actual type I had Option<Box<[Box<[&'a str]>]>>. It's more than just Box and Option being poor abstractions for the heap and nullability respectively, but the fact that Rust is a systems programming language and provides nothing to actually help with even mundane problems that arise in systems programming * there has been almost no iteration in the design space of lifetimes despite being a cornerstone feature of the language * prolific do_x and do_x_mut methods; there has to be a better way than countless *_mut methods for a language where mutability is so important My general impression of Rust is that it ships a MVP version of a feature and never really tries to iterate on it, or iteration happens incredibly slowly (const generics being the only notable exception I can think of where almost every release seems to have something to say about const generics). And I get it, things like GATs are important for the language long term, but the "ivory tower" approach has left the rest of the language feeling neglected IMO.

nu11ptr 4y ago

To be honest, usually the exact opposite. There are some things where I start writing in Rust and it turns out to be a bit of a pain, but this is unusual for the types of stuff I write. Typically this just means I need a crate to do the heavy lifting as I'm trying to do too much. I would say most things are solidly better and easier to write, and given the safety guarantees, often work even without tests (exception being complicated algorithms that I usually get wrong the first time). In summary, yes, I'm a bit of a fanboy, but there is a reason I am - Rust is pragmatic and helps me get things done in a way I have not found in other languages.

shrimp_emoji 4y ago

It was painful for me at first. Many struggles with the borrow checker. I dropped it for a year or two and came back, and, weirdly, my return met smooth sailing -- the borrow checker and I were a well-oiled cybernetic machine. It was like the lessons of my first time burrowed into my subconscious or something. At this point, I kind of feel like, if you're writing safe C or C++, being mindful of where the data goes and why, you're pretty much writing Rust that compiles.

anon291 4y ago
> At this point, I kind of feel like, if you're writing safe C or C++, being mindful of where the data goes and why, you're pretty much writing Rust that compiles. Exactly. If you're using modern c++ and you actually know what's undefined behavior and what's not, you're doing rust. The only difference is c++ compilers don't error out on the undefined behavior. Actually it wouldn't be that hard to write a c++ compiler that errored out in this way. unfortunately, it'd break all c++ programs today.

WiSaGaN 4y ago

It depends very much on what type of software you are writing. Whether you are writing an exploratory software that will get tossed a few days after, or a piece of hardware that will be used and modified continuously in order of several years. Whether it is a GUI like mentioned in this article with changing requirements or architecture trends once in a while, or fundamental building blocks with very slow-changing requirements but with high stakes regarding correctness and performance like kernels or cryptotography/security. There is no single tool that can handle all the problems, but rust can be especially productive to use in those latter case, considering the time spent in entire software life-cycle like maintaining and debugging. After some time, it is even possible to be more productive just in writing code itself than Python (for me this is true for command-line client tools)! At the end of day, if you are a C++ programmer that gets constantly bitten by bug either written by youself or by someone else in your team. Bugs like using `foo.to_string().c_str()` after the line that defines it, bugs caused by trying to erase element of an iterator in a `for` loop. Starting to write code in Rust, it will soon be less painful than writing in C++. Especially you are into idiomatic ways to write good software in C++!

deleted 4y ago

[deleted]