Hacker News Reader

Comment by nu11ptr | Hacker News Reader

This doesn't surprise me and matches my own experience. Rust literally makes a codebase nearly void of most bug classes with the exception of logic bugs (Unfortunately, in a huge codebase, there can still be tons and tons of logic bugs).

Still, when I migrated my Python codebase to Rust I got rid of whole classes of bugs and honestly code faster in Rust on a "per debugged line of code" basis. In Python, every line MUST be run or could trigger an exception (and so many do and it is hard to see). This now requires a test harness that tests every single line which is a huge pain. In Rust, the things that can obviously panic are pretty easy to see and are limited (unwrap, expect, indexing, etc.) making it much easier to write robust code, even with a more limited test suite.

View on HN

The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python. I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

I find Rust to have a particularly expressive type system, and a quite strict one to. Not all languages with type systems such have strict enforcement of mutability or null safety.

> I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

Rust has a very expressive type system[0], which you won't otherwise find before hitting the more functional and research-y side of things. Modelling data in terms of enums (sum types), move types (affine types), etc... makes it a lot more reliable and a lot less faillible as it just removes entire swathes of edge cases. See concepts like "making invalid states unrepresentable".

[0] though it's still lacking in many ways, the more you get the more you want after all

Other than Rust the only other "pragmatic" language I can think of that has as much of a robust type system is Typescript. As you say anything else you'd have a hard time convincing the rest of your team to use.

Typescripts type system is anything but robust. It's escape hatch build upon escape hatch. Don't get me wrong, it has to be like that due to it allowing gradual typing and essentially beeing a superset of js.

I now introduce you to Haskell. Welcome to the dark side.

To some extent, possibly, but it is a very rich type system, and does not have null which in and of itself gets rid of a set of errors. I also find Rust culture tends to be more guarded on panicking due to having such a rich error type (Result), so panic is reserved for the worst possible "can't continue" scenarios (unlike languages with unchecked exceptions). Also, enum pattern matching is exhaustive which gets rid of errors where you simply don't account for new variants. The list goes on and on.

> I can only assume that the bug classes you are referring to would have been eliminated by using essentially any language with a type system.

That's not entirely true. As an easy example, Go has a type system but it's relatively anaemic and recreates the "billion dollar mistake" of nil. I have personal experience with Go applications that have broken in production due to nil dereferences, to bugs related to type-switching off `interface{}`, and to the language's inability to enforce exhaustive case statements in general.

While the unique safety features in Rust are generally about memory safety, it still takes a much more safety-conscious approach in general than most languages that are statically typed.

Agreed, also consider C++ whose type system uses implicit conversions and mutability by default, leading to a number of non-memory related bugs.

> The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python

Rust gets safety with its ownership system. The ownership system brings strong guarantees around who is mutating / reading any given object.

Python has uncontrolled ownership. Any function can generally mutate / store any variable you pass in. This can definitely cause bugs if a rouge function starts modifying input.

Rust makes this impossible without the mutation “permission” being part of the method signature. Strong ownership controls force functions to be extremely explicit with their intentions

For those not familiar with ownership concepts, it does apply to many things beyond just memory management. Most obvious example of this is file handles. In python you have to close() them or scope within a context manager to auto close when the block exits. If you need more complex logic around, such as transfer the handle into another function, the context manager is no longer sufficient and you quickly loose track of who should call close(), is it the caller or the callee.

Rust keeps track of this, no matter how deep you twist your logic and it does so for every variable, no context manager blocks required.

wrong, rust is about exclusive ptr access, nothing more. you cannot do ReadOnly<T> in rust.

Why not? Isn't that &T like a read only wrapper of T?

try to do ReadOnly<T> yourself, and then put Cell into it, or RwLock, or Mutex, or Atomic, or crossbeam channel, ...

it LOOKS like it's possible but it can be broken easily. again, because rust is not really about (i)mutability, it's about mem-safety - and all of those can be safely mutated with &T

Rust has no exceptions and enforces correct propagation of errors at compile time. There are few if any strong typed languages in current use that offer a similar experience, for this mix of [memory safety + strong types + error correctness + close to machine performance] you would have to go to some very exotic language route.

Unlike those exotic options, Rust also comes out of the box with a very powerful free linter (clippy) which you definitely want to use, and has a wide community, library, cargo ecosystem, is very stable and tested etc.

When you total it up, you get a fast, safe program that exhibits 60-70% less runtime bugs than something written in either Python or C++ for a similar development effort. You still need to test of course, but you can focus on major integration and logic bugs instead.

While the big one for rust borrowing system is memory bugs it als make it extremely specific what can be mutated. And there can only be a single mutator at any time. Unless you explicitly write something to work for multiple mutators. This makes many logic bugs much more obvious even though you could still make them.

And of course you don't have nullability which is another big one.

Due to the pain that concurrency is in Python, the codebases I've seen mostly shared data only via external processes (queues, databases).

I was very surprised to read the article. I think in the code I have in mind the borrow checker would only add overhead.

The most frequent errors I see in the Python webapp code are: 1. logic errors, especially around concurrent DB transactions, 2. type errors (missing values, improperly modeled data), 3. performance problems.

It's not only threads. It's also explicit in whether a function can modify an argument because it's type signature says this with the mut keyword.

You're right. It just doesn't seem to create much issues in the application code I have experience with.

Well the article is about writing a database, which is definitely going to need concurrency and communication via shared memory to deliver the performance that it needs to (which is why the original implementation was mostly C++ and the new one is Rust). But yeah, I think in general if you're running into issues with mutability in Python, you're either using Python for something it should not be used for, or you're just programming in a really weird way.

I find exception handling in Python to be one of its weakest spots. I really like Python and I use it often. But I'm never quite sure which exceptions a library function might throw. This is rarely documented well and so you end up encountering new exceptions at run time, which is exactly when you do not want to be encountering new thrown exceptions.

Usually I end up looking at source of libraries and making a list of all exceptions that can be thrown. But of course this is also terribly error prone.

I think unchecked exceptions in Python probably make sense. I think the real issue is people trying to use Python to write large systems instead of scripts. I love python for 100-500 line scripts, but beyond that the ease of use features get in the way of writing robust code.

However, I think unchecked exceptions are a mistake in any language for writing _serious_ code. Interestingly, everyone hated checked exceptions in java so now everyone makes new exceptions unchecked. I would say this is not because people disliked the idea of ensuring errors were handled, but the verbosity required to do so meaningfully was annoying, so people took shortcuts to avoid pain by wrapping in unchecked exceptions and in the process introduced "exceptions gone wild" (and now everyone who runs a known java app is familiar with the exception stack trace in logs and in the console).

Python definitely considers itself a serious language, not one intended for 500 line scripts. They have libraries supporting server creation, GUI and desktop applications etc.

It's just that in practice, the trade-offs the designers made for easy development made writing large applications next to impossible, unchecked exceptions being one of the major sources of instability. You write very fast buggy code and get excellent productivity initially, but as the program grows you fave a factorial growth of interactions between components, and, because the interface points are not well defined and checked at compile time, what you gained during development is lost under an uncontrolled torrent of subtle runtime bugs.

That’s why Elixir developers like to make NIF callouts with Rust. It’s dangerous to do anything outside of the BEAM but Rust negates all of those concerns.

Maybe not all concerns, you're still allocating memory outside of BEAM and you still need to be careful to yield control on longer-running NIFs.

Is it possible to use Ada instead of Rust?

I believe you can made a NIF with just about anything.

I wonder if there are any examples though. Would be helpful. I suppose I could just make Ada bindings.

>with the exception of logic bugs

this is one big exception, because logical bugs are most common and most problematic.

If your main concern is security bugs, then according to Microsoft[0] about 70% of their bugs were memory-safety related.

[0]: https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

Most people don't write operating systems or write software in C/C++, so memory safety bugs are not big concern.

> ... or write software in C/C++

The article we've all supposedly read (but clearly some have not) is specifically talking about software written in a mix of C/C++ and Python.

I strongly disagree. The vast majority of bugs I see are unhandled None or exceptions and typos in dictionary keys and class attributes.

When I went from Java to Ruby on Rails it was an incredible breath of fresh air, and a massive, massive time saver, and truthfully Ruby can do many things Rails can not, and it worked well.

On a language level though (I still hate java) but the type safety was nice and did save you a lot of worry. In retrospect I realize most of the issue was the frameworks available and all the terrible configuration stuff.

I love that today you have so many more options because for a lot of time you do save time on a per line level..

> In retrospect I realize most of the issue was the frameworks available and all the terrible configuration stuff.

Also that Java’s type system is… not great.

So you have to put in a lot of effort (especially if it was before java 8, to say nothing of Java 5) and you just… don’t get much out of it.

Even more so given the syntactic overhead of defining java types before records (or without Lombok), to say nothing of the performance cost.

Reply on news.ycombinator.com