Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction – Rust for Python Programmers

microsoft.github.io

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Introduction – Rust for Python Programmers

#11

Post by sgeisenh »

onlyrealcuzzo wrote: post #3

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 = "a,b,c".split(',').collect(); // Vec ``` I never understood why Rust didn't / couldn't make functions able to retur…

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.

Re: Introduction – Rust for Python Programmers

#12

Post by pie_flavor »

iloveoof wrote: post #5

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?

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

Re: Introduction – Rust for Python Programmers

#13

Post by pie_flavor »

onlyrealcuzzo wrote: post #3

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 = "a,b,c".split(',').collect(); // Vec ``` I never understood why Rust didn't / couldn't make functions able to retur…

You may notice no language on the planet does this. That is because it is bad. Type guesstimation is a great way of ensuring random problems crop up in random places where they aren't expected and of making the typechecker much slower and more prone to unresolvability (see Swift's multi-minute compiles). All to save you from having to learn what an iterator is, in case you come from a language where lists are more common than iterators; the experience of being scared by a type, and then discovering that the type is not scary in chapter 13.2, is not actually worth making the simple type system instead staggeringly complicated.

Re: Introduction – Rust for Python Programmers

#15

Post by onlyrealcuzzo »

pie_flavor wrote: post #13
onlyrealcuzzo wrote: post #3

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 = "a,b,c".split(',').collect(); // Vec ``` I never understood why Rust didn't / couldn't make functions able to retur…

You may notice no language on the planet does this. That is because it is bad. Type guesstimation is a great way of ensuring random problems crop up in random places where they aren't expected and of making the typechecker much slower and more prone to unresolvability (see Swift's multi-minute compiles). All to save you from having to learn what an iterator is, in case you come from a language where lists are more co…

> You may notice no language on the planet does this. That is because it is bad.

Perhaps I've explained this poorly, but C#, Java, Perl, & Haskell (and I'm sure others as well) do versions of this already...

You even seem to imply that Swift does, though I have almost no experience directly with Swift.

The vast majority of times it is NOT ambiguous. The compiler can flag it, IFF you want it to.

If you're coming from Python and you want to ease your learning experience, you probably don't want to hit several brick walls before you can do anything...

If you have an enterprise codebase, you probably don't want to allow anything to be compiled that could be ambiguous, so you can force that mode of compilation (and likely should)...

I don't know of any major language which have progressive modes of compilation like this. I think people will find it useful.

Maybe it'll be a disaster. Time will tell. The whole point is to intelligent design the modes such that you can't ever get a MASSIVE surprise "upgrading" from one mode to the next, any error that is too hard to resolve basically automatically / through selecting options needs to be dealt with at the easiest mode.

Re: Introduction – Rust for Python Programmers

#16

Post by nickpsecurity »

Quothling wrote: post #10

> 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

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.

Re: Introduction – Rust for Python Programmers

#17

Post by onlyrealcuzzo »

sgeisenh wrote: post #11
onlyrealcuzzo wrote: post #3

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 = "a,b,c".split(',').collect(); // Vec ``` I never understood why Rust didn't / couldn't make functions able to retur…

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.

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

Yes, which is why there's progressive modes of compilation to not allow anything ambiguous if that's what you want (i.e. an enterprise codebase).

But, a junior can still try things out in weaker modes of compilation, and then once they've got something working, it is typically very easy to do the pedantry to remove ambiguous behavior.

Re: Introduction – Rust for Python Programmers

#18

Post by pie_flavor »

onlyrealcuzzo wrote: post #15
pie_flavor wrote: post #13

Earlier quoted context omitted.

You may notice no language on the planet does this. That is because it is bad. Type guesstimation is a great way of ensuring random problems crop up in random places where they aren't expected and of making the typechecker much slower and more prone to unresolvability (see Swift's multi-minute compiles). All to save you from having to learn what an iterator is, in case you come from a language where lists are more co…

> You may notice no language on the planet does this. That is because it is bad. Perhaps I've explained this poorly, but C#, Java, Perl, & Haskell (and I'm sure others as well) do versions of this already... You even seem to imply that Swift does, though I have almost no experience directly with Swift. The vast majority of times it is NOT ambiguous. The compiler can flag it, IFF you want it to. If you're coming from…

In none of the languages you mentioned do stdlib functions either return an iterator or a list depending on whether you feed it into an iterator operation; in none of the languages you mentioned can a fully-generic return as a method receiver be inferred by the name of the method. It has nothing to do with how well you explained it; it just doesn't exist. Every single thing you are complaining about exists in all of the languages you brought up, although Perl does a small portion of that in some cases depending on the variable sigil (ie still not guessed).

Your post is a restricted special case of "it would be great if any old sequence of characters compiled correctly and the compiler just read my mind". Wouldn't it just, but the rules of programming languages exist for more purposes than just annoying the user.

Re: Introduction – Rust for Python Programmers

#19

Post by tclancy »

embedding-shape wrote: post #6
iloveoof wrote: post #5

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?

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

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?

Re: Introduction – Rust for Python Programmers

#20

Post by poulpy123 »

Quothling wrote: post #10

> 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

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
Post reply on HN