10 ms·

Introduction – Rust for Python Programmers

71 points by linhns 3mo ago

Tiberium 3mo ago
The whole "book" seems to be AI-generated, or at least very heavily AI-edited. Would at this point it not be easier to just tell developers to use their LLM of choice to achieve the same (or, likely, better) result? Random chapter so you can judge the quality for yourself: https://microsoft.github.io/RustTraining/python-book/ch09-error-handling.html 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-introduction-and-motivation.html#when-to-choose-rust-over-python 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 https://github.com/microsoft/RustTraining/issues/14
onlyrealcuzzo 3mo ago
I can't recommend Rust enough. It has such a bad reputation, but it isn't that hard. I truly think it's easier than many languages with much less-intimidating reputations. 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.
- mightyham 3mo ago
  Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. If it's an issue that you have to chain one extra collect call, just write a helper function for splitting that returns a vec.
  - onlyrealcuzzo 3mo ago
    > Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. I think you're assuming the language won't warn you if you're doing something cost ineffective, and that there aren't modes to compilation which will make you make things explicit whenever its ambiguous. For a person to get started, they should be able to compile in `easy` mode and do things that make sense to them, and the compiler should only bitch at you to be pedantic when you ask for that. Especially because an LLM can probably do that pedantic part for you. You: write code almost as high level as a scripting language, it works, turn on strict mode, most of the time you get auto-fix solutions/options from the compiler. That's my opinion anyhow. I assume most Rust people won't like it. That's fine. You already have your language! I'm not trying to make a slightly different Rust for Rust people... I'm trying to make Rust more accessible to everyone else.
- embedding-shape 3mo ago
  > I never understood why Rust didn't / couldn't make functions able to return different outputs depending on context Referential transparency probably being the first reason I could see. Having the behaviour of a callee sounds horrible and something we usually try to actively work against, you want to be able to look at the function in isolation and be able to understand how it works and what values it gives back, without jumping around and seeing where it's being called. And yes, I'd agree with your last part, you do sound a bit like a psychopath ;) With that said, the world needs those too, so I hope your experiment is fun and brings you lots of learnings, enjoy! :)
- sgeisenh 3mo ago
  This closely resembles implicit conversion from C++ and in many serious codebases it is considered poor practice because it leads to a lot of hidden control flow. I think Rust strikes a nice balance but there’s enough magic that some people still get frustrated. Following traits can get tedious at times.
iloveoof 3mo ago
This tutorial is very bad, and the time estimates are pretty absurd. 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?
- embedding-shape 3mo ago
  > and the time estimates are pretty absurd. I wonder when LLMs will catch up with the new timelines, they frequently cite days/weeks of worth, then you say "Ok, implement that" and 30 minutes later everything been implemented. But seems they themselves is stuck not realizing they're not estimating for human timeframes anymore.
  - tclancy 3mo ago
    I actually asked Claude about that this week and it was fairly interesting: the estimates are based on historical data, so I think that suggests in the current set up there will always be wild gaps. As best I could tell, the estimates you get are probably for the model one or two whole versions ago?
- onlyrealcuzzo 3mo ago
  Link to the Brown tutorial: https://rust-book.cs.brown.edu/ https://rust-book.cs.brown.edu/
- pie_flavor 3mo ago
  In my experience working with newbies, the alterations Brown makes to the chapters on borrowing are strictly worse. It is entirely focused on ramming the difference between the stack and the heap down your throat, which has nothing to do with ownership and borrowing, and newbies will frequently say that they are extremely confused by the chapter, then sigh in relief upon reading the original version. Just use the official guide, nobody has improved upon it yet. https://doc.rust-lang.org/book https://doc.rust-lang.org/book
Quothling 3mo ago
> Cargo vs pip/Poetry 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
- nickpsecurity 3mo ago
  People learning Python or searching for it will run into endless answers using PIP. Then, lots of advice on how to work around PIP's problems. Then, multiple alternatives they have to consider. I only recently started using UV after going through all that. Packaging, concurrency, and type errors had me strongly considering switching to Go or Rust recently. These are such long-solved problems in other languages that I question why we should put up with it in Python. Then, I remember it was the ecosytem, including job market and AI performance, that made me use Python. So, maybe a Python/Rust combo... There's the extensions the OP article mentioned and a Python interpreter written in Rust.
- poulpy123 3mo ago
  Because it's rust for python dev, not rust for python dev who use uv. I would understand your comment if you mentioned poetry, but pip has been the standard for years
- kermatt 3mo ago
  Because Astral is now owned by a profit driven org, and that often becomes problematic. Also because Pip ain't perfect, but it is stable in a sense.
muadddib 3mo ago
What pathetic garbage AI slop. I apologize to everyone who clicked and wasted their time.
dartharva 3mo ago
Jeez, what a hostile crowd. I personally am just glad companies like Microsoft, that infamously used to charge for every material they put out, have been providing free learning resources to newcomers like this, quality notwithstanding. 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.
paultopia 3mo ago
I feel like this is a lost cause, but why do people who publish these online free book-like-substances never make the files available as a single download? Do I really need to run a scraper if I want to read this as an epub on my kindle?
frumiousirc 3mo ago
"microsoft", okay, off to a great start. First click in the ToC that looks interesting and something I'd actually like to know as a RUST outsider: Common Python Pain Points That Rust Addresses But then number one: 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. Uh, okay. This rarely if ever has been a problem for me and I don't usually even use type hints. 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".
faangguyindia 3mo ago
My question is why will Python programmer, use Rust when they can use Go? As someone who went from C++ to java to Ruby to Javascript to Python, to Go. I find Go enviornment much superior. Not only your code can keep working for decade and compile fine with new compilers, you get more than enough speed you need. And also, you don't use random libraries, you precisely use to part you need which imho makes you software more reliable, cleaner and smaller. Using libraries and other people's module will always bite you just like llm bites you because you believe you understand it but you don't know how it's actually implemented and those who actually go through library and check all that, can implement parts they need from scratch without adding 100s of things u don't need.
- afdbcreid 3mo ago
  One possible reason: because Rust can interface with Python much more easily.

71 points by linhns 3mo ago

The whole "book" seems to be AI-generated, or at least very heavily AI-edited. Would at this point it not be easier to just tell developers to use their LLM of choice to achieve the same (or, likely, better) result? Random chapter so you can judge the quality for yourself: https://microsoft.github.io/RustTraining/python-book/ch09-error-handling.html 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-introduction-and-motivation.html#when-to-choose-rust-over-python 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 https://github.com/microsoft/RustTraining/issues/14

onlyrealcuzzo 3mo ago

I can't recommend Rust enough. It has such a bad reputation, but it isn't that hard. I truly think it's easier than many languages with much less-intimidating reputations. 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.

mightyham 3mo ago
Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. If it's an issue that you have to chain one extra collect call, just write a helper function for splitting that returns a vec.
- onlyrealcuzzo 3mo ago
  > Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. I think you're assuming the language won't warn you if you're doing something cost ineffective, and that there aren't modes to compilation which will make you make things explicit whenever its ambiguous. For a person to get started, they should be able to compile in `easy` mode and do things that make sense to them, and the compiler should only bitch at you to be pedantic when you ask for that. Especially because an LLM can probably do that pedantic part for you. You: write code almost as high level as a scripting language, it works, turn on strict mode, most of the time you get auto-fix solutions/options from the compiler. That's my opinion anyhow. I assume most Rust people won't like it. That's fine. You already have your language! I'm not trying to make a slightly different Rust for Rust people... I'm trying to make Rust more accessible to everyone else.
embedding-shape 3mo ago
> I never understood why Rust didn't / couldn't make functions able to return different outputs depending on context Referential transparency probably being the first reason I could see. Having the behaviour of a callee sounds horrible and something we usually try to actively work against, you want to be able to look at the function in isolation and be able to understand how it works and what values it gives back, without jumping around and seeing where it's being called. And yes, I'd agree with your last part, you do sound a bit like a psychopath ;) With that said, the world needs those too, so I hope your experiment is fun and brings you lots of learnings, enjoy! :)
sgeisenh 3mo ago
This closely resembles implicit conversion from C++ and in many serious codebases it is considered poor practice because it leads to a lot of hidden control flow. I think Rust strikes a nice balance but there’s enough magic that some people still get frustrated. Following traits can get tedious at times.

iloveoof 3mo ago

This tutorial is very bad, and the time estimates are pretty absurd. 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?

embedding-shape 3mo ago
> and the time estimates are pretty absurd. I wonder when LLMs will catch up with the new timelines, they frequently cite days/weeks of worth, then you say "Ok, implement that" and 30 minutes later everything been implemented. But seems they themselves is stuck not realizing they're not estimating for human timeframes anymore.
- tclancy 3mo ago
  I actually asked Claude about that this week and it was fairly interesting: the estimates are based on historical data, so I think that suggests in the current set up there will always be wild gaps. As best I could tell, the estimates you get are probably for the model one or two whole versions ago?
onlyrealcuzzo 3mo ago
Link to the Brown tutorial: https://rust-book.cs.brown.edu/ https://rust-book.cs.brown.edu/
pie_flavor 3mo ago
In my experience working with newbies, the alterations Brown makes to the chapters on borrowing are strictly worse. It is entirely focused on ramming the difference between the stack and the heap down your throat, which has nothing to do with ownership and borrowing, and newbies will frequently say that they are extremely confused by the chapter, then sigh in relief upon reading the original version. Just use the official guide, nobody has improved upon it yet. https://doc.rust-lang.org/book https://doc.rust-lang.org/book

Quothling 3mo ago

> Cargo vs pip/Poetry 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

nickpsecurity 3mo ago
People learning Python or searching for it will run into endless answers using PIP. Then, lots of advice on how to work around PIP's problems. Then, multiple alternatives they have to consider. I only recently started using UV after going through all that. Packaging, concurrency, and type errors had me strongly considering switching to Go or Rust recently. These are such long-solved problems in other languages that I question why we should put up with it in Python. Then, I remember it was the ecosytem, including job market and AI performance, that made me use Python. So, maybe a Python/Rust combo... There's the extensions the OP article mentioned and a Python interpreter written in Rust.
poulpy123 3mo ago
Because it's rust for python dev, not rust for python dev who use uv. I would understand your comment if you mentioned poetry, but pip has been the standard for years
kermatt 3mo ago
Because Astral is now owned by a profit driven org, and that often becomes problematic. Also because Pip ain't perfect, but it is stable in a sense.

muadddib 3mo ago

What pathetic garbage AI slop. I apologize to everyone who clicked and wasted their time.

dartharva 3mo ago

Jeez, what a hostile crowd. I personally am just glad companies like Microsoft, that infamously used to charge for every material they put out, have been providing free learning resources to newcomers like this, quality notwithstanding. 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.

paultopia 3mo ago

I feel like this is a lost cause, but why do people who publish these online free book-like-substances never make the files available as a single download? Do I really need to run a scraper if I want to read this as an epub on my kindle?

frumiousirc 3mo ago

"microsoft", okay, off to a great start. First click in the ToC that looks interesting and something I'd actually like to know as a RUST outsider: Common Python Pain Points That Rust Addresses But then number one: 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. Uh, okay. This rarely if ever has been a problem for me and I don't usually even use type hints. 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".

faangguyindia 3mo ago

My question is why will Python programmer, use Rust when they can use Go? As someone who went from C++ to java to Ruby to Javascript to Python, to Go. I find Go enviornment much superior. Not only your code can keep working for decade and compile fine with new compilers, you get more than enough speed you need. And also, you don't use random libraries, you precisely use to part you need which imho makes you software more reliable, cleaner and smaller. Using libraries and other people's module will always bite you just like llm bites you because you believe you understand it but you don't know how it's actually implemented and those who actually go through library and check all that, can implement parts they need from scratch without adding 100s of things u don't need.

afdbcreid 3mo ago
One possible reason: because Rust can interface with Python much more easily.