3 ms·

Except that there are other languages like Go, Crystal, D, Nim that all offer memory safety ( thanks to there GC ), with a light GC ( like reference counting ).

Except that there are other languages like Go, Crystal, D, Nim that all offer memory safety ( thanks to there GC ), with a light GC ( like reference counting ). And based upon the same benchmarks that Rust in participates, they are close or even faster at times, with close or better memory usage. https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks

bnolsen 9y ago
GCs are nondeterministic amongst other issues. Baking one into the core of a systems language likely isn't a good idea.
- pjmlp 9y ago
  It worked out alright for Algol 68RS, Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Sing#, System C#. Those systems failed market adoption mostly due to politics and company acquisitions than technical hurdles.
  - adrianN 9y ago
    Some applications are easier without a GC. Embedded work comes to mind. Realtime guarantees for systems with GC are also somewhat tricky (though not impossible to achieve).
    - pjmlp 9y ago
      True, but just because a systems language has a GC doesn't mean one has to use it everywhere, it is the only mechanism to allocate memory or that it has to run all the time. Modula-3 is a good example of how to support all scenarios required by a systems programming language with GC, unfortunately Compaq buying DEC followed by HP buying Compaq, killed all the work the SRC group was doing. For embedded work check the Oberon compilers sold by Astrobe for ARM Cortex-M3, Cortex-M4 and Cortex-M7, as well as, Xilinx FPGA Systems.
- rurban 9y ago
  Baking unsafe memory languages with limited type systems and blocking libraries for the hard parts is neither a good idea for systems.
ryeguy 9y ago
Try these benchmarks instead: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html Rust should be beating the majority of those languages in well-implemented comparisons.
dom0 9y ago
> light GC ( like reference counting ) Refcounting is often one of the slower ways to implement a GC. It also has other issues, like long GC pauses when a large structure goes out of scope.

bnolsen 9y ago

GCs are nondeterministic amongst other issues. Baking one into the core of a systems language likely isn't a good idea.

pjmlp 9y ago
It worked out alright for Algol 68RS, Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Sing#, System C#. Those systems failed market adoption mostly due to politics and company acquisitions than technical hurdles.
- adrianN 9y ago
  Some applications are easier without a GC. Embedded work comes to mind. Realtime guarantees for systems with GC are also somewhat tricky (though not impossible to achieve).
  - pjmlp 9y ago
    True, but just because a systems language has a GC doesn't mean one has to use it everywhere, it is the only mechanism to allocate memory or that it has to run all the time. Modula-3 is a good example of how to support all scenarios required by a systems programming language with GC, unfortunately Compaq buying DEC followed by HP buying Compaq, killed all the work the SRC group was doing. For embedded work check the Oberon compilers sold by Astrobe for ARM Cortex-M3, Cortex-M4 and Cortex-M7, as well as, Xilinx FPGA Systems.
rurban 9y ago
Baking unsafe memory languages with limited type systems and blocking libraries for the hard parts is neither a good idea for systems.

ryeguy 9y ago

Try these benchmarks instead: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html Rust should be beating the majority of those languages in well-implemented comparisons.

dom0 9y ago

> light GC ( like reference counting ) Refcounting is often one of the slower ways to implement a GC. It also has other issues, like long GC pauses when a large structure goes out of scope.