6 ms·

Java and .NET are Safe..... O.o Edit: For the uninitiated, I am baffled by the fact that people think Java and .NET are memory safe. Also if you meant that

Java and .NET are Safe..... O.o Edit: For the uninitiated, I am baffled by the fact that people think Java and .NET are memory safe. Also if you meant that Java and .NET should be replaced by something memory safe.. I am absolutely for it. :)

pjmlp 7y ago
More than Rust in multithreaded scenarios, actually. Not only they have automatic memory management, they have an industry standard memory model for hardware access, adopted by C and C++ standards, used as inspiration for std:atomic<> on CUDA. While you keep being baffled, where is Rust's memory model specification?
- minraws 7y ago
  Not sure where I said, Rust is memory safe.... Though. Just scroll up, I explicitly mentioned how it isn't. I just want to say, Java and C# isn't as safe as most people think. Define industry standard, cause nothing points me towards industry standards actually being better than not industry standards. Has everyone forgotten these http://cs.oswego.edu/pipermail/concurrency-interest/2017-December/016272.html http://cs.oswego.edu/pipermail/concurrency-interest/2017-Dec... Nevertheless who knows I might not know anything, and I love being proved wrong when it makes most of the world a safer place (quite literally)... :P
- dbaupp 7y ago
  There's a good argument to be made that Rust is safer in multithreaded scenarios than the JVM or .NET. Rust statically prevents inappropriate unsynchronized accesses for arbitrary APIs (for instance, the compiler will emit an error when attempting to mutate a non-concurrent object/data structure from multiple threads). Those VMs make unsynchronized mutations of individual memory locations work just enough to not be unsafe, but still allow arbitrary unsynchronized operations. These will likely end up with an incorrect result, even if there's no memory unsafety, and may completely violate any internal invariants of the object or data structure. This latter point means one cannot write a correct abstraction that relies on its invariants without explicitly considering threadsafety (it is opt-in safety), whereas Rust has this by default (opt-out safety). Rust has essentially adopted the C/C++11 concurrency model.
  - pjmlp 7y ago
    Yes, it is one less failure point to worry about, but in my experience using the respective task libraries in distributed applications, most of the multithreaded access bugs lie on external resource usage, and those Rust does not prevent. Not saying that it isn't important though.
    - dbaupp 7y ago
      Ownership/affine typing does allow modelling that, within a single program. For instance, the type representing a handle to the external resource can have limited constructors and limited operations, that will enforce single threaded mutations or access (including things like "this object can only be destroyed by the thread that created it").
      - pjmlp 7y ago
        Assuming you are accessing the distributed resource from multiple threads instead of multiple distributed processes, which is quite common in distributed architectures. Borrow checker doesn't help at all with process IPC. Plus all ML derived languages have good enough type systems to model network states, while enjoying the productivity of automatic memory management.
AgentME 7y ago
When was the last time a Java or .NET codebase had an RCE from writing past the end of a list? The only RCEs in safe languages generally only happen in uncommon explicit code-loading calls or explicitly unsafe memory access calls.

pjmlp 7y ago

More than Rust in multithreaded scenarios, actually. Not only they have automatic memory management, they have an industry standard memory model for hardware access, adopted by C and C++ standards, used as inspiration for std:atomic<> on CUDA. While you keep being baffled, where is Rust's memory model specification?

minraws 7y ago
Not sure where I said, Rust is memory safe.... Though. Just scroll up, I explicitly mentioned how it isn't. I just want to say, Java and C# isn't as safe as most people think. Define industry standard, cause nothing points me towards industry standards actually being better than not industry standards. Has everyone forgotten these http://cs.oswego.edu/pipermail/concurrency-interest/2017-December/016272.html http://cs.oswego.edu/pipermail/concurrency-interest/2017-Dec... Nevertheless who knows I might not know anything, and I love being proved wrong when it makes most of the world a safer place (quite literally)... :P
dbaupp 7y ago
There's a good argument to be made that Rust is safer in multithreaded scenarios than the JVM or .NET. Rust statically prevents inappropriate unsynchronized accesses for arbitrary APIs (for instance, the compiler will emit an error when attempting to mutate a non-concurrent object/data structure from multiple threads). Those VMs make unsynchronized mutations of individual memory locations work just enough to not be unsafe, but still allow arbitrary unsynchronized operations. These will likely end up with an incorrect result, even if there's no memory unsafety, and may completely violate any internal invariants of the object or data structure. This latter point means one cannot write a correct abstraction that relies on its invariants without explicitly considering threadsafety (it is opt-in safety), whereas Rust has this by default (opt-out safety). Rust has essentially adopted the C/C++11 concurrency model.
- pjmlp 7y ago
  Yes, it is one less failure point to worry about, but in my experience using the respective task libraries in distributed applications, most of the multithreaded access bugs lie on external resource usage, and those Rust does not prevent. Not saying that it isn't important though.
  - dbaupp 7y ago
    Ownership/affine typing does allow modelling that, within a single program. For instance, the type representing a handle to the external resource can have limited constructors and limited operations, that will enforce single threaded mutations or access (including things like "this object can only be destroyed by the thread that created it").
    - pjmlp 7y ago
      Assuming you are accessing the distributed resource from multiple threads instead of multiple distributed processes, which is quite common in distributed architectures. Borrow checker doesn't help at all with process IPC. Plus all ML derived languages have good enough type systems to model network states, while enjoying the productivity of automatic memory management.

AgentME 7y ago

When was the last time a Java or .NET codebase had an RCE from writing past the end of a list? The only RCEs in safe languages generally only happen in uncommon explicit code-loading calls or explicitly unsafe memory access calls.