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

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

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.

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

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

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/

It is not.

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.

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.

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

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

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

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

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

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

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

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.

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.

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.

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.

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

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

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.

What makes you think they're a team?