> Maybe not yet, but it is heading in that direction;

It's definitely getting more complex, but C++ has a huge lead haha. C++ is like a fractal in that you can look at almost any feature closer and closer to reveal more and more complexity, and there are a lot of features... Here's a page on just one dark corner of the language: https://isocpp.org/wiki/faq/pointers-to-members and it interacts in interesting ways with all the other corners (like virtual vs non-virtual inheritance) in fun and exciting ways...

Also, there are far more ways to cause UB in C++. Rust has a big lead on formalizing what constitutes UB, and even those rules you only need to learn if you are using "unsafe", whilst in C++ you don't have that luxury.

> 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.

> Maybe not yet, but it is heading in that direction

When people say that Rust is complex, they often neglect to differentiate between implementation complexity and developer facing complexity. The implementation complexity is growing in part to support the end user simplicity. I also don't understand why anyone feels the need to know every feature of the language. You can just learn about and use the features that you need.

> Maybe not yet, but it is heading in that direction

I have little doubt that Rust will end up being as complicated as C++ eventually, but a big difference is how explicit and well documented the discusson of new features are.

The Rust RFCs provide a ton of context to almost every feature of the lagnuage. I find that historical context extremely helpful when trying to figure out why something is the way that it is.

There may be something like that for C++, but I feel like a lot of it is "you had to be there" kind of reasons.

> 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

Having just delved into Rust a little (and then given up and decided to learn Dart/Flutter for more practical applications development - I don't need another language to make command line tools in), this one I did feel while I was going through documentation.

The problem is most of the important problems you deal with while programming require heap allocations: i.e. a lot of Rust advice is liable to lead you astray trying to find over-complicated solutions to optimizations you probably don't need up front.

So in terms of systems programming, Rust is technically good here - these are all things you'd like to do on low level code. On the other hand if you're making a bunch of web requests and manipulating some big infrequently used data in memory...Box'ing everything with Arc is probably exactly what you should do, but everyone will tell you to try not to do it (and the issue is, if you're like me, you're coding in the "figure out what and how to do it" phase not the "I have a design I will implement optimally" phase).

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.

Yeah. I wouldn't use Rust as a scripting language for that reason. But some critical applications want that enforced correctness and (hopefully) proper performance to be guaranteed if you pass the compiler.

I want to eventually join the "50 engines for every game" race that is rust gsme engineer development, but I'm sure not going to have the fast iteration part of design be done in Rust. The renderer and all the managers should be absolutely solid, but some parts of games need you to break stuff quickly.

Well, if the entirely of that list is as awesome as those 3, then it's a good list to be.

What is the 90-9-1 rule?

First, things don't panic a lot in my experience writing Rust for the past three years. Second, when things do panic, it indicates a defect in the code that needs to be fixed. Aborting the program with a stack dump is the perfect behavior for seeing the state and the invariant that was violated and then figuring out the fix. Contrast this to C or C++ "limping along", usually until a later invariant causes a crash and being further away from and obscuring the true root cause, and we see why C and C++ code is generally still so bug-ridden relatively speaking. Fail-fast is not just a buzz word and program bugs are not recoverable errors. See https://joeduffyblog.com/2016/02/07/the-error-model/

Things should not panic a lot, and when I’m going over someone else’s Rust code I will discourage them to use panic at all if it’s socially appropriate.

Inasmuch as I am aware, the correct usage of panic is “there is no way to recover from this without leaving the application in an undefined state”.

Not “a file I expected to exist wasn’t there” or “the user gave bad input” or “I didn’t implement this feature yet”.

But more like “a cosmic ray must have struck the machine or something, because this ought to be logically impossible.”

Or pretty much, if you literally don’t see a mechanism in Rust that can pass an error upwards and the program also cannot continue execution without the result being affected, then you panic.

That’s a little stricter than what I understand the official guidance is, but not much.

If you have something panicking it should be less “I can’t see what’s going on” and more “thank god it stopped itself so it didn’t write bogus data to production.”

It is not.

Only about 1/3 of those are language features. Out of those a ton are #[cfg] related (i.e. being able to more accurately doing conditional compilation), const (lifting limitations with compile time evaluation), documentation, architecture specific additions (like intrinsics) and co.

I only see about like 30 or so that are actual proper language additions, some of which are just exploration without even an RFC either, leaving us with about 15 or so, which really isn't that bad.

Rust is nowhere near C++’s complexity.

And most of C++’s language complexity doesn’t come from “large scale industry deployment”, it comes from implementing a feature in a half-assed way, then updating it, but then the old feature needs to be kept around so all the libraries need to deal with two ways of doing things. Then something new and better comes along, and it needs to deal with three ways of doing things.

Meanwhile, developers get frustrated with how difficult the abstractions are to use, and end up carving out their own codebase-specific coding standards.

On Rust’s side, there’s 10x the emphasis on making things easy to use, so developers converge to consensus on pretty much the same modern style.

Just look at project management. Before I even write a project, with C++ I’m hit with choosing between a barrage of build systems and package managers, none of them particularly good. Will I use cmake and Conan? Then I’m stuck writing several lines of boilerplate before I even get started in a weird non-imperative language.

In Rust, I type cargo init and I’m ready to go.

C++ has basically completely fallen down when it comes to language design, and from what I’ve seen, is simultaneously in denial that things are so horrible for its end users (Bjarne Stroustrup iirc putting out an essay where he claimed “C++ is fine for any project I’m concerned about”) and suddenly trying to rush to (badly) copy features from Rust, and only recently coming to the realization that it really needs to abandon some of its fundamental precepts to stop self-sabotaging by carrying around massive amounts of baggage that nobody should be using anymore.

Meanwhile even the White House and other government agencies are saying “please use anything but C or C++”. Because ultimately, no one writes anything close to modern C++, and even modern C++’s memory safety guarantees are painfully minimal in exchange for massive amounts of code complexity (you still have to track every pointer lifetime yourself, and every safety abstraction is opt-in, so you still have to have the expertise to not cut yourself, and every codebase is unique and different in its conventions, which precludes running any kind of static analysis that could rival Rust without significant time investment).

It’s just..really bad. The only way Rust will get there is if it falls prey to the same feature hoarding as C++

But Rust already has a deprecation-and-removal process for features, as well as an edition system to provide backwards compatibility for old code, and standardized tooling for linting that’s 10x better at telling you how to refactor than anything I’ve seen with C++.

And god help you if you have an error in your code, because the C++ compiler will probably dump you out with a dozen irrelevant errors of dense template code you need to skip over, while with Rust you’ll make a mistake with lifetimes that will generate a text visualization of what you did wrong with the compiler pointing to what you need to change. Plus the Rust program will probably just run the first or second try, whereas the C++ program will segfault for the next ten minutes or so, because all the strictness in Rust means the complexity is more meaningful and less performative.

Look at what people are learning in schools today and I bet they’re still starting with new and delete or even malloc and free rather than things like std::make_unique and std::span.

The whole C++ ecosystem is basically predicated on nearly everyone having incomplete knowledge and doing something different and having to support or account for infinite combinations of features, whereas Rust has a higher barrier to entry but you can presume that pretty much everybody is using an idiomatic set of constructs for a given edition.

Anyway, sorry for beating that over your head. I started with C++ around the time of Visual C++ 6, and to me it’s absolutely shameful at how bad the language has gotten. Whole ecosystems (C#, Java) and subsequent ecosystems (Go, Rust) have arisen in response to how bad people have it programming in C++, and despite two decades of people running away from C++ to create their own general-purpose programming language, so many proponents of the language seem to still be in denial. They’ve simply shifted the goalposts from C++ being the general-purpose programming language to it being a “systems” language to rationalize why the vast majority of developers don’t use it anymore because it refused to evolve.

I see people these days comparing it to COBOL, that is, it’s not that anyone wants to use it for the merits of its language design, it simply has incumbency status that means it will be around for a long time.

It's not too hard to do tokio without Send/Sync futures. See the example in https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html... It's kind of annoying that the current_thread flavor of the executor doesn't automatically enter a LocalSet and make spawn_local work out of the box but it's easy enough to do at the beginning of your program.

I use Box::leak without shame.

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.

> 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.

> 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.

>> 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.

> Because it’s impossible to implement any non-trivial data structures in safe Rust

This is why I think rust is great for application programmers. Honestly high performance web servers, games, anything in that realm it's pretty good for.

Low level systems and high performance data structures are better implemented with direct memory management, but the consumers of those libraries shouldn't have that same burden (as much as possible).

Granted, I haven't worked with rust enough to run into issues with other people's unsafe code.

> I think this will basically turn into provably-correct data structures.

That's kind of what I'm thinking. The basic idea is to prove that .upgrade().unwrap() and .borrow() never panic. This isn't all that much harder than what the borrow checker does. If you have the rule that the return value from those functions must stay within the scope where they are created, then what has to be proven is that no two such scopes for the same RefCell overlap. Sometimes this will be easy; sometimes it will be hard. A reasonable first cut would be to check that no such scopes overlap for a specific type, anywhere. That's rather conservative. If you can prove that, you don't need the checking. So it's an optimization.

>people think unsafe Rust is easier

If that's their line of thought, I don't know why they simply don't use C/++. Or even C# with unsafe blocks. I know you said the same, but I wanted to reiterate that.

But yes, I can see a few very specific cases where unsafe access is needed. Emphasis on "few". I think anything past some fundamentals should be at best a late optimizing step after an MVP is established.

I also think, if it's not already there, that crates should be able to identify if it's "safe" or "unsafe". Same mentality where I'd probably want to rely on safe crates until I need to optimize a sector and then look into blazing fast but unsafe crates.

If the language actually supported a full set of memory policies it would be quite possible.

Unfortunately it only thinks about are unique, an opinionated form of borrowed ownership, and a little bit about shared (weak I think is punted entirely to the library?), and not all other ownership policies can effectively be implemented on top of them.

The usual thing approach would be:

  given two types, P and C (which may be the same type in case of homogeneous trees, but this), with at least the following fields:

  class P:
    child1: ChildPointer[C]
  class C:
    parent: ParentPointer[P]

  p.child1?.parent = null
  c?.parent?.child1 = null # only needed if splice-to-steal is permitted; may need iteration if multiple children
  p.child1 = c
  p.child1?.parent = p

A have a list of several other ownership policies that people actually want: https://gist.github.com/o11c/dee52f11428b3d70914c4ed5652d43f...

This annotation would be useless, because it would infect ~99% of your codebase. All IO is implemented as unsafe FFI calls or unsafe inline assembly somewhere down the stack. And even "pure" types like Box, Option, Vec have a lot of unsafe in their implementations. At some point these standard implementations just have to talk to an allocator which is implemented unsafely (obviously), or they have to construct a slice [1], etc. Would you make an exception for the standard library and why? I think, this just doesn't make sense. It's all unsafe somewhere down the stack.

[1] https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

It is explicitly mentioned that ubsafe is in their dependencies not their own code.

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).

> 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++.

> 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.

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.

[0] https://rust-unofficial.github.io/too-many-lists/

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 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.

That’s technically possible, yes, but I really doubt there is any appetite to change basic syntax like that when it’s already so ingrained in everyone’s mind.

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.

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.

Games themselves, not game engines. Systems code, game engines, and games.

This isn't meant to be an exhaustive list--it's just the domains I have experience with that Rust was a good fit for. Lest it seem like I'm saying Rust is a good fit for everything I've done, I also worked on Firefox where the UI was JavaScript, and I wouldn't hurry to rewrite that code in Rust. Nor would I want the throwaway stuff I write in Python or Ruby to be Rust.

That's not the point, though. The author says:

> Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest. Go was designed as the antidote to this kind of endlessly increasing language surface area.

Yes, Rust learning curve is much steeper and the "language surface area" is big, but it's not changing much in recent years. Go getting generics is much bigger change than anything that Rust got in a long while.

I guess it depends on what libraries you're using, but honestly a lot of very popular libraries are at 1.x and hardly change. Honestly I'm not sure where people are getting these experiences from. I feel like either they make it up or they talk about experiences from 2017 or sth. Or maybe they are very unlucky when choosing dependencies?

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.

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.

"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.

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.

> 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.

> 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.

It's the opposite for me. I would put more effort into Rust, but I'm not going to invest in learning how to write safe rust if my libraries are built on unsafe.

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.

"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.

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.

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.

[0] https://github.com/danudey/pystrptime/

> 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.

My "I'm gonna learn Rust!" initial project was porting a callgraph traversal tool from Python to Rust. For loading in my input file, the speedup was very disappointing: 1x. (As in, no speedup at all.)

Then I learned about the `--release` flag and it instantly became a 40x speedup. So that was nice.

Waiting 30s vs <1s puts it well within "anything requiring remotely decent speeds". But it was really about parsing a custom data format, nothing fancy. I haven't done comparison timings of the graph traversals, but everything is basically instantaneous in the Rust version and not in the Python.

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++.

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.

The author predicted it.

Take a gander at the rest of that blog, they're a Haskell main.

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.

It is common to use "they" for singular unknown people, e.g. "Someone left their coat here."

I'm not OP, but since I don't know anyone on the Internet, I have the habit of using "they" for everybody, for example: "WildRookie? No, I don't know their real name, only that username."

It could be that OP has such a habit, which just carried over for referring to Chris, even though someone named "Chris Done" is probably a man (although, there are women who go by Chris).

What makes you think they're a team?