Black Hat Python, along with RTFM: Red Team Field Manual; are excellent resources for binpacking your brain with some simple effective uses of tools to serve a need.
I don't feel the same about this book.
Python is pretty ubiquitous, and RTFM focuses on oneliners and easily composable programs with utilities that already exist on target systems.
A lot of what makes Red Team work harder is the need for portability, which pushes people to need to learn lots of interpreted languages and OS internals.
My memory of using Rust for interop with the OS, is syscalls in win32 api; which consumed the better part of a couple weeks to get right, and required the use of unsafe, a lot.
I recently read blackhat python. I feel it has not aged well as large parts are dedicated to issues that are no longer relevant.
I don't see this book doing the same mistake. On the other hand, I dont know if I want to fight the borrow checker for weeks instead if throwing together a quick script in python...
I feel as though buying a book like this is admission that you don't have what it takes to do black hat work. Good if it's just out of curiosity though.
I will eventually read through this because I have a reasonably good handle on Python/Go, but don’t have any experience with Rust. This book will help me focus on the parts of Rust that I am most interested in given my current InfoSec work.
You'd be surprised how many professional hackers - the ones that intelligence agencies hire/train/employ - start with close to zero prior knowledge on topics like cybersecurity, when they're going through selection.
If you have solid knowledge in CS fundamentals and the right mindset/motivation, that tends to be enough.
I feel as though buying a book like this is a great way to start learning about black hat work. Doing things out of curiosity is how everyone starts in a field like cybersecurity.
If I had to extract meaning from it, I'd say "Never before has there been one language that is at least ok at writing shellcode, a web server, and a phishing page in".
Not sure I agree with the statement, but it's a pretty weird category to sit in. C would count as a possible member at least.
Sure, we can do those things in C, but they are easier and faster to do in Rust, and safer, largely because of Rust's enums (algebraic data types, not as simplistic as C's) and traits, and because of crates: a lot can be done in Rust by gluing together a few well maintained crates.
The only language that comes close, AFAICT, is python.
Add the fact that Rust's memory safety brings thread safety for free (once you've grokked Rust's memory management model) and yiu get quickly written type safe memory safe thread safe high perfomance code.
1. It's highly opionated so there's a cult-like element of an ingroup/outgroup, e.g. "we don't have OOP, OOP is bad! if you use it, you are an outsider and we can do things better in Rustland here!"
2. It's posed as an alternative to C/C++ which have many historical problems. It's very easy to construct a strawman to show Rust is so much better than those ancient languages. ("here's this trivial buffer overflow bug Rust could have prevented!")
3. It's low-level enough that people feel 1337 for using it but not low-level enough to actually require low-level skills to use it. This is why you can see how in many cases, the "solution" to the borrow checker is just cloning everything - because they have zero idea about how to make performant programs.
4. It doesn't have many established libraries/frameworks compared to other languages, so "I wrote X but Rust" is a viable thing. In other languages, this wouldn't stand because there are already established libraries so interest in new ones is not as high + there are certain quality standards you have to meet.
5. It has certain high-profile features which are easy to explain why they are better - option types and slices for example. These Rustaceans are usually not exposed to functional programming before - so they start to embrace simple forms of functional programming. It makes Rust programs look fairly different compared to similar languages, which is another differentiator. It's easy to showcase the advantages of these features in code snippets, which makes it easy to evangelise.
We don't have a lot of place for religion in my industry, and safe, performant low level code is everything. Writing and debugging such code in Rust is just easier and faster than in C.
Two years ago I was casually learning Rust by night while by day I was extending a scheduler I had previously written in C. I kept wishing I could switch, because I kept having to handcraft in C things I would have gotten for nearly free in Rust.
Now, we're designing the Rust replacement for that C program, and it is taking all my will power not to start coding it: that job falls to someone else, and I am wistful about it. Not because I am going to miss the C code, but because it would just be so much fun to do in Rust.
Not sure you are trolling us or not, but there is a bit of a contradiction between "here is a huge learning curve to Rust, one that I am still climbing," in the comment above and "is just easier and faster than in C".
It is certainly true that you have a lot of things you can easily have at your fingertips with cargo in Rust, which you might need to first identify or even handcraft (if you have no existing framework to rely on) in C. On the other hand, I am not sure this is a good thing. I am a bit skeptical about the cargo / NPM style of package management.
> but there is a bit of a contradiction between "here is a huge learning curve to Rust, one that I am still climbing," in the comment above and "is just easier and faster than in C
I see no contradiction when you realize that no one has ever been proficient enough in C to write code that is free from UB… The problem with C is that cannot realistically be written by humans, so pretty much any language (except C++ …) is going to be “easier than C”.
Wild claims. So many huge projects have been successfully written in C by humans. There are patterns to solve all the built in solutions provided by Rust, how do you imagine Rust got them in the first place?
One tiny example of many here is the Linux kernel.
I'd say we didn't have many options back then except for C and no more than 4-5 others. So we did the things you quoted _despite_ C's drawbacks, not because of them.
I can very easily imagine doing the same things with Rust, with small amount of exceptions (that the core team is working on even now).
And yes Rust learned from the mistakes of the languages before it. Is that a bad thing?
Java and C# runtimes are getting memory safety at the cost of RAM usage in runtime, to lesser extent CPU overhead in runtime. Rust is getting memory safety at the cost of cognitive load of developers. Due to this tradeoff, by design Rust is extremely hard to use. Some people still learn the language despite the learning curve, then fall to sunk cost fallacy.
Another thing, it’s obvious people who designed Rust liked functional programming, so Rust attracts FP programmers. In the online communities, functional programmers are known for over-the-top evangelism for decades now.
While I agree that Rust advocates can be annoying at times, your last paragraph confuses me: which language do you have in mind that is both memory-safe and higher performance than Rust?
Rust is legitimately special: being memory safe without any kind of garbage collection (I include ref-counting here). That's what enables its deployment in stuff like QEMU or the Linux kernel.
Also, rust is legitimately a nice language. I get it that people get annoyed over the hype, but then they start acting like people like it just because they're morons who can't think for themselves.
There is the theory that Rust people constantly have to reassure themselves that the language is great and the future, so that can bear the suffering from using it.
If you say so. Considering that you can define the basics of a memory and thread safety for free JSON parser in a single enum in Rust, and derive a lot of utility functions, where C would take a lot more code, and the code would be riskier, well, I'm just going to keep enjoying working in the language. It has a lovely balance of power and conciseness.
There is a huge learning curve to Rust, one that I am still climbing, but I haven't been as excited learning and working with a new language since 1987 when I learned C afters years of working with Pascal, Fortran, and a number of procedural job control systems.
In the years since, I've written large complex programs and systems in C, JS, bash, and PowrShell, and so far Rust feels like my new forever home, my defauly go to.
I'm glad of this, because my industry is heading to memory-safe, compiled languages, and the others I've experienced don't work for me. It's aesthetic, mostly, I guess, but Rust just makes sense.
And there you go, you've passed the line. In response to a suggestion that maybe you could tone it down a bit, you just repeat the party line again, because a slight opening has been spotted and by golly you're not going to let that pass!
You're hurting more than you're helping at this point.
And, just in case you're having trouble following along, as the evidence rather suggests that you are, note that replying with yet another paeon to Rust will be really missing the point.
There is no party line, and there is no tone. There are over 30 years of experience with C, not all of it pleasant, though most of it productive, and, comparatively speaking, amazing recent experiences with Rust. I do have to shift my thinking from how I would solve problems in C, because the memory management paradigm is so different, but, thanks in part to deep dives into scoping in other languages in pursuit of pernicious bugs, once I make that shift, problems are easier to solve in Rust: The language and the compiler, hand in glove, do a lot of the work for you.
You can carp all you like, and that is all it is, carping, not criticism, we'll just happily work along getting a lot done in less time.
If you want to advocate for things, you should learn more about social cues. Blatently missing them this badly hurts your advocacy and pushes people away. This is not unique to the Rust community, and it isn't universal to the Rust community by any means, I know you're a minority, but you people who just beat on people like this are hurting far more than you are helping.
To me it seems like you are passing a different line, into downright anti-rust hysteria, as if it is some sort of taboo to talk positively about it, or argue about its merits.
Your earlier comment, that his advocacy passes into parody, also seems silly to me. Perhaps you don't believe Rust's merits, and that's fine. Perhaps you don't believe the grandparent, and that's fine too. But either way, his argument was fair.
Edit: I later realized that my comment is mostly just an attack that doesn't really add anything to this thread. I apologize for that.
To add something to it, I'd just like to second that Rust is indeed very easy to write after learning to deal with the borrow checker. Much, much easier than C, and I say that with 15 years of writing various applications in C (with all of the autotools rituals, pthreads, Glib gobject nonsense, GTK/GDK/cairo, etc).
I had a fun little code battle with a colleague, and here's a comparison of Rust [1] vs Python [2]. Although Rust is certainly nowhere near as readable as Python, it was just as easy to write, due to the type-system saving on debugging/learning time.
Monomaniacally monopolizing the topic is anti-social behavior.
I mention this because apparently you could use a bit of clue on that as well. You're actively pushing people away from Rust at this point when you resist the clue stick this hard.
I see. Yes, I will admit that I see the context as being perfectly fine.
It started as a misguided comment that takes a tongue-in-cheek statement but believes it is unironic, followed by a comment saying it was tongue-in-cheek, there is some truth to it, but that truth is hard to believe, and then finally PeterWhittaker's comment, which argues that it should not be that hard to believe after all.
> Sure, we can do those things in C, but they are easier and faster to do in Rust
...I don't know what to say to this except "no?".
I'd have to question what priors someone making that claim is bringing and where they got them from.
> The only language that comes close, AFAICT, is python.
With well over a decade in Python experience and having regularly defended it against many claims of unsuitability for many tasks, I have to call BS on this and say that no, that is not even remotely correct. Of all the possible use cases where Python is an easily dismissed but very defensible choice this is NOT one of them.
> easier and faster to do in Rust, and safer, largely because of Rust's enums (algebraic data types, not as simplistic as C's)
Python enums are largely equivalent to C enums, except you can use string constants as values. Otherwise there's little ergonomic difference.
> and traits
Python Protocols (less anything that came before) aren't even remotely comparable to Rust traits. And neither affords any major advantage to red team style development.
And while memory safety is great for mission critical pieces of a larger system, and language ergonomics are essential for readable and maintainable code, I don't know what either of these possibly has to do with writing exploits.
> shellcode, a web server, and a phishing page in
Python would at least be a better choice than Rust for all of these, but so would have been Perl 20 years ago.
Apologies, my reference to python was unclear: I was referring to the python module system and the strength and depth of community contributions, not to the syntax and semantics of the language.
In both cases, the communities do so much good work that often someone else has at least a partial solution to problème-du-jour, so it can be relatively easy to get at least a prototype or PoC, and learn from it, and sometimes one gets a complete solution to at least part of the problem.
I don't know where you'd draw the line, but if you asked me which language made it easier to say, integrate a jinja library that web pages were written in, I know my answer.
Wooshed might feel good but the whole thing reads as a wispy joke to me, and every page 404s. Maybe if there was more content than surface level general falsehoods it'd provide enough to chew on, instead of dismiss
I thought this repo was something I could read on GitHub, but it seems like it just stores code associated with the book. So this is just an ad for the book. And all the chapter links 404.
I've got to say, it's time for HN to add an obligatory tag for ads like that, I know it's not so much a loss of time, but it irritates me sometimes, just like now.
I think what the author hasn't realized yet is that for the most part - exploit development, fuzzing a binary, finding a logical problem and building a feasible exploit for it - you are fighting against the language that you chose.
The reason Go got so popular is not because of its type system, but because it also has a mode of programming "good enough" prototypes.
Python for exploit development is also great due to the gdb fork that can generate python payloads, offsets etc, but it sucks for deployment on targets.
If I would compare the three language choices I don't see why anyone would choose Rust over the other two in terms of efficiency and not having to fight the language. I don't even know whether it would be possible to write an exploit that overflows something in an external ABI binary in Rust without sacrificing everything that Rust stands for. After all, the binary would have to be statically linked for deployment, have to support invalid types, have to support invalid control flows etc.
On the other hand, in Go that's what CGo is made for. The VM and GC in Go doesn't care about what CGo does.
Edit: nevermind, the only example that is using Rust for this type of exploits is a sudo cli argument exploit, lol. I would have expected a little more than a char array generator that's using the FFI package. [1]
Exactly my thoughts reading the ToC. One exception would come to my mind though: Rust would seem a very reasonable language choice to me to write malware. E.g., the next Stuxnet. Low level enough, plus the language safety to help staying under the radar.
How is (A) relevant? It's not like Google is pouring lots of money into Go! The use of Go _inside_ Google is limited at best. I would say, the success of Go is exactly aligned with the success of cloud plumbing as a whole: Docker, Hashistack, Kubernetes (which is not successful "because Google", but rather because it's virtually unmatched in capability and just happens to be written in Go.) People like to say Google has helped Go succeed, however in reality Google's influence is vastly overstated. This is nothing else but expendable excuse, see "big company = big money = bad." Apple spent order of magnitude more on Swift, and yet it's not as successful outside of a handful applications. Google itself had _actually_ spent orders of magnitude more on Dart, enabling its adoption, holding conferences, investing deeply into Flutter, and it's nowhere near as successful as Go.
The real reason Go is a success is the Go team, and engineering prowess they brought to the table.
Go is the language where people get shit done; now, Rust may be "the most loved language" or whatever, but the overwhelming success of Go as a programming platform (which is Rust community is supposedly obsessed with) cannot be attributed to anything else but engineering reasons. People like it. Why do they like it? Because it's easy to use, gets out the way, and it gets the job done. You find a library on Github, read the godoc, and you're literally seconds away from incorporating it in your program. This is not something you can get by accident, by means of investment, or otherwise by making bad design decisions.
I'd also like to add that Go has the advantage that its ideology of using a "pure go until the syscall level" approach is what makes it an optimal malware development language. It's so much easier to develop and deploy malware because most of the EDR world focus heavily on the "C-like world" and its limitations.
The only other project that comes close to what you can do with Go when it comes to mutating binaries is in my opinion the APE/cosmopolitan ecosystem. But those binaries tend to get flagged immediately because there's no major software that's being used that requires APE binaries to run.
On the other hand, the static parts of any Go binary (the head/runtime part) can't be flagged because of so many devops tools rely on Go binaries to work. There was the Ebowla incident in 2016, where all go binaries (including docker) were flagged as malware because the static parts were added as yara rules in Kaspersky and other Antivirus tools. They had to revert those changes after a week.
bro this is a "news" site run by a startup incubator.
80% of this site is about pushing and selling stuff. blatant out of the blue spam doesn't have a place here, but discussing (and hating on) Rust is a common topic.
76 comments
[ 3.9 ms ] story [ 144 ms ] threadhttps://github.com/rustaccato/road-to-being-master-rustacean...
I don't feel the same about this book.
Python is pretty ubiquitous, and RTFM focuses on oneliners and easily composable programs with utilities that already exist on target systems.
A lot of what makes Red Team work harder is the need for portability, which pushes people to need to learn lots of interpreted languages and OS internals.
My memory of using Rust for interop with the OS, is syscalls in win32 api; which consumed the better part of a couple weeks to get right, and required the use of unsafe, a lot.
I don't see this book doing the same mistake. On the other hand, I dont know if I want to fight the borrow checker for weeks instead if throwing together a quick script in python...
To be fair, you only need to fight if you care about maximum performance.
it's alright, a lot of stuff I'd characterize as a 'good start'
If you have solid knowledge in CS fundamentals and the right mindset/motivation, that tends to be enough.
i'd ordinarily consider this too implausible a statement to be seriously believed, but rust people really do talk like this.
Not sure I agree with the statement, but it's a pretty weird category to sit in. C would count as a possible member at least.
The only language that comes close, AFAICT, is python.
Add the fact that Rust's memory safety brings thread safety for free (once you've grokked Rust's memory management model) and yiu get quickly written type safe memory safe thread safe high perfomance code.
It's not like it's the only high-performance memory safe language. It wasn't the first. It's not the highest performance. What am I missing?
2. It's posed as an alternative to C/C++ which have many historical problems. It's very easy to construct a strawman to show Rust is so much better than those ancient languages. ("here's this trivial buffer overflow bug Rust could have prevented!")
3. It's low-level enough that people feel 1337 for using it but not low-level enough to actually require low-level skills to use it. This is why you can see how in many cases, the "solution" to the borrow checker is just cloning everything - because they have zero idea about how to make performant programs.
4. It doesn't have many established libraries/frameworks compared to other languages, so "I wrote X but Rust" is a viable thing. In other languages, this wouldn't stand because there are already established libraries so interest in new ones is not as high + there are certain quality standards you have to meet.
5. It has certain high-profile features which are easy to explain why they are better - option types and slices for example. These Rustaceans are usually not exposed to functional programming before - so they start to embrace simple forms of functional programming. It makes Rust programs look fairly different compared to similar languages, which is another differentiator. It's easy to showcase the advantages of these features in code snippets, which makes it easy to evangelise.
Two years ago I was casually learning Rust by night while by day I was extending a scheduler I had previously written in C. I kept wishing I could switch, because I kept having to handcraft in C things I would have gotten for nearly free in Rust.
Now, we're designing the Rust replacement for that C program, and it is taking all my will power not to start coding it: that job falls to someone else, and I am wistful about it. Not because I am going to miss the C code, but because it would just be so much fun to do in Rust.
It is certainly true that you have a lot of things you can easily have at your fingertips with cargo in Rust, which you might need to first identify or even handcraft (if you have no existing framework to rely on) in C. On the other hand, I am not sure this is a good thing. I am a bit skeptical about the cargo / NPM style of package management.
I see no contradiction when you realize that no one has ever been proficient enough in C to write code that is free from UB… The problem with C is that cannot realistically be written by humans, so pretty much any language (except C++ …) is going to be “easier than C”.
One tiny example of many here is the Linux kernel.
I can very easily imagine doing the same things with Rust, with small amount of exceptions (that the core team is working on even now).
And yes Rust learned from the mistakes of the languages before it. Is that a bad thing?
Another thing, it’s obvious people who designed Rust liked functional programming, so Rust attracts FP programmers. In the online communities, functional programmers are known for over-the-top evangelism for decades now.
Besides, cargo cult is simply the wrong concept to point out here.
Rust is legitimately special: being memory safe without any kind of garbage collection (I include ref-counting here). That's what enables its deployment in stuff like QEMU or the Linux kernel.
There is a huge learning curve to Rust, one that I am still climbing, but I haven't been as excited learning and working with a new language since 1987 when I learned C afters years of working with Pascal, Fortran, and a number of procedural job control systems.
In the years since, I've written large complex programs and systems in C, JS, bash, and PowrShell, and so far Rust feels like my new forever home, my defauly go to.
I'm glad of this, because my industry is heading to memory-safe, compiled languages, and the others I've experienced don't work for me. It's aesthetic, mostly, I guess, but Rust just makes sense.
You're hurting more than you're helping at this point.
And, just in case you're having trouble following along, as the evidence rather suggests that you are, note that replying with yet another paeon to Rust will be really missing the point.
There is no party line, and there is no tone. There are over 30 years of experience with C, not all of it pleasant, though most of it productive, and, comparatively speaking, amazing recent experiences with Rust. I do have to shift my thinking from how I would solve problems in C, because the memory management paradigm is so different, but, thanks in part to deep dives into scoping in other languages in pursuit of pernicious bugs, once I make that shift, problems are easier to solve in Rust: The language and the compiler, hand in glove, do a lot of the work for you.
You can carp all you like, and that is all it is, carping, not criticism, we'll just happily work along getting a lot done in less time.
Your earlier comment, that his advocacy passes into parody, also seems silly to me. Perhaps you don't believe Rust's merits, and that's fine. Perhaps you don't believe the grandparent, and that's fine too. But either way, his argument was fair.
Edit: I later realized that my comment is mostly just an attack that doesn't really add anything to this thread. I apologize for that.
To add something to it, I'd just like to second that Rust is indeed very easy to write after learning to deal with the borrow checker. Much, much easier than C, and I say that with 15 years of writing various applications in C (with all of the autotools rituals, pthreads, Glib gobject nonsense, GTK/GDK/cairo, etc).
I had a fun little code battle with a colleague, and here's a comparison of Rust [1] vs Python [2]. Although Rust is certainly nowhere near as readable as Python, it was just as easy to write, due to the type-system saving on debugging/learning time.
[1] https://gist.github.com/andreivasiliu/a4a2a6007d1659799b1f80...
[2] https://gist.github.com/lemon24/252ee6aa122a2b38395b096f96cb...
Monomaniacally monopolizing the topic is anti-social behavior.
I mention this because apparently you could use a bit of clue on that as well. You're actively pushing people away from Rust at this point when you resist the clue stick this hard.
It started as a misguided comment that takes a tongue-in-cheek statement but believes it is unironic, followed by a comment saying it was tongue-in-cheek, there is some truth to it, but that truth is hard to believe, and then finally PeterWhittaker's comment, which argues that it should not be that hard to believe after all.
All in a thread that is mostly about Rust.
...I don't know what to say to this except "no?".
I'd have to question what priors someone making that claim is bringing and where they got them from.
> The only language that comes close, AFAICT, is python.
With well over a decade in Python experience and having regularly defended it against many claims of unsuitability for many tasks, I have to call BS on this and say that no, that is not even remotely correct. Of all the possible use cases where Python is an easily dismissed but very defensible choice this is NOT one of them.
> easier and faster to do in Rust, and safer, largely because of Rust's enums (algebraic data types, not as simplistic as C's)
Python enums are largely equivalent to C enums, except you can use string constants as values. Otherwise there's little ergonomic difference.
> and traits
Python Protocols (less anything that came before) aren't even remotely comparable to Rust traits. And neither affords any major advantage to red team style development.
And while memory safety is great for mission critical pieces of a larger system, and language ergonomics are essential for readable and maintainable code, I don't know what either of these possibly has to do with writing exploits.
> shellcode, a web server, and a phishing page in
Python would at least be a better choice than Rust for all of these, but so would have been Perl 20 years ago.
I'm not sure what to say
In both cases, the communities do so much good work that often someone else has at least a partial solution to problème-du-jour, so it can be relatively easy to get at least a prototype or PoC, and learn from it, and sometimes one gets a complete solution to at least part of the problem.
(Although I'm not sure I would consider Rust to be adept in that category either...)
Something like maud[0] + actix[1] perhaps. That's probably something that is possible in python but I wouldn't dare try in C.
[0] https://maud.lambda.xyz/
[1] https://actix.rs/docs
The reason Go got so popular is not because of its type system, but because it also has a mode of programming "good enough" prototypes.
Python for exploit development is also great due to the gdb fork that can generate python payloads, offsets etc, but it sucks for deployment on targets.
If I would compare the three language choices I don't see why anyone would choose Rust over the other two in terms of efficiency and not having to fight the language. I don't even know whether it would be possible to write an exploit that overflows something in an external ABI binary in Rust without sacrificing everything that Rust stands for. After all, the binary would have to be statically linked for deployment, have to support invalid types, have to support invalid control flows etc.
On the other hand, in Go that's what CGo is made for. The VM and GC in Go doesn't care about what CGo does.
Edit: nevermind, the only example that is using Rust for this type of exploits is a sudo cli argument exploit, lol. I would have expected a little more than a char array generator that's using the FFI package. [1]
[1] https://github.com/skerkour/black-hat-rust/blob/main/ch_07/e...
You can Grug program in any language. Including Rust.
Just clone, Arc, and unwrap everything.
The reason why Go got popular is:
A) It's backed by Google (this is essential, there are many languages simpler/easier than it)
B) It's easy to pickup
The real reason Go is a success is the Go team, and engineering prowess they brought to the table.
Go is the language where people get shit done; now, Rust may be "the most loved language" or whatever, but the overwhelming success of Go as a programming platform (which is Rust community is supposedly obsessed with) cannot be attributed to anything else but engineering reasons. People like it. Why do they like it? Because it's easy to use, gets out the way, and it gets the job done. You find a library on Github, read the godoc, and you're literally seconds away from incorporating it in your program. This is not something you can get by accident, by means of investment, or otherwise by making bad design decisions.
The only other project that comes close to what you can do with Go when it comes to mutating binaries is in my opinion the APE/cosmopolitan ecosystem. But those binaries tend to get flagged immediately because there's no major software that's being used that requires APE binaries to run.
On the other hand, the static parts of any Go binary (the head/runtime part) can't be flagged because of so many devops tools rely on Go binaries to work. There was the Ebowla incident in 2016, where all go binaries (including docker) were flagged as malware because the static parts were added as yara rules in Kaspersky and other Antivirus tools. They had to revert those changes after a week.
Why would you fight Rust? It is decent for prototyping.
I used to steer clear of Rust for a lot of problems because of its complexity, now I use it for almost everything and it’s great
Moving on
80% of this site is about pushing and selling stuff. blatant out of the blue spam doesn't have a place here, but discussing (and hating on) Rust is a common topic.