I know this section is really just a comparrison of pyproject.toml and cargo.toml, but who on earth would use pip instead of UV as a drop-in replacement in 2026? Though calling it a comparrison is a bit of a stretch considering there is no text.

On top of that, I imagine that a lot of Python programmers who actually do use pip would also use requirements.txt and not pyproject.toml

Random chapter so you can judge the quality for yourself: https://microsoft.github.io/RustTraining/python-book/ch09-er...

And the non-stop bullet list slop just looks horrible: https://microsoft.github.io/RustTraining/python-book/ch01-in...

Seems like this isn't limited to the Python book though, and others have the same issues: https://github.com/microsoft/RustTraining/issues/14

    Common Python Pain Points That Rust Addresses

    1. Runtime Type Errors
    
    The most common Python production bug: passing the wrong type to a function. 
    Type hints help, but they aren’t enforced.

Then comes calling out the existence of None, the GIL and packaging as common "pain points". None of these have posed any problem to me essentially ever. Packaging used to be honestly annoying but since uv hit the scene, not at all.

I should have known better and stopped after reading "microsoft".

The explanations are extremely short and I imagine a new Rust dev would not understand what is going on.

The Brown tutorial is far better, compare its section on mutables and ownership to this.

And yes, this entirely thing is AI generated. Why was this created?

I am just extremely grateful in general for anyone who takes the effort to put something out there for public education for free. If you are one of those, irrespective of how your content is appreciated, please take my heartfelt thanks. You guys are at the forefront of restoring my faith in humanity.

That said, one of the places Rust loses people pretty early on is an example they have early in this intro:

```rust

let parts: Vec<&str> = "a,b,c".split(',').collect(); // Vec<&str>

```

I never understood why Rust didn't / couldn't make functions able to return different outputs depending on context. If you chain `.split()` to something else that can take an iterator, you want to pass an iterator. If you don't, ~99% of people would probably rather have a collected array. And if you want an `it`, you could just do `.it()` or this is when type inference could be overloaded and you could do:

```rust

let it: Split<'_, char> = "a,b,c".split(',');

```

I think Rust should've put more effort into making the thing newbs want to do the default, and easy ways to get the most efficient thing for experts.

```rust

let parts = "a,b,c".split(); // Gives an Array/Vec

let count = "a,b,c".split().count(); // Optimized stream, no array allocation

```

It could work like that, and I think almost everyone would be happy. But it doesn't.

Instead, they've created a language that I think could have been nearly as easy as a scripting language, but isn't.

It obviously isn't only collection iterators this applies to. There's dozens of very small places that add up and make what - I believe - is an otherwise relatively easy and sensible language feel too far out of reach for too many people.

`Option<T>`, `Result<T, E>`, `Future<T>` all impact linguistically how you can interact with a Type. I think the impacts of this don't make sense to people who've never encountered this before. `Arc<T>`, `Rc<T>`, `Mutex<T>`, and `RwLock<T>`, etc also have similar consequences.

Not only do people just not get it. But also, the type system quickly becomes "scary". To do pretty basic concurrency, you need to build a pretty "scary" looking type if you come from Python.

Which is why I'm a psychopath and attempting to create a language where it defaults to the things most people want, and it's very easy for experts to override.