"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
---
Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :)
---
The points, addressed, I guess?
- Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling
- Rust inserts Copy, Drop, Deref for you: it would be really annoying to write Rust if you had to call `.copy()` on every bool/int/char. A language like this exists, I'm sure, but this hasn't stopped Rust from taking off
- Fetishization of Efficient Memory Representation: ... I don't understand what the point is here. Some people care about avoiding heap allocations? They're a tool just like anything else
- Rewrite anything and it gets faster: okay sure, but there are limits to how fast I can make a Py/JS algorithm vs a compiled language, and Rust makes writing compiled code a bit easier. People probably aren't rewriting slow Python projects in C these days
- Rust is as complex as C++: ...no, it's not. Rust really hasn't changed much in the past 6 years. A few limitations being lifted, but nothing majorly new.
- Rust isn't as nice of community as people think: subjective maybe? People are nice to me at conferences and in discussion rooms. There's occasional drama here and there but overall it's been pretty quiet for the past year.
- Async is problematic: Async Rust really is fine. There's a huge meme about how bad it is, but really, it's fine. As a framework author, it's great, actually. I can wrap futures in a custom Poll. I can drive executors from a window event loop. Tokio's default choice of making `spawn` take Send/Sync futures is an odd one - occasionally cryptic compile errors - but you don't need to use that default.
I'm unsure why this article is so upvoted given how vapid the content is, but it does have a snappy title, I guess.
> Rust is as complex as C++: ...no, it's not.
Maybe not yet, but it is heading in that direction; and I only say this because of the absolutely giant pile of features in unstable that seem to be stuck there, but I hope will eventually make its way to stable at some point.
> Async Rust really is fine
I dunno. Always thought it was too complicated, but as another person pointed out avoiding Tokyo::spawn solves many issues (you said this too, I think). So maybe, not Rust's fault :D
> Maybe not yet, but it is heading in that direction
About 95% of the unstable features lift limitations that most people expect not to be there in the first place. I'm not aware of all too many that aren't like that.
> Fetishization of Efficient Memory Representation: ... I don't understand what the point is here. Some people care about avoiding heap allocations? They're a tool just like anything else
The point is that dealing with the Rust borrow checker is a huge pain in the ass and for most Rust applications you would have been better off just using a garbage collected language.
> huge pain in the ass
Maybe if you structure your code weirdly? I haven't encountered a major borrow checker issue that I couldn't easily resolve in many years.
I haven’t had to „deal with” the borrow checker since like 2018. It’s quite smart
I mean, maybe?
If you come into Rust thinking you're going to write doubly-linked lists all day and want to structure everything like that, you're going to have a bad time.
But then in python you run into stuff like:
```
def func(list = []):
list.append(1)
and list is actually a singleton. You want to pull your hair out since this is practically impossible to hunt down in a big codebase.
Rust is just different, and instead of writing double-pointer code, you just use flat structures, `Copy` keys, and `loop {}` and move on with your life.
FYI this site doesn't use ``` for code blocks, it uses indentation (two spaces).
> this is practically impossible to hunt down in a big codebase
use linters, they keep getting smarter
rustc is a good smart linter
I've seen a case where the rust panic handler is used in FFI and this creates a memory leak.
This was an oddly defensive and vapid comment. Mostly just handwaving away any views the article brings up, of which at least the article expands on their thoughts. This comment is just "meh not a bad thing" repeatedly. Why is this comment being upvoted?
The title is inflammatory and yet there are few nuanced takes in the article. It's weird to see it shoot to the top of HN.
I think the loglog article is a much better, nuanced, full critique of Rust.
https://loglog.games/blog/leaving-rust-gamedev/
The internet is just so full of negativity these days. People upvote titles but don't read articles. Reading about people's views on subjects is useful, but I don't think this one is.
Inflammatory? "My Negative Views on X" is pretty far from inflammatory. It is exactly what the post was, with some positivity sprinkled in as well.
> This was an oddly defensive and vapid comment.
Even comparatively, next to your own comment? I have no specific idea of what you object to or why, but I have learned that you are upset.
> Rust isn't as nice of community as people think
It's a numbers game. As the number of people using Rust grows, so does the number of Jerks using Rust. And it's not like the Rust community is a stranger to bullying maintainers of crates for various things.
> Async is problematic: Async Rust really is fine.
It's... OK. It has a few issues, that hopefully will get fixed, like making Pin from a generic struct into a type of reference. e.g. instead of `Pin<&str>` you would write `&pin str`.
There is also the coloring problem which is quite a hassle and people are looking into possible solutions.
IMHO the biggest Rust async annoyance is exactly this:
> Tokio's default choice of making `spawn` take Send/Sync futures
... combined with lack of structured concurrency.
This means async tasks look like threads in every respect, causing you to end up using Arc<> and other concurrency constructs all over the place where they ought not be necessary. This harms efficiency and adds verbosity.
My big problem with Rust is too much "unsafe" code. Every time I've had to debug a hard problem, it's been in unsafe code in someone else's crate. Or in something that was C underneath. I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people seem to use "unsafe" so much.
Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail. Those should be checked at compile time. Detecting a double borrow is the same problem as detecting a double lock of a mutex by one thread, which is being worked on.
> I just do not see why people seem to use "unsafe" so much
Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code in the implementation to allocate heap memory. When you need efficient trees or graphs (I doubt any non-trivial software doesn’t need at least one of them), unsafe code is the only reasonable choice.
C++ does pretty much the same under the hood, but that’s OK because the entire language is unsafe.
C# has an unsafe subset of the language with more features, just like Rust. However, it runs inside a memory-safe garbage collected runtime. Even List and Dictionary data structures from the standard library are implemented with safe subset of the language. Efficient trees and graphs are also trivial to implement in safe C#, thanks to the GC.
> When you need efficient trees or graphs (I doubt any non-trivial software doesn’t need at least one of them), unsafe code is the only reasonable choice.
To name one example, the AnimationGraph in Bevy is implemented with petgraph, which is built using adjacency lists, and doesn't use any unsafe code in any of the parts that we use. It is very high-performance, as animation evaluation has to be.
Non-trivial data structures are often just a bunch of arrays/maps with additional semantics. You may consider implementing/using unchecked versions of basic operations for a little bit of additional performance. If you implement (de)serialization yourself, you may need unsafe code. Sometimes the safety of deserialization may be a convenient lie, if checking the invariants fully would be too expensive. And sometimes you may want to expose internal helper functions for various purposes, which may have to be marked unsafe if they can break the invariants.
Beyond that, you only need unsafe code for specific kinds of data structures. At least in my experience.
> Non-trivial data structures are often just a bunch of arrays/maps with additional semantics
This might be fine for code which consumes data structures implemented by other people. The approach is not good when you actually need to implement data structures in your program.
In modern world this is especially bad for a low-level language (marketed as high performance, BTW) because the gap between memory latency and compute performance is now huge. You do need efficient data structures, which often implies developing custom ones for specific use cases. This is required to saturate CPU cores as opposed to stalling on RAM latency while chasing pointers, or on cache coherency protocol while incrementing/decrementing reference counters from multiple CPU cores.
Interestingly, neither C++ nor C# has that boundary, for different reasons: C++ is completely unsafe, and safe C# supports almost all data structures (except really weird ones like XOR linked lists) because GC.
>> I just do not see why people seem to use "unsafe" so much
>Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code
Hmm.. wasn't memory safety the main selling point for rust? If not the only. Now mix of two languages looks even worst than one complex. Especially taking into account that it can be paired with safe language from long list. Don't know what rust fans are thinking, but from outside it doesn't look very attractive. Definitely not enough to make a switch. Julia looked better at first, but turned out to be just a graveyard of abandoned academic projects.
Memory safety without gc is not the only reason people use rust. It's also nicer to use than C++ for multiple reasons (language features, included package manager, easy to integrate tests...)
> Now mix of two languages looks even worst than one complex.
The point is that the vast majority of code doesn't have to be unsafe. Empirically, Rust code has far fewer memory safety problems than non-memory-safe languages.
Nope it isn't. You just aren't experienced in system programming. Working with hardware is unsafe since it has state that one cannot completely encapsulate in a single program. The entire specific design of a chip isn't available to programmer; only the machine code is. We usually don't know how a processor decides to cache things or switch to kernel permission level. Usually this isn't even the level we're at, OSes have private internals that change behind the programs and they are not accessible from user space. Pressing Ctrl+C to interrupt changes so many things in memory, it would be outright impossible to write programs that handle every single thing.
The fundamental / syntactic promise of Rust is providing mechanisms to handle and encapsulate unsafety such that it is possible to construct a set of libraries that handle the unsafety in designated places. Therefore the rest of the program can be mathematically proven to be safe. Only the unsafe parts can be unsafe.
Coming from Java or Go or Js or Python angle wouldn't be the same. Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data which is necessary when one is communicating with hardware or the OS or just wants to have an acceptable amount of performance.
In C++, the compiler can literally remove your code if you sum or multiply integers wrong or assume the char is signed/unsigned. There is no designated syntax that limits the places possible memory overflow error happen. The design of the language is such that some most trivial oversight can break your program silently and significantly. It is too broad so it is not possible to create a safe and mathematically proven and performant subset with the C and C++ syntax. It is possible with Rust. It is like the difference of chips that didn't have a hardware mechanism to switch between user and kernel mode so everything was simply "all programs should behave well and no writes to other programs' memory pinky promise".
Rust doesn't leave this just as a possibility. Its standard library is mostly safe and one can already write completely safe and useful utilities with the standard library. The purpose of the standard library is provide you ways to avoid unsafe as much as possible.
Of course more hardware access or extremely efficient implementations would require unsafe. However again, only the unsafe parts can cause safety bugs. They are much easier to find and debug compared to C++. People write libraries for encapsulating unsafe so there are even less places that use unsafe. If people are out of their C++ habit, reaching for the big unsafe stick way too often, then they are using Rust wrong.
Whatever you do, there will be always a need for people and software that enables a certain hardware mode, multiply matrices fast, allocates a part of display for rendering a window etc. We can encapsulate the critical parts of those operations with unsafe and the rest of the business logic can be safe.
You fan wrap unsafe implementations with safe APIs. The point is there's an explicit boundary between unsafe an safe.
> Hmm.. wasn't memory safety the main selling point for rust? If not the only.
No. Like, not at all. Java, Python, C#, Go, Ruby, lisps and countless others are “memory safe” in the way that matters. That’s not Rusts unique value proposition.
> I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people seem to use "unsafe" so much.
I agree. I rarely ever use unsafe, and only as a last resort. Unsafe code is really not needed to achieve high performance.
> Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail.
I think this will basically turn into provably-correct data structures. Which is possible to do, and I've long thought there should be systems built on top of Rust to allow for proving these correct. But we should be clear that something like Idris is what we're signing up for. Whatever it is, it is assuredly going to be far more complex than the borrow check. We should basically only use such systems for the implementations of core data structures.
> Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail. Those should be checked at compile time.
It's not clear to me how rustc could detect a dangling backlink in a tree structure at compile time. Seems impossible short of adding proofs to the type system.
> I just do not see why people seem to use "unsafe" so much.
SIMD seems to be a big one.
> My big problem with Rust is too much "unsafe" code.
I hear cargo-geiger is useful identifying such crates.
> I just do not see why people seem to use "unsafe" so much.
Because it's:
A) fast (branchless access)
B) fast (calling C libs or assembly)
C) fast (SIMD)
D) people think unsafe Rust is easier
Want to write a JSON parser that will gobble up gigabytes per second? Your only way is removing as many branches and use assembly as much as possible. Doubly so on stable! I guess the same goes for making a "blazingly fast"™ graphical stack.
People that think unsafe is easier, shouldn't be writing unsafe code. Writing unsafe code correctly is like juggling burning chainsaws. Saying that's easier than using chainsaws is moronic at best.
EDIT: Consider following, if each of your unsafe {} blocks doesn't contain a
// SAFETY:
// Detailed explanation of invariants
It's ugly but it's inevitable in some sense. The author should know what they are doing, and `// SAFETY:` comment is a must.
No. Nobody is going read those (because most people won't even know that some unsafe is buried 5 layers of dependencies below what they work with). The author should make reasonable effort to prove the code is working correctly (and cannot be abused) by other means if possible. It might be a domain issue, so far all my apps are 100% safe (not counting libraries).
Unsoundness is considered a bug and should be reported and fixed.
> Distinguishing mutability has its advantages
I think it's misleading to say that Rust distinguishes mutability. It distinguishes _exclusivity_. If you hold a reference to something, you are guaranteed that nothing else holds an exclusive reference to it (which is spelled &mut). You are _not_ guaranteed that nothing accessible through that reference can change (for example, it might contain a RefCell or other interior-mutable type). Shared references (spelled &) usually imply immutability, but not always. On the other hand, if you hold an exclusive reference to something, you are guaranteed that nothing, anywhere, holds any kind of reference to it.
IMO, the fact that exclusive references are spelled "&mut", and often colloquially called "mutable references", was a pedagogical mistake that we're unfortunately now stuck with.
Needs (2023)
> I predict that tracing garbage collectors will become popular in Rust eventually.
The use of Rc is already very widespread in projects when people don't want to deal with the borrow checker and only want to use the ML-like features of Rust (Sum types, Option, Error etc.)
> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.
I wonder when we will see the rise of Haskell like LanguageExtensions in Rust. AFAIK, pretty much everybody uses things like GADT, PolyKinds, OverloadedStrings etc. The most similar thing I can think of Rust right now for is python-like decorator application of things like builder macros using Bon.
> Async is highly problematic
Agreed. Tokyo is the only reason, I think, anybody is able to use Rust for this stuff.
Does Rc really resolve the core problem this post is talking about, which is that it's really painful to naturally express tree and graph structures in Rust? It feels like I mostly see people talking about building application-layer pointer systems with integers, which would be surprising if (in a single thread, perhaps) you could just Rc your way around the problem.
> Does Rc really resolve the core problem this post is talking about, which is that it's really painful to naturally express tree and graph structures in Rust?
No, but Gc will not resolve the core problem either. The core problem is that rust forbids two mutable pointers into one chunk of memory. If your tree needs backlinks from child nodes to parents, then you are out of luck.
In what way am I "out of luck"? It's trivial to express a tree, including one with backlinks, in Java.
> Does Rc really resolve the core problem this post is talking about, which is that it's really painful to naturally express tree and graph structures in Rust
No, it doesn't. If you naively express graphs containing cycles with `Rc` you will leak memory, just like you would with `std::shared_ptr` in C++.
Considering that there exists a book about building linked lists in Rust[0], I am going to go ahead and say "Unclear" That does not matter though. It is easier (though verbose and often unidiomatic), and hence Rc has become really popular, especially with beginners.
Rc does solve the problem, but it often introduces interior mutability, which ends up causing usability problems. That's why at the end of the day adjacency representations (i.e. integers) are often preferred.
Sure, Rc/Arc absolutely solves this problem. It's not super idiomatic to go crazy with using it like that, but it's possible/acceptable.
Using SlotMap and integer ids, etc. doesn't I think offer any advantage.
I feel pretty comfortable with Rc and Arc, read the "too many lists" book, &c. and feel like it is not actually simple to model trees with Rc? What am I missing? I'd love to be convinced I'm wrong about this (I want to like Rust more than I do).
A tree of Rc/Arc<T> is a tree of references, and is really no different than a Java or Python reference value, except that you'll have to do explicit .clone()s
Is it mutability that's tripping you up? Because that's the only gotcha I can think of. Yes, you won't get mutability of the content of those references unless you stick a RefCell or a Mutex inside them.
Yes! Mutability is what's tripping me up! That is not a minor detail!
Doesn't SlotMap save RAM and pointer dereferences?
What is a slotmap lookup... if not a pointer dereference, or at least a dereference out of a vector likely on heap... so probably a pointer...?
> Agreed. Tokyo is the only reason, I think, anybody is able to use Rust for this stuff.
A lot of problems related to Tokyo can be avoided if you think your code as structured concurrency and avoid using Tokio::spawn. However, too often this is not possible.
I haven't, yet, run into building rust apps that require highly complex async implementations with lifetimes etc. however excluding those situations I've found it very straightforward and easy to use. I've built some applications with a lot of moving parts, mpsc has always been a life saver.
I don't have too much experience with async, but I have noticed a similar pattern. Maybe you are right.
> The use of Rc is already very widespread in projects when people don't want to deal with the borrow checker and only want to use the ML-like features of Rust (Sum types, Option, Error etc.)
And the fact that this hasn't caused alarm is kind of an issue.
The problem with that is Reference Counting is WAY slower than good Garbage Collectors on modern CPUs. Reference Counting breaks locality, hammers caches and is every bit as non-deterministic as a garbage collector.
I actually used to agree that Rust generally wasn't good for high-level application code, but working with Bevy has made me change that opinion for certain domains. I simply haven't seen a system that makes automatically parallelizing all application logic (game logic, in this case) feasible, other than Bevy and other Rust-based systems. The trick is that the borrow check gives the scheduler enough information to automatically safely determine which systems can run in parallel, and that's very powerful. It's not that you couldn't do this in C# or whatever--it's that you won't without a system that helps express your intent and enforces that those declarations are up to date.
For applications that don't need high performance for the CPU code and aren't systems code, sure, Rust may not be a good choice. I'm not writing the server-side code for low traffic Web sites in Rust either.
I learned to program around the peak of object oriented fetishization. Shortly after that came functional programming's moment, and now it seems we are slightly past Rust and other safety focused languages' peak period of hype. All three language families have useful things to offer, but were never the panacea their proponents claimed them to be. "No Silver Bullet" continues to be true.
> People waste time on trivialities that will never make a difference.
This is an aha moment as I read it. The complexity of your tools must be paid back by the value they give to the business you’re in.
Related:
My negative views on Rust - https://news.ycombinator.com/item?id=29659056 - Dec 2021 (89 comments)
I think to some extent Rust is a victim of its own unreasonable effectiveness. It is great at its narrow niche of memory safe low level programming, but frankly pretty good at lots of other things. But at these other applications some of its design principles get in the way - like the pedantic borrow checker. Languages not used outside their niches don't tend to collect such criticism.
Python is a bit like that. It is a top choice for a few things, and ends up used effectively for other things, simply because it is versatile. But then people run into issues with dynamic typing, zero static safety, start slapping type annotations everywhere... and bemoan Python as a bit of a horror show.
My use case for Rust is complementing Python, where frankly I don't care about half the complex features, still it's nicer than C or C++ to code in. The complexities of the borrow checker are more like a tax to me. I understand people who are frustrated with it thought, as otherwise they see it as a bit of a perfect language.
I think in general python gets used because of laziness and vitality. It's just the dumb shit that X person learned first because Y person before then was taught it because it was easy even though it's maybe not even the right choice for example, you can't properly write a working webserver in python without {venv, uvicorn, celery etc.} and if youve ever worked in another language its like why the hell is this shit here? Because it's viral, someone didn't know better, and it stuck.
Same goes for machine learning. The ML folks at the start couldn't be bothered to learn something the least bit sophisticated. Some things are getting better. You don't need conda anymore, tensorflow wheels are out, and at least instead of shippong around .pt, checkpoint, or pickle files at least we use safetensors, but there's still python shit around, like jinja2 templates for conversations, etc.
Anyways if we want good things we need to get better about getting unstuck from these local minima.
I disagree re Python. It is a brilliant, flexible scripting language. It is easy to build expressive libraries such as pytest or argparse, with deep introspection. It is easy to prototype by subtly changing return types, or even keeping them flexible. It is really easy to eg build a custom data type and build custom expression trees, such as what ML often needs.
It has a number of features (often stemming from the above) that make it a PITA for other applications, even when it would be fairly well suited to them otherwise. What I would give for proper static typing for production Python! Alas, that's not coming, and Rust's occasionally mind boggling borrow checker is there to stay.
I like Rust but at the same time I agree with the points here. These things are indeed problems with Rust.
Nevertheless, C++ has even worse problems. When your alternative is using C++, that's the time to consider Rust.
Some points resonate with me:
> People don't want "to have to play Chess against the compiler"
Things that are easy to express in other languages become very hard in Rust due to the languages constraints on ownership, async...
> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.
It's indeed hard to keep up.
> Async is highly problematic.
Yes, more complexity, more fragmentation and feel like another language.
But one point feels unfair:
> the excellent tooling and dev team for Rust [..] pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in.
What? No. The main appeal was the safety. It's still a distinctive feature of Rust. To almost eliminate a whole class of safety issues. It has been proven by several lengthy reports such as https://security.googleblog.com/2024/09/eliminating-memory-s....
They are many projects for which the reliability and efficiency are worth the trouble.
I agree with a couple points here, specifically I agree that choosing a language based on it's community (and not it's ecosystem) is just silly. And we all know that async ended up being a bit of a thorn in rust's side.
But yeah, rust is very much a systems language: so it will be forcing you to think about memory layout one way or the other. Idk how valid of a complaint that is when you really consider that, and specifically the other alternatives you have.
A complication of the "Rust is a systems programming language" thing is that people adopt definitions of "systems" of varying expansiveness to suit the situation. There are unquestionable systems programming domains --- the kernel is a great example, and one where it's easy to see why Rust is an exciting proposition; same with browsers, the "second OS" everyone runs --- and then more questionable domains. Is the framework-layer code for a CRUD web application "systems" code? How about a container orchestrator?
This isn't a criticism of Rust, but rather of the framing we often use to compare Rust and (say) Python or Java.
"Systems programming language" has almost turned into a weird slur; instead of using it to refer to languages that can actually handle that task, they use it to attempt to pigeonhole a language into only that.
As in, people don't realize being a "systems programming language" is extremely difficult to get right, and many languages simply can't handle that (and never will, as per internal design requirements unique to those languages); if a language gets that right, they're going to get everything else right too if people decided to use it for that.
See, depending on your definition of "systems programming language", that is just wildly false. A language that nails all the details and ergonomics of expressing a kernel block device driver is almost necessarily going to be suboptimal for exploratory scientific computing or line-of-business app development.
Again: this is about the term, not about the language. I don't think it's controversial to suggest that there is no one ur-language that is optimal for every problem domain!
I don't think the people that use it as a slur actually define it. They use it to mean the language they don't like because they think it has some level of enforced complexity that takes away from the language instead of being an important feature of the language.
Yes: it's about the distinction between global GC and programmer-defined memory management. GC is about as straightforward a tradeoff as you can make: remove a very large class of programmer concerns in exchange for a different performance envelope. It is not reasonable to argue that Rust's memory management doesn't represent a point on a tradeoff space --- that people suggesting GC languages are better fits for some problems just don't grok Rust well enough. That's a common trope, and it's pretty obviously false, just as it would be false to say that kernels should just supply a GC runtime so we can write device drivers in Java.
Rust makes you think about your memory layout, memory allocation and avoiding thereof, about the specific time you grab and release other resources, about specifics of your inter-thread interactions, etc.
If such considerations are natural for your problem domain, you likely do "systems programming" and also happen know C, have an.opinion on Zig, etc.
If such considerations are the noise which you wish your language would abstract away, then you likely do "application programming", and you can pick from a wide gamut of languages, from Ruby and Python to Typescript to Elixir and Pony to C#, Java, and Kotlin to OCaml and Haskell. You can be utterly productive with each.
What does "think about your memory layout" mean? Can you provide an example? I've seen this brought up a few times on this thread and have no idea what people are referring to when they say it.
As for the rest of your list - I'm not sure why rust is special in regards to "the specific time you grab and release resources" or "inter-thread interactions". Seriously - I have to think about when I acquire and release resources like sockets and file handles python, c, ocaml, java, c#, and every other language I've used. Its not like you can randomly call file.close() or close(fd) (in python and c respectively) and expect to be able to continue reading or writing the file later. Same for inter-thread interactions... all those languages have mutexes too. Like none of that is rust-specific, its just the consequence of using resources and threads in code.
Again, the subtext here is GC versus direct control of memory lifecycles, and it is probably not reasonable to argue that there isn't a tradeoff here --- that every application is as gracefully expressible in one as the other, so long as you "git gud" at it. Both sides of this debate are guilty of deploying that trope.
Yeah I use often Rust where Python would be enough. But unless I really need quick/interactive feedback (for exploratory stuff ie.: Jupyter with plots), Rust suits me well.
I enjoy expressing applications in C. Once a week, a story hits the front page here about someone shipping a web app in C. C suits me well. But I don't pretend that's an objectively reasonable engineering decision. It is not.
> People waste time on trivialities that will never make a difference.
Depending on the situation, memory layout could be trivial (copying 200 bytes once at startup vs. not in a way that should never be user-perceptible and difficult to even measure) or actually a big deal (chasing down pointers upon pointers in a tight inner loop). It's entirely situational. To dismiss all of that as "trivial" and saying it will "never" make a difference is not helpful. There are a lot of shitty apps that are impossible to get running reasonably without a total rewrite and their shitty use of memory is part of that.
Criticising a systems programming language for needing to manually manage memory is honestly embarrassing.
I mean to be fair so is using a systems programming language for every use case under the sun. If Rust is a great systems programming language that’s one thing. If it’s a general purpose language that’s another.
A lot of git(1) subcommands were originally written in shell or Perl. Now most are written in C.
Through many decades people wrote utilities and applications in C. Not hardcore lower-level kernel modules. Just utilities and applications. Because that’s what they wanted to write them in. Over Perl or Java or whatever else the alternatives were.
What’s more C than that? Writing everything short of scripts in it?
Now people write applications in a modern programming language with modern affordances. They might be working uphill to a degree but they could have chosen much less ergonomic options.
The embarrassing part is criticizing people who have put in the work, not on the merits of their work, but on… having put in too much work.
The two are not mutually exclusive. Also, I don't think I have ever needed to actively think about memory management more than .clone() and static for any hobby project I have undertaken. All the ML-like features like sum types, pattern matching etc. add great value. Cargo too. So, it is a great general purpose programming language. But blaming it as too low-level or similar despite choosing it is obtuse at best.
The subtext is that most of the time it won't make a difference, and Rust demands that you consider it every of the time. That squares with my experience. The powerful argument Rust has is that in the hotspots where memory lifecycle and layout make a huge difference to programs, it's much easier to express the fast and predictable memory arrangement than in GC'd languages.
Thinking like that is how we get 12MB of javascript to read a news article, or mobile apps that are jankier than Word 97.
I don't get how someone can criticise a systems programming language by saying "I have to think about memory layout"....
There's a response to your comment in the post:
> I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things.
> This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for.
> This post still offends many who have tied Rust to their identity, but that’s their problem, not mine.
Who uses panic instead of `?` and anyhow / Box<dyn Error> (error propagation?)
I think there is even a (gross) way to achieve try/catch around a block of code that panics?
Yeah, panic/assert is only for Things That Really Shouldn’t Ever Fail, If They Do Our Base Assumptions Have Broken.
whereas Error is for things that are unlikely to fail, like network/filesystem requests and recoverable logic bugs.
rust is fine, it's a solid mix of performance and expressiveness, it has good constructs and it's gaining traction
it's hard to learn so we shall see what kind of niche it can carve for itself, but it's fine
> it's hard to learn
And as long as Rust remains popular, this is why we will witness endless complaining about it. Most devs are lazy, and would rather sweep complexity under the rug and pretend it doesn't exist until it becomes a real problem they can't ignore anymore. That's fine. But no need to be so vocal about it. At this point, people whining about Rust is more of a trope than people proselytizing it.
> Most devs are lazy, and would rather sweep complexity under the rug and pretend it doesn't exist until it becomes a real problem they can't ignore anymore
You mean pragmatic. Not all of us are memory absolutists. The time ideally invested in memory management really depends on the problem space, the deadlines, etc.
> At this point, people whining about Rust is more of a trope than people proselytizing it.
This is common pattern reminds me cross-fit/veganism/i-use-arch/etc. Almost like an echo.
So much to disagree with....
> In practice, people just want to be able to write a tree-like type without having to play Chess against the compiler.
Sure, Rust's strong encouragement of tree-structured ownership may be annoying when you try and make a spaghetti ownership soup, but it's not like it doesn't have upsides. Many people have written about how the ownership & borrowing rules lead to code structure that has fewer bugs.
> I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement.
Maybe, but I think this is missing the point. The "rewrote it in Rust and it's X times faster" stories are generally when people rewrite from very slow (Python) or medium fast languages (JavaScript or maybe even Go).
In those cases you can rewrite in Rust without considering performance and get amazing speedups. I recently did a straight 1:1 port of some Python code with zero extra optimisation effort and got a 45x speedup.
Sure I maybe could have got the same in C or C++ but there's no way I would have rewritten it in C++ because fuck segfaults and UB. I don't want to spend any more of my life debugging that.
> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.
I don't really know about Haskell, but I don't think Rust's complexity is anywhere close to as bad as C++'s. Even if it were it doesn't matter because in Rust if you forget some complex rule the compiler will tell you, whereas in C++ it will randomly crash but only in release mode after the program has been running for 2 hours. Totally different.
> The “Friendly” Community
Gotta agree with this though. The "we're friendly" thing is bullshit.
> Async is highly problematic
Also agree here. Async is a huge wart on Rust's otherwise relatively unblemished face. Big shame. Oh well. You can mostly avoid it, and there are some cases where it's genuinely good (e.g. Embassy).
> I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. > > This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for.
I don't see why he's disappointed about this. Rust is great for command line tools and web backends.
> I think that the excellent tooling and dev team for Rust, subsidized by Big Tech, pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in. There’s danger in that type of thinking.
Ok this guy is not worth listening to.
First off, if you edit the "this guy is not worth listening to" out of your comment, you'll probably get better responses from people.
Second: I don't think this author disagrees with you that there are huge speedups to get from porting code out of Python. But you'd also get huge speedups porting to Java, and you wouldn't be in the business of managing your own memory lifecycles.
I don't think that was too harsh given that he's saying that everyone who likes Rust (an extremely popular language) is an idiot who has been tricked into thinking it's good.
How can you take opinions like that seriously? It's like saying "nah The Beatles weren't actually that good, everyone just thought they were because of their cool sunglasses".
It's patronising and illogical and I don't think it's worth listening to nonsense like that.
He didn't say that at all.
I'm curious what kind of code gets a 45x speedup by going from python to rust
and by that I don't mean the rhetorical or bait-style "i'm curious", no, the literal I'm curious, cause I'm trying to find use cases such as that these days and I'm often thwarted by the fact that for anything requiring remotely decent speeds, python most of the time already delegates to C extensions and so any rewrite is not as useful
"I'm often thwarted by the fact that for anything requiring remotely decent speeds, python most of the time already delegates to C extensions and so any rewrite is not as useful"
Be sure you verify this is the case for whatever you think it is, though. Pure Python is so much slower than compiled languages (not just Rust) that you don't have to do much percentage-wise in pure Python before you've badly fallen behind in performance versus the pure-compiled alternatives.
I think this is asserted a lot more often then it is benchmarked. I am reminded of the way people for a long time asserted that the performance of web languages doesn't matter because you spend all your time waiting for the database, so it never mattered. People would just whip this argument out reflexively. It turns out that if you take a non-trivial codebase written in such a language and actually benchmark it, it is often not true, because as applications grow they tend to rapidly outgrow "all my code is just running a SELECT and slamming the results with minimal processing out to the web stream". I hear this a lot less often than I used to, probably through the slow-but-effective process of a lot of individuals learning the hard way this isn't true.
I've seen a lot of Python code. Very little of it that was not "data science" was just a bit of scripting around lots of large C-based objects, such that Python wasn't doing much actual work. And even some of that "data science" was falling back to pure Python without realizing because NumPy actually makes that shockingly easy.
This is an old example, but - date/time parsing.
A coworker of mine years ago was trying to parse out some large logfiles and it was running incredibly slowly (because the log file was huge).
Just for fun he profiled the code and found that 90% of the time was spent taking the timestamp ("2019-04-22 15:24:41") into a Python datetime. It was a slow morning, so we went back and forth trying to come up with new methods of optimizing this parsing, including (among other things) creating a dict to map date strings to datetime objects (since there were a lot of repeats).
After some even more profiling, I found that most of the slowdown happened because most of Python's strptime() implementation is written in Python so that it can handle timezones correctly; this prevented them from just calling out to the C library's strptime() implementation.
Since our timestamps didn't have a timezone specified anyway, I wrote my first ever C module[0] for Python, which simply takes two strings (the format and the timestamp) and runs them through strptime and returns a python datetime of the result.
I lost the actual benchmark data before I had a chance to record it somewhere to reproduce, and the Python 3 version in my repo doesn't have as much of a speedup compared to the default Python code, but the initial code that I wrote provided a 47x performance boost to the parsing compared to the built-in Python strptime().
Anyone who had a similar Python script and converted it wholesale to Rust (or C or Golang, probably) would have seen a similarly massive increase in performance.
One could argue that writing a timestamp as a string which then has to be parsed is silly and instead it should be delta-of-delta encoded and packed into variable width integers, but even then double integrating and constructing a datetime for each one would still be expensive in python, only less so.
Anecdotal experience: we rewrote an image processing algorithm from numpy+scipy to pure rust and got a 50x speedup in release builds, without even spending any effort optimizing the rust side.
There are further improvements possible around memory allocation and cachelines, but 2 days for 50x improvement was sufficient to not make it worth investing additional effort.
Edit: this was from a team who had _never_ touched Rust before.
> I'm curious what kind of code gets a 45x speedup by going from python to rust
Pretty much any code that is not just tying together external libraries?
If you heavily rely on the Python standard library, then you’re using a lot of Python code that doesn’t call out to C extensions. Peruse the standard library code, if you want to get a sense of it: https://github.com/python/cpython/tree/main/Lib
So you can expect any code that heavily relies on the standard library to be slower than the Rust equivalent.
A purely interpreted language implementation (not JIT’d) like CPython is almost always going to have a 10x-100x slowdown compared to equivalent code in C/C++/Rust/Go or most other compiled/JIT’d languages. So unless your program spends the vast majority of time in C extensions, it will be much slower.
Conway's Game of Life perhaps is a good example: it's a simple program, with a tight loop and cheap calculation in the loop. Python's loops are slow. I wouldn't be surprised if the speedup was much greater than 45x.
It is basically reading a massive JSON file containing a few thousand logs and then scanning them with a load of regexes.
I was a bit surprised how much faster it was too. Apart from Python being dog slow the only thing I really changed was to use RegexSet which isn't available in Python. I didn't benchmark how much difference that made though; I just used it because it was obviously the right thing to do.
That's kind of the point. If you just do the obvious thing in Rust you get very good performance by default.
It's the same in C++ but then you're writing C++.
I've read this before, it's been passed around the Rust community a few times.
The annotated tl;dr is: Chris doesn't want to learn how hardware works, they don't want to learn how to write optimal software, they don't want to write safe software, they just want to write in a language they already know because they're not comfortable with learning other languages because their home language is a functional language (Haskell). It's a weird, yet short, essay that doesn't actually go anywhere.
I suspect Chris wrote the essay against their will, or because people asking them about Rust rubbed them the wrong way, because they lash out and say "This post still offends many who have tied Rust to their identity, but that’s their problem, not mine."
Its the Internet, man, if you're not offending someone, nobody is reading your shit.
So, we should be focused on attacking the author, not the points raised in the article?
Surely someone who writes a lot of C code as he mentions has written it for hardware, no?
Take a gander at the rest of that blog, they're a Haskell main.
Chris is a team of people? I thought he was just one developer
If you re-read the sentence with s/Chris/The Author/ I expect you'll find the pronoun cromulent. "They" was exclusively plural in Middle English in the 1300s, but, we're not speaking Middle English.
What makes you think they're a team?