4 ms·

> "can we have speed, correctness, and expressiveness in one language?" Didn't ocaml already answer that question? Since ocaml hasn't dominated, it seems somet

> "can we have speed, correctness, and expressiveness in one language?" Didn't ocaml already answer that question? Since ocaml hasn't dominated, it seems something more is required... What has rust got beyond that?

maccam94 8y ago
> OCaml bytecode and native code programs can be written in a multithreaded style, with preemptive context switching. However, because the garbage collector of the INRIA OCaml system (which is the only currently available full implementation of the language) is not designed for concurrency, symmetric multiprocessing is unsupported. --https://en.wikipedia.org/wiki/OCaml https://en.wikipedia.org/wiki/OCaml Rust has memory-safe concurrency without a GC.
GolDDranks 8y ago
Threads and predictable runtime model. (No GC)
- lmm 8y ago
  Threads are an implementation technique, not a user requirement (at least they shouldn't be).
- ernst_klim 8y ago
  Rust does not have predictable allocations, till it would have custom allocators. Malloc is not better than GC.
  - imtringued 8y ago
    You're moving goal posts so far I don't even understand what your point is. Malloc vs GC doesn't matter at all because you can decide to not use it if you don't want to in Rust, C, C++. The vast majority of performance sensitive code avoids dynamic allocation of memory at all costs by either preallocating a large chunk of memory upfront and reusing it or by only using the stack. When no allocations are performed in a time critical section of code it is not affected by other threads making allocations. This is what a predictable runtime model is. Programming languages like javascript or python always dynamically allocate every single object. When the GC does it's job it has to stop all threads and therefore will stop your time critical code even if you avoid allocating inside it. This is what is commonly understood as an unpredictable runtime model. What does predictable allocations even mean? Allocation is always predictable, it will happen when you use "new" (Java), "Box::new"(Rust), malloc, etc. The unpredictable aspect is the stop the world pause caused by garbage collection. Your complaint regarding custom allocators doesn't make sense because arena allocators [0] and probably others are available in rust. [0] https://doc.rust-lang.org/1.1.0/arena/index.html https://doc.rust-lang.org/1.1.0/arena/index.html
    - ernst_klim 8y ago
      >The unpredictable aspect is the stop the world pause caused by garbage collection. As well as malloc pauses on deallocation. The only way of using your memory in realtime apps is preallocation, which often can be done in languages with GC too, it would be just very inconvenient. At the moment custom allocation support in rust is a joke if you compare it with Ada or C++, and Box is not better than GC in this regard. >Unstable Besides it's very inconvenient to use. Does Box/Rc/Arc support this arena allocator, as C++'s smart_pointers do?

maccam94 8y ago

> OCaml bytecode and native code programs can be written in a multithreaded style, with preemptive context switching. However, because the garbage collector of the INRIA OCaml system (which is the only currently available full implementation of the language) is not designed for concurrency, symmetric multiprocessing is unsupported. --https://en.wikipedia.org/wiki/OCaml https://en.wikipedia.org/wiki/OCaml Rust has memory-safe concurrency without a GC.

GolDDranks 8y ago

Threads and predictable runtime model. (No GC)

lmm 8y ago
Threads are an implementation technique, not a user requirement (at least they shouldn't be).
ernst_klim 8y ago
Rust does not have predictable allocations, till it would have custom allocators. Malloc is not better than GC.
- imtringued 8y ago
  You're moving goal posts so far I don't even understand what your point is. Malloc vs GC doesn't matter at all because you can decide to not use it if you don't want to in Rust, C, C++. The vast majority of performance sensitive code avoids dynamic allocation of memory at all costs by either preallocating a large chunk of memory upfront and reusing it or by only using the stack. When no allocations are performed in a time critical section of code it is not affected by other threads making allocations. This is what a predictable runtime model is. Programming languages like javascript or python always dynamically allocate every single object. When the GC does it's job it has to stop all threads and therefore will stop your time critical code even if you avoid allocating inside it. This is what is commonly understood as an unpredictable runtime model. What does predictable allocations even mean? Allocation is always predictable, it will happen when you use "new" (Java), "Box::new"(Rust), malloc, etc. The unpredictable aspect is the stop the world pause caused by garbage collection. Your complaint regarding custom allocators doesn't make sense because arena allocators [0] and probably others are available in rust. [0] https://doc.rust-lang.org/1.1.0/arena/index.html https://doc.rust-lang.org/1.1.0/arena/index.html
  - ernst_klim 8y ago
    >The unpredictable aspect is the stop the world pause caused by garbage collection. As well as malloc pauses on deallocation. The only way of using your memory in realtime apps is preallocation, which often can be done in languages with GC too, it would be just very inconvenient. At the moment custom allocation support in rust is a joke if you compare it with Ada or C++, and Box is not better than GC in this regard. >Unstable Besides it's very inconvenient to use. Does Box/Rc/Arc support this arena allocator, as C++'s smart_pointers do?