6 ms·

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 (Unfort

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.

brightball 4y ago
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.
- johnisgood 4y ago
  Is it possible to use Ada instead of Rust?
  - brightball 4y ago
    I believe you can made a NIF with just about anything.
    - johnisgood 4y ago
      I wonder if there are any examples though. Would be helpful. I suppose I could just make Ada bindings.
- Xorlev 4y ago
  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.
wooque 4y ago
>with the exception of logic bugs this is one big exception, because logical bugs are most common and most problematic.
- wazzaps 4y ago
  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-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
  - wooque 4y ago
    Most people don't write operating systems or write software in C/C++, so memory safety bugs are not big concern.
    - kelnos 4y ago
      > ... 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.
- jon_richards 4y ago
  I strongly disagree. The vast majority of bugs I see are unhandled None or exceptions and typos in dictionary keys and class attributes.
s17n 4y ago
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.
- charrondev 4y ago
  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.
- masklinn 4y ago
  > 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
  - p1necone 4y ago
    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.
    - rowanG077 4y ago
      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.
    - toomanydoubts 4y ago
AndyMcConachie 4y ago
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.
- nu11ptr 4y ago
  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).
  - manholio 4y ago
    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.
DoesntMatter22 4y ago
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..
- masklinn 4y ago
  > 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.

brightball 4y ago

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.

johnisgood 4y ago
Is it possible to use Ada instead of Rust?
- brightball 4y ago
  I believe you can made a NIF with just about anything.
  - johnisgood 4y ago
    I wonder if there are any examples though. Would be helpful. I suppose I could just make Ada bindings.
Xorlev 4y ago
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.

wooque 4y ago

>with the exception of logic bugs this is one big exception, because logical bugs are most common and most problematic.

wazzaps 4y ago
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-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
- wooque 4y ago
  Most people don't write operating systems or write software in C/C++, so memory safety bugs are not big concern.
  - kelnos 4y ago
    > ... 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.
jon_richards 4y ago
I strongly disagree. The vast majority of bugs I see are unhandled None or exceptions and typos in dictionary keys and class attributes.

s17n 4y ago

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.

charrondev 4y ago
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.
masklinn 4y ago
> 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
- p1necone 4y ago
  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.
  - rowanG077 4y ago
    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.
  - toomanydoubts 4y ago

AndyMcConachie 4y ago

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.

nu11ptr 4y ago
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).
- manholio 4y ago
  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.

DoesntMatter22 4y ago

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

masklinn 4y ago
> 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.