Introduction – Rust for Python Programmers

Certainly if you allow a language do something like:

```rust

fn foo() -> i32 { 42 }

fn foo() -> String { "42" }

```

That would be a nightmare.

But you can have something like:

```rust-ish

@eager_fallback(String[])

fn split(s: String, separator: Char) -> String::Iterator { ... }

```

Which, essentially, defaults to calling collect to an Array for you when bound to a variable, or when chained to a function that doesn't take an iterator but does take a String Array. And in a different mode of compilation, there are no fallbacks (you're back to Rust).

Sure, I don't know a language that supports polymorphic return exactly on `.split()`, but there are languages that support all of the different mechanisms to do this intelligently.

You're assuming the implementation is going to do a number of things that would cause either code bloat or force ambiguity (and potentially a number of other assumptions).

I think you're also assuming the type is not resolved until who knows what happens to it, rather than once it's bound.

None of those HAVE to be true.

To the best of my knowledge, for the most common cases, this can be solved, and when it can't, the compiler can flag it.

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.

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

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.