Unexpected productivity boost of Rust

I encourage every one to at least stop writing code in Python.

The benefits realized can be mostly attributed to strong type checking.

I'm a rust dev full time. And I agree with everything here. But I also want people to realize it's not "Just Rust" that does this.

In case anyone gets FOMO.

Here is some actual useful advice:

Use a type checker! Pyright can get you like 80% of Rust's type safety.

I don't agree that Python can be saved by a type checker. The language itself is flawed irreversibly, as well as its ecosystem. It's a big big mess. Can't build reliable software in Python.

What are the major pros and cons of Pyright and Mypy relative to one another?

People who recommend that other people stop using one of the best documented languages on the planet with a huge library ecosystem, a friendly user base, a clean syntax, excellent reference documentation, intuitive function names, readable tracebacks, superb editor and AI support.

Do you know a language other than Rust that has alternative for docs.rs? In JavaScript and Python they never bother to have any documentation or reference, one notable example that gets me frustrated these days is the openai SDK for TypeScript. There is no documentation for it. I have to go look at the source code to figure out what the hell goes on.

you can and this is a juvenile position. there is reliable software in any language as popular and widespread as Python. every language is flawed

Sorry, it's not even close to Rust. Or even C# or Java. It can't provide the same "fearless refactoring". It is better than being blind/having to infer everything manually. That's not saying much.

And that's assuming the codebase and all dependencies have correct type annotations.

Is this rage-bait? A language alone doesn't dictate reliability. There are tons of large scale systems out there running on Python. As for the language being, "flawed irreversibly", I'd be curious to hear you expand on that with examples.

These days isn't the solution to this just "ask <insert LLM of choice here>" to read the code and write the documentation"?

It can't be 100% saved, but like the OP said it's 80% saved.

It's not true you can't build reliable software in python. People have. There's proof of it everywhere. Tons of examples of reliable software written in python which is not the safest language.

I think the real thing here is more of a skill issue. You don't know how to build reliable software in a language that doesn't have full type coverage. That's just your lack of ability.

I'm not trying to be insulting here. Just stating the logic:

   A. You claim python can't build reliable software.
   B. Reliable Software for python actually exists, therefore your claim is incorrect
   C. You therefore must not have experience with building any software with python and must have your hand held and be baby-sitted by rusts type checker.

Just spitting facts.

I've not tried Pyright, but mypy on any realistic, real-world codebase I've thrown at it emits ~80k errors. It's hard to get started with that.

mypy's output is, AFAICT, also non-deterministic, and doesn't support a programmatic format that I know of. This makes it next to impossible to write a wrapper script to diff the errors to, for example, show only errors introduced by the change one is making.

Relying on my devs to manually trawl through 80k lines of errors for ones they might be adding in is a lost cause.

Our codebase also uses SQLAlchemy extensively, which does not play well with typecheckers. (There is an extension to aid in this, but it regrettably SIGSEGVs.)

Also this took me forever to understand:

  from typing import Dict

  JsonValue = str | Dict[str, "JsonValue"]

  def foo() -> JsonValue:
      x: Dict[str, str] = {"a": "b"}
      return x

  x: JsonValue = foo()

That will get you:

  example.py:7: error: Incompatible return value type (got "dict[str, str]", expected "str | dict[str, JsonValue]")  [return-value]

> There is an extension to aid in this, but it regrettably SIGSEGVs.

Love this.

Yes, you can have Claude Code go through the code and make an .md file with documentation for all the public APIs. I do that for everything that doesn't provide llms.txt.

I don't use mypy so I can't comment on it but at least from what I have seen pyright is deterministic in it's output and get output json.

Regarding the ~80k errors. Yeah, nothing to do here besides slowly grinding away and adding type annotations and fixes until it's resolved.

For the code example pyright gives some hint towards variance but yes it can be confusing.

https://pyright-play.net/?pyrightVersion=1.1.403&code=GYJw9g...

If you know some secret behind building reliable software in a programming language without types, with nulls, and with runtime exceptions, I'm all ears. I admit that a blanket statement "can't build reliable software" is going overboard, but the intention was to be dramatic, not factually correct. You can probably build reliable software in Python if you write everything from scratch, but I wouldn't want to do that to myself. I would rather use a programming language that has a type system, etc, and a better cultured ecosystem.

Pythons power is in the REPL. It's good for when you want to do something ad-hoc that's too much for Bash or a graphing calculator. It has a large enough ecosystem that you can make a PoC for basically anything in a day.

It's really, really good for <1000 LoC day projects that you won't be maintaining. (And, if you're writing entirely in the REPL, you probably won't even be saving the code in the first place.)

javadoc.io is similar to (but not as good as) docs.rs for the Java ecosystem. It pulls the JavaDoc out of packages that are published to the Maven Central repository. It doesn't have good discoverability like docs.rs, though, and it's dependent on the publishers actually including the javadoc files.

All programming languages are Turing complete and you can arque with that. But you reach similar results with varying pre-knowledge and effort. Sometimes it is even impossible. All programs can be bug-free but most are not, if we reverse the argument.

> 80% of Rust's type safety.

Sort of like closing 80% of a submarine's hatches and then diving.

the problem is that when you write enough <1kloc projects, a couple of them are useful enough to stay used in which case you are now maintaining python in prod.

javadoc.io is similar in the fact that it lists things I guess? It looks worse (objective) but is also depended on a lot less so is just by default going to be a second thought. It’s also not auto-generated like docs.rs like you said.

what language are you referring to here?

Yes but the alternative is "not having those projects at all" not "having them in a 'better' language"

I used mypy just fine for a previous job. If you are getting 80k errors, that means you are either starting very late to use the type checker and have done many dubious things before, or you didn't exclude your venv from being type checked by mypy.

I prefer types too.

But I can build reliable software without types as well. Many people can. This isn’t secret stuff that only I can do. There are thousands and thousands of reliable software built on Python, ruby and JavaScript.

Everyone stubs their toe on container invariance once, then figures it out and moves on. It's not unique to Python and developers should understand the nuances of variance.

If you want to not reliably know anything about the code, sure. But if you want to have useful knowledge, using a stochastically unreliable tool isn't going to cut it.

Of course not, the alternate is writing these projects in a more maintainable language

I don't think that's inevitable, you can just not do that. I've been doing this for 15 years and it hasn't happened to me.

Python.

https://www.tiobe.com/tiobe-index/

https://pypl.github.io/PYPL.html

https://www.statista.com/statistics/793628/worldwide-develop...

https://redmonk.com/sogrady/2024/03/08/language-rankings-1-2...

Intuitive function names like __new__() and __init__()? Or id() and pickle.dumps()?

The accessibility of Python is overrated. It's a language with warts and issues just like the others. Also the lack of static typing is a real hindrance (yes I know about mypy).

Exactly! I code in Python every day, I haven't done so without a type checker (usually mypy) for years, I don't push a single change without type-checking it first, it catches stupid mistakes and saves me from breaking production all the time.

Dunders keep them out of the public namespace on purpose.

I recommend first starting with pyflakes and later ruff on a huge old Python project. Do file by file.

When done, do typing similarly.

lol, Instagram is written in Python.

Indeed, I write very reliable Python every day. A lot faster than the Rust straitjacket too.

We had sentry installed so I know exactly how many exceptions were happening, rare to zero. Lots of tests/constraints on the database as well.

That said I like a nice tight straitjacket at other times. Just not every day. ;-).

P.S. Python doesn’t have the billion-dollar-mistake with nulls. You have to purposely set a variable to None.

Very few bugs are life-threatening.

Or writing them in whatever language gets you going quickly and rewrite the "successful" ones in a more safe language like Rust. Of course write test cases for those ones first and then use LLM help to migrate them, including tests, to a safer language. Problem happens when the velocity of changes is too much and/or there is no appetite for migration - those are a different category of problem.

The ideal scenario is what you are saying but most of the time it boils down to deadline vs familiarity/skill (of the developer and the team) trade-off.

It doesn't solve all the problems at library boundaries, but pyright is fairly new and vastly vastly better than mypy.

With it Python feels about at the type safety level of Typescript - not as good as a language that had types the whole time, but much much better than nothing if enforced with strict rules in CI.

But they decrease productivity. And I seriously think many teams don’t track the time sunk for fixing bugs / defects properly and they overestimate their productivity, especially the initial productivity boost from not having to think about types.

OP was needlessly combative. But, if I have to write a program that is correct (i.e. does what I want it do to), I'm going to write it in Rust. Not because you cannot write correct programs in Python. But because it's easier to prove it's correct in Rust.

As a solo dev, I find that I start off in Python, but at a certain project size I find it too unwieldy to manage (i.e. make changes without breaking things) and that's when I implement part or all of the project in Rust.

> In JavaScript and Python they never bother to have any documentation or reference

Please, main Python libraries have much richer docs than almost anything from Rust ecosystem.

Yeah, I would never know it is impossible to write anything larger than 1k LOC in Python if I would not visit HN.

On the other hand, TS is terrible. The type system is ridiculously complex in order to support all the weird stuff you can do in JS, I frequently get insane error messages with 20+ lines of archaic type gibberish and when I figure out the solution it's usually very clear that the sparse information i managed to glean from reading the error message was nothing but a distraction.

I don't like JS but after having used TS intermittently for a number of years I'm starting to think JS is the better option. At least there I don't get tricked by typed objects being something other than what they claim to be, or waste time trying to declare the right types for some code that would work perfectly without TS.

TS is too much work for too little reward. I'd rather just make simple frontends with as little logic as possible and do the real programming in a real programming language on the backend.

I feel like this is exaggerated. If you spent a couple days building a POC in python and found that it was useful then you can spend a couple days re-building it in a better language. You already know what you're making, probably have a decent plan for how to implement it, should be simple and straight forward to replicate it.

What language do you recommend instead for the type of small tasks I write python to solve? Needs to have a good image manipulation library, tools for manipulating binary data and converting it to normal types, good list comprehension tools, the ability to easily be a web client or server and a good REPL

> one of the best documented languages

Are we talking about the same Python? Have you seen the Python documentation? There's a reason it ranks so badly on Google.

Also you forgot the abysmal performance and laughably janky tooling (until uv saved us from that clusterfuck anyway).

Mypy is shit, but Pyright is actually very good so you can write Python with a pretty good static type experience. Almost on par with Typescript.

The problem is you will spend your whole life unsuccessfully trying to get your lazy colleagues to actually use them.

It's not exaggerated. You can spend a couple of days rebuilding it in a better language (and I have done that!), but what actually happens is people want new features far more than they want you to rebuild it in a better language. So in most cases it gradually grows and gradually gets more unmanageable and it gradually becomes more difficult to justify a rewrite. There's never a solid point where you have to do a rewrite so it grows and grows until you really really wish that you had but it's also way way too late.

Happens all the time in my experience. It goes so far that big companies like Facebook, Google and Dropbox have all ended up writing their own Python/PHP runtimes or even entirely new languages like Hack and Google's new C++ thing rather than rewrite, because rewrites become impossible very quickly.

That's why - despite people saying language doesn't matter - it is very important to pick the right language from the start (if you can).

I would say it's more like 50%. Rust benefits not just from static typing but also a much stronger type system with things like enums, pattern matching, marker traits, ownership, mutability, etc. You don't get any of that with Pyright.

(But if you must use Python then definitely use Pyright.)

That's fair. I wasn't really defending the idea of using python for prototyping. Personally I'd just start with C# for pretty much any project and try to do it right from the beginning.

I suppose most of my point was that in the case described one should jump to the rewrite sooner rather than later, to avoid the situation you describe.

Bun

isnt that just javascript?

> Intuitive function names like __new__() and __init__()? Or id() and pickle.dumps()?

I use python for some basic scripting and I don't write anything huge. Most of these do roughly what I would expect.

> __new__ is a static method that’s responsible for creating and returning a new instance (object) of the class. It takes the class as its first argument followed by additional arguments.

> In Python, __init__ is an instance method that initializes a newly created instance (object). It takes the object as its first argument followed by additional arguments

> Python id() function returns the “identity” of the object. The identity of an object is an integer, which is guaranteed to be unique and constant for this object during its lifetime.

The pickel.dumps() is the only one that is a bit odd until to find out what the pickle module does.

> The accessibility of Python is overrated.

The accessibility isn't overrated. Python has something that is missing from a lot of languages that isn't often talked about. It is really good a RAD (Rapid Application Development). You can quickly put something together that works reasonably well, it also is enough of the proper language that you can build bigger things in it.

> It's a language with warts and issues just like the others.

Like every other one.

If you're willing to put a bunch of up-front effort into learning it first, Haskell. If not, OCaml.

It's JavaScript (TypeScript) that ships as a single executable with lots of stuff in it like bundler, compiler, postgres client, etc. I use it for scripting, e.g., seed database, etc.

> A language alone doesn't dictate reliability.

Nobody would claim that. But are you trying to say that the language has no effect on reliability? Because that's obviously nonsense.

Language choice has some effect on reliability, and I would say Python's effect is mediocre-to-bad. Depending on if you use Pyright. Not too bad if you do. Pretty awful if you don't.

> every language is flawed

But not equally flawed.

https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...

The problem with an unsound type system like TypeScript's is that once a value of an unexpected type has snuck through a soundness hole, it can end up anywhere in the program, even in code that seems fully safe.

(Also, it means that you don't get any performance benefit from static typing your program.)

> have to write a program that is correct

Yes, exactly. It doesn’t happen that often, but it does.

And folks have forgotten, not sure why, but Python was always billed as a prototyping language in the “olden tymes.” Or even “executable pseudocode.” At those it excels.

What exactly? I work at Instagram.

The difference between new and init is not knowable from reading their names. The same is true of pickle. By definition, that makes them unintuitive.

A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.

>The difference between new and init is not knowable from reading their names. The same is true of pickle. By definition, that makes them unintuitive.

By that standard nothing is. At some point if you are using a programming language you are going to have to RTFM. None of things you cherry-picked would be used by a novice either.

Every example you gave are what I call are "Ronsil" (https://en.wikipedia.org/wiki/Does_exactly_what_it_says_on_t...).

Even the pickle.dumps() example is obvious when you read the description for the module and works exactly the same to json.dumps(), which works similarly to dumps() methods and terminology in other programming languages.

I feel like I am repeating myself.

> A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.

Nonsense. None of those I would say are RAD. JavaScript literally has no standard lib and requires node/npm these days and that can be a complete rigmarole in itself. C# these relies heavily on DI. I have no idea about Clojure so won't comment.

All the RAD stuff in C# and JS is heavily reliant on third party scripts and templates, that have all sorts of annoying quirks and bloat your codebase. That isn't the case with Python at all

> By that standard nothing is.

Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.

> Even the pickle.dumps() example is obvious

Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.

The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.

> Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.

I believe that people should RTFM. Any arguments that is predicated on not reading the documentation for the language, and then pretending that it is somehow opaque, I am going to dismiss to be quite honest.

> Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.

You are still cherry-picking things to attempt to prove a point. I don't find this convincing.

> The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.

I didn't say that you can't do RAD with libraries. You didn't understand what I was saying at all.

I can get up and running with Python in mere minutes. It doesn't require a application templates/scaffolding apps to get started (like C# and JS/TS). You just need a text editor and a terminal. Doing that is still quicker and easier to get something working than all the gumpf you have to do with the other languages. I BTW was a JS/TS and .NET for about 15 years

I just wish there were more Python and Go jobs in the UK.

C# does not require scaffolding any more than Python does. It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too. How much setup you need really depends on what you are trying to do; if you are using Django, there will be an insignificant amount of that, and some of the most complicated setups I've seen have been with Pylons/Pyramid. If you're just making a CLI app, well I don't see how it's any less setup with Python than with Node. And anyway, RAD isn't about setup time, it's about iteration time.

I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...

I don’t work at Instagram so I can only go off of what I found online: https://www.pythonpool.com/how-instagram-is-using-django-and...

https://python.plainenglish.io/how-instagram-uses-python-sca...

R.E. scaffolding in C#, with upcoming .NET 10, it's really simple: - Write code to myfile.cs - `dotnet run myfile.cs`

That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.

And since we're talking about RAD, Python can't even compare to Clojure. Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.

[1]: https://github.com/babashka/scittle

> C# does not require scaffolding any more than Python does.

They've changed so much in the last few years I honestly don't know anymore. Which is part of the entire problem.

The last time I bothered writing anything with C# / .NET was .NET 8. They definitely had scaffolding tools for popular project types. Setting stuff up from a blank project wasn't straight forward.

> It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too.

I find dealing with C++ and CMake/Make (I hobby program Vulkan/OpenGL) easier than dealing with Node JS and NPM. People think I am being hyperbolic when I say this, I am not. Which show you how insane the JS ecosystem is.

I am honestly fed up of both C# and JS. There are far more headaches with both (especially if you are using TypeScript).

If you use TypeScript and don't want to use babel, until recently you have to basically use tsx or tsnode . You then have to wrangle a magic set of options in the tsconfig.json to have some popular libraries work.

.NET after 5 has absolute DI madness in ASP.NET and none of it seems documented properly anywhere (or I can't find it) and it seems to change subtly every time they update .NET or ASP.NET.

I ended up resorting to pulling down the entire source code to see what the Startup was doing. C# now has total language and syntactic sugar overload.

I have almost none of these headaches with Python and Go.

> And anyway, RAD isn't about setup time, it's about iteration time.

It is both. I find Python quicker, easier and less headaches that either JS or .NET. I am well versed in C# and JS.

I know less Python than .NET and JS/TS, yet I find it easier.

> I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...

That is true. I am sure most Go jobs advertised in the UK are in London.

> R.E. scaffolding in C#, with upcoming .NET 10, it's really simple: - Write code to myfile.cs - `dotnet run myfile.cs` > That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.

I've just had a quick look at some of this and they've basically just moved stuff in to the cs file from the proj file. I remember them saying this was on the roadmap when I was doing a .NET 8 refresher.

   // app.cs
   #:package Humanizer@2.*

   using Humanizer;

It also seems anything non-trivial will still require proj files. Which means that they are likely to still have project templates etc.

> And since we're talking about RAD, Python can't even compare to Clojure.

I am unlikely to ever use Clojure, I certainly won't be able to use it at work.

> Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.

All sounds very complicated and is the sort of thing I am trying to get away from. I find all of this stuff more of a hinderance than anything else.

To be fair, you do get enums and pattern matching from base language.