Hacker News Reader

Comment by kitkat_new | Hacker News Reader

My experience with Python recently:

I have been working on a mediumish project (without tests or type hints) where I needed to add functionality including a bit rewiring.

My main problems were:

- I didn't know what data (types) were passed around when looking at parts of the code, so I had to look were the data structures were created, adapted and passed along to actually know more (or just debug it)

- After changing parts of the code, I was 100% certain that I had to run it a dozen times to fix new bugs or things I had forgotten

How it works with Rust:

- I see the types in the function signature

- I know the properties of 'classes' without scanning the whole code of the class

- when it compiles, it works 90+% of the time, because the compiler tells me where I forgot something before, if the IDE hasn't already told me

View on HN

> I didn't know what data (types) were passed around when looking at parts of the code

For me this is the big one. Types isn't just about writing error-free code, it also aids in making the code self-documenting.

When I read a function signature in an unknown codebase in C, C++, C#, Delphi or similar, I can almost always tell what it does and what I can do (or not). Even types I haven't seen before helps, because the name of the types can be informative.

Thanks to this I've helped countless people fix their code using libraries I've never seen before in mere minutes, simply by glossing over some of the code.

When I work in untyped code, like older Python or similar, it's much harder. Invariably I end up sprinkling dir() or similar just to figure out what the heck is going on. Ok, this so function created... something... what can do with it? Who knows?

Python also has the regrettable property that many type errors aren’t even caught at runtime. Instead you often get incorrect results with no exception.

str vs bytes confusion is a major example. If you use one where you needed the other, the results can be anywhere from inscrutable failures to hilarious. My personal favorite is if you stick bytes into a templating engine. For some reason, iterating bytes in Python yields integers (not bytes-of-length-1 or a separate byte type), and those integers can get stringized and flattened, and your webpage turns into a bunch of digits and you end up with the Matrix.

> How it works with Rust ...

You will be amazed to find that that's how it works with C, Pascal, Java ...

Types being declared in function headers and checked is 1960's technology.

But Rust puts a unique amount of information into the types. This can get annoying sometimes, but it means typechecking better predicts correctness.

For example, a c header type might have an out parameter and an error code returned. The interaction between those two isn't specified in the type system.

I personally require discriminated unions (i.e. enums where each variant can hold its own type of data) before I consider a type system adequate.

But that's way beyond someone coming from JS or Python, just being excited that there are types on the parameters and the compiler tells you when basic things are wrong.

I personally came from JS to Java and got annoyed I had to do all this work specifying types but they gave me essentially no benefit.

Then I tried Rust and realized why types were good. (and then Kotlin)

it’s not just the type checker; its the borrow checker, which prevents way more bugs than in C++ and is certainly not 1960s tech

certainly not with C:

Manually managing memory has turned out to be error prone (for me) and can result in quite nasty to debug bugs (because the type system is lacking), only to mention the most important thing.

I think there is enough out there on C vs Rust, esp. because of the Linux kernel

That said, it was asked about Python (within the context of Rust), and I have limited experience with Pascal and Java, so I will leave it at that.

except the type system in C isn't that good.

That’s an understatement. If you see a function in a header like:

    char *func(char *in, size_t len);

It’s anybody’s guess what the actual input type is, not to mention the ownership or lifetime of the output.

HN now supports backslash escapes for asterisks (which, unescaped, are markup notation for italics).

> I didn't know what data (types) were passed around when looking at parts of the code, so I had to look were the data structures were created, adapted and passed along to actually know more (or just debug it)

It's even better when all those data structures are just dicts, because it's too cumbersome to make serializable classes, so good luck figuring out what fields are in which.

Reply on news.ycombinator.com