6 ms·

I don’t know what projects you are doing where rust vs python are the options.

theptip 4y ago
I think a lot of people would like to use rust for web dev, but IMO it’s not quite there for ORM-backed apps. (Diesel is nowhere near the ergonomicity of Django for example.)
- mr_00ff00 4y ago
  I’ve said it before and I’ll say it again, although I think it’s an unpopular opinion: Rust introduces unsafe code (at a minimum through crates). The rust community hates that people use C++ when they could use a memory safe language, so why are they introducing memory unsafe to something that a GC works fine? It’s like their opinion of memory safety as a necessity totally flips the second rust is the unsafe one.
  - ameliaquining 4y ago
    All languages have memory unsafety somewhere in the stack.
    - mr_00ff00 4y ago
      This just makes no sense to me, then why try to replace C++? After all, all languages are memory unsafe. Rust let’s you write unsafe code, that’s so different than say python.
      - rom-antics 4y ago
        Python lets you write unsafe code. https://wiki.python.org/moin/CrashingPython https://wiki.python.org/moin/CrashingPython Does that mean it's no safer than C++?
        mr_00ff00 4y ago
        What? Those aren’t memory exploitable bugs. And no I am not, you are saying that. I think python is way safer than either, you seem to think because you can crash a python program that means the memory vulnerabilities of rust are justified.
        rom-antics 4y ago
        Crashes are just security holes that nobody has crafted an exploit for yet.
        mr_00ff00 4y ago
        GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. And you didn’t address my second point.
        rom-antics 4y ago
        > GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. All of the work Python does at runtime with a GC, Rust does at compile time with the borrow checker. GC is orthogonal to the idea of memory safety. > And you didn’t address my second point. I don't know what you expect. It's a semantically empty statement and thus unfalsifiable. You can flip it around without changing the truth or the meaning: > you seem to think because you can crash a Rust program that means the memory vulnerabilities of Python are justified.
        ameliaquining 4y ago
        It's not just crashes. Python's ctypes API can do anything that unsafe Rust can do, including the parts that permit arbitrary code execution vulnerabilities.
      - ameliaquining 4y ago
        C++ is pervasively memory-unsafe; a bug in any part of a C++ codebase can easily cause undefined behavior, such that you can't isolate the memory-unsafe parts and apply extra assurance techniques to them. Most modern garbage-collected languages do let you do this, as does Rust.
  - rom-antics 4y ago
    Every language has unsafe bits if you look deep enough. CPython and Java's garbage collector are written in C, and we have ctypes and JNI, but I think most people would still consider those memory safe languages. The important question is: is there a well-defined safety boundary, somewhere between the CPU and your application code, where memory is guaranteed* not to be corrupted and the programmer is freed from worrying about low-level bugs like segfaults? *assuming no outside bugs such as CPU bugs, bugs in the GC, or bugs in an unsafe block
    - mr_00ff00 4y ago
      This doesn’t make sense. So rust let’s you write unsafe code, and now that’s the same as any language that calls C in any way? Why replace C++ then? After all, rust is just as unsafe by your definition. Having a language that is default safe and can only be unsafe in rare situations is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary.
      - rom-antics 4y ago
        > Having a language that is default safe and can only be unsafe in rare situations This describes both Python and Rust. They are default safe, with escape hatches (ctypes or unsafe blocks) for rare situations. Writing unsafe code in Rust should be as rare as using ctypes in Python. > is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary. Python lets libs use ctypes to poke at raw memory. Solution: avoid those libraries Rust lets libs use unsafe blocks. Solution: avoid those libraries (and optionally use tools like cargo-geiger or forbid(unsafe) if you care enough
        mr_00ff00 4y ago
        If you don’t seem a parallel between what you just said: “just use these tools to catch the unsafe parts of rust” and the C++ crowd saying “just use these tools or do these things to catch the unsafe parts of cpp” there’s no point in continuing this discussion. Python ctypes are not at all as common as rust unsafe code and geiger only goes so deep in search for unsafe code if I remember correctly.
  - burntsushi 4y ago
    Isn't it obvious? The position is not against the use of code that might cause UB, it's against making that the default everywhere. In Rust, unsafe is opt in and can be encapsulated. That's the key bit.
- tayo42 4y ago
  Yeah with things like are we web yet, rust presents it self as can do anything language. Which sure technically it can, but atm I think it's a only appropriate when you have an army of developers at some money printing company that go and write all your dependencies To answer the above question, like cli tools
spenczar5 4y ago
I have one: scientific software. There's a growing recognition that Python is creaking under the weight of scientific applications that lean on it. It's very difficult to write efficient, maintainable, large-scale software systems with it. An example that comes to mind is data reduction pipelines for the bytes coming out of a major telescope, like that of LSST. I worked on those pipelines, and a lot of the effort was around figuring out how to consistently build the dang thing given the looseness of Python's systems. An equally large amount of the effort was on trying to eke out the performance of Python via Numpy tricks, Numba, etc, which impinged readability and maintainability. In some places, we fall back on a C++ core, but nobody is happy about that, for all the usual reasons. Some of us advocated for Rust... but it was never really plausible, because the interactions with Python numerical and scientific libraries are so immature. People are starting to work on it but it's hard to compete with the decades of work put into C++ and Python as the core of scientific stacks.
- throw_away1525 4y ago
  Julia seems to be a great potential replacement for Python for scientific software.
  - spenczar5 4y ago
    I totally agree, and it has identical issues. The momentum behind Python and C++ is enormous, so catching up is hard.

I think a lot of people would like to use rust for web dev, but IMO it’s not quite there for ORM-backed apps. (Diesel is nowhere near the ergonomicity of Django for example.)

mr_00ff00 4y ago
I’ve said it before and I’ll say it again, although I think it’s an unpopular opinion: Rust introduces unsafe code (at a minimum through crates). The rust community hates that people use C++ when they could use a memory safe language, so why are they introducing memory unsafe to something that a GC works fine? It’s like their opinion of memory safety as a necessity totally flips the second rust is the unsafe one.
- ameliaquining 4y ago
  All languages have memory unsafety somewhere in the stack.
  - mr_00ff00 4y ago
    This just makes no sense to me, then why try to replace C++? After all, all languages are memory unsafe. Rust let’s you write unsafe code, that’s so different than say python.
    - rom-antics 4y ago
      Python lets you write unsafe code. https://wiki.python.org/moin/CrashingPython https://wiki.python.org/moin/CrashingPython Does that mean it's no safer than C++?
      - mr_00ff00 4y ago
        What? Those aren’t memory exploitable bugs. And no I am not, you are saying that. I think python is way safer than either, you seem to think because you can crash a python program that means the memory vulnerabilities of rust are justified.
        rom-antics 4y ago
        Crashes are just security holes that nobody has crafted an exploit for yet.
        mr_00ff00 4y ago
        GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. And you didn’t address my second point.
        rom-antics 4y ago
        > GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. All of the work Python does at runtime with a GC, Rust does at compile time with the borrow checker. GC is orthogonal to the idea of memory safety. > And you didn’t address my second point. I don't know what you expect. It's a semantically empty statement and thus unfalsifiable. You can flip it around without changing the truth or the meaning: > you seem to think because you can crash a Rust program that means the memory vulnerabilities of Python are justified.
        ameliaquining 4y ago
        It's not just crashes. Python's ctypes API can do anything that unsafe Rust can do, including the parts that permit arbitrary code execution vulnerabilities.
    - ameliaquining 4y ago
      C++ is pervasively memory-unsafe; a bug in any part of a C++ codebase can easily cause undefined behavior, such that you can't isolate the memory-unsafe parts and apply extra assurance techniques to them. Most modern garbage-collected languages do let you do this, as does Rust.
- rom-antics 4y ago
  Every language has unsafe bits if you look deep enough. CPython and Java's garbage collector are written in C, and we have ctypes and JNI, but I think most people would still consider those memory safe languages. The important question is: is there a well-defined safety boundary, somewhere between the CPU and your application code, where memory is guaranteed* not to be corrupted and the programmer is freed from worrying about low-level bugs like segfaults? *assuming no outside bugs such as CPU bugs, bugs in the GC, or bugs in an unsafe block
  - mr_00ff00 4y ago
    This doesn’t make sense. So rust let’s you write unsafe code, and now that’s the same as any language that calls C in any way? Why replace C++ then? After all, rust is just as unsafe by your definition. Having a language that is default safe and can only be unsafe in rare situations is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary.
    - rom-antics 4y ago
      > Having a language that is default safe and can only be unsafe in rare situations This describes both Python and Rust. They are default safe, with escape hatches (ctypes or unsafe blocks) for rare situations. Writing unsafe code in Rust should be as rare as using ctypes in Python. > is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary. Python lets libs use ctypes to poke at raw memory. Solution: avoid those libraries Rust lets libs use unsafe blocks. Solution: avoid those libraries (and optionally use tools like cargo-geiger or forbid(unsafe) if you care enough
      - mr_00ff00 4y ago
        If you don’t seem a parallel between what you just said: “just use these tools to catch the unsafe parts of rust” and the C++ crowd saying “just use these tools or do these things to catch the unsafe parts of cpp” there’s no point in continuing this discussion. Python ctypes are not at all as common as rust unsafe code and geiger only goes so deep in search for unsafe code if I remember correctly.
- burntsushi 4y ago
  Isn't it obvious? The position is not against the use of code that might cause UB, it's against making that the default everywhere. In Rust, unsafe is opt in and can be encapsulated. That's the key bit.
tayo42 4y ago
Yeah with things like are we web yet, rust presents it self as can do anything language. Which sure technically it can, but atm I think it's a only appropriate when you have an army of developers at some money printing company that go and write all your dependencies To answer the above question, like cli tools

spenczar5 4y ago

I have one: scientific software. There's a growing recognition that Python is creaking under the weight of scientific applications that lean on it. It's very difficult to write efficient, maintainable, large-scale software systems with it. An example that comes to mind is data reduction pipelines for the bytes coming out of a major telescope, like that of LSST. I worked on those pipelines, and a lot of the effort was around figuring out how to consistently build the dang thing given the looseness of Python's systems. An equally large amount of the effort was on trying to eke out the performance of Python via Numpy tricks, Numba, etc, which impinged readability and maintainability. In some places, we fall back on a C++ core, but nobody is happy about that, for all the usual reasons. Some of us advocated for Rust... but it was never really plausible, because the interactions with Python numerical and scientific libraries are so immature. People are starting to work on it but it's hard to compete with the decades of work put into C++ and Python as the core of scientific stacks.

throw_away1525 4y ago
Julia seems to be a great potential replacement for Python for scientific software.
- spenczar5 4y ago
  I totally agree, and it has identical issues. The momentum behind Python and C++ is enormous, so catching up is hard.