17 ms·

By using a garbage collector, Go must compete with python, ruby, haskell, clojure, java, scala, c#, etc. Maybe Go is nice for some things, but it seems like an

By using a garbage collector, Go must compete with python, ruby, haskell, clojure, java, scala, c#, etc. Maybe Go is nice for some things, but it seems like an incremental improvement over the next best alternative. Rust only needs to compete against c, c++, Ada, etc. In that class of languages, safety is a major feature.

krenoten 12y ago
This is so much more important than people are generally aware of. We are leaving the point in time that writing highly bug-prone C or C++ is justifiable due to performance concerns. The justifiability of these up until now is a huge reason why governments and organized crime have been able to buy the keys to our servers and personal machines. We are going to be able to replace ubiquitous, critical, buggy code with something that will significantly increase the costs of finding and exploiting RCE vulnerabilities. This is so huge.
- Ygg2 12y ago
  For now, I don't think Rust is as performant as C/C++. Although it should be able to match C/C++ speed, I think there are some cases where the output was slower than expected.
  - krenoten 12y ago
    You are absolutely correct. I should say that the THEORETICAL performance of Rust may be competitive with C++, maybe even faster in some cases, but that work remains to be done to get it there. My above statement assumes that this day will come, or that the performance at least reaches a point that will allow a reasonable engineer to choose Rust over C or C++ for something that performance is a crucial consideration for.
  - brohee 12y ago
    There are actually cases where Rust is faster than C already, one of the reasons being the compiler emitting better code thanks to mutable aliasing being forbidden. http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html
    - zzzcpan 12y ago
      It's not why C is faster, it's more about being able to use hand crafted SSE2 instructions and existing libraries with such optimizations. Nothing competes with C when performance really matters.
      - krenoten 12y ago
        Feel free to use the asm! macro in rust when you need to. FFI support is also quite good.
      - pcwalton 12y ago
        You can use "hand-crafted" SSE2 instructions and libraries with the same in Rust. Servo heavily relies on Skia, for example…
      - hetman 12y ago
        Technically Fortran does compete. For computational applications it is faster than C and hence why it's so popular in supercomputing.
      - bjz_ 12y ago
        There is also a case for making highly optimized C performance easier to attain, without needing to resort to unsafe code. You can do this by providing more invariants to the compiler via a better type system, which gives it more room to optimize. It may never get to the performance of hand-optimized stuff, but for that there is unsafe code blocks.
    - deleted 12y ago
      [deleted]
  - NateDad 12y ago
    I think the point is that machines are fast enough that being as fast as C++ doesn't matter anymore.
    - furyofantares 12y ago
      True for many things. But there are still plenty of things that we still want to do faster or cheaper or that we want to feed more data to, and we also still find plenty of new things to do as computers get more powerful.
pron 12y ago
I find comparing Rust and Go baffling. Both are relatively new, and both compile to native binaries, but their approach and purpose are completely different. The Go runtime provides GC, its own scheduler, time abstractions -- basically everything a JVM is required to do (plus the scheduler)[1]. It's an AOT-compiled Java. Because of its high-abstraction runtime, interoperation with native libraries is hard to nearly impossible (depending on the direction). It is to be used to write server-side applications. It's Java without the JVM, for better or worse (native binary, short startup, but no dynamic code swapping, no multiple languages support, no instrumentation, no JIT, and no deep monitoring) Rust, on the other hand, is a modern C/C++ replacement. It is meant to be used anywhere C or C++ are used. It can be used to write applications, device drivers, operating systems, or fully native libraries (that can be called from Java, Go, Python or Fortran). Neither approach is better than the other, but the two are so different that they can't even be compared directly. One is Java minus the JVM, and the other is a C/C++ replacement. [1]: GC (or rather the illusion of infinite memory), abstracting OS time plus some other OS abstractions -- all provided by Go but but not Rust), are the only things required from a JVM. Runtime bytecode interpretation or JIT -- what most people usually associate with JVMs -- are actually not required; some JVMs, particularly those for hard realtime and safety critical code, perform AOT compilation.
- krenoten 12y ago
  They are compared because as humans, we are much better at learning new things when contrasted to other things that we are aware of. A concept that has absolutely no parallels with a previously encountered one is much more difficult to understand. From this perspective, it is actually quite useful to compare these two things.
- austinz 12y ago
  I always thought it was because both languages were (at least at some point) referred to and advertised as 'systems languages', which naturally invited comparisons. However, 'systems' meant different things for each language. For Go, 'systems' as in the sense of software running on servers providing services to user applications. For Rust, 'systems' as in the sense of (http://en.wikipedia.org/wiki/System_programming_language http://en.wikipedia.org/wiki/System_programming_language) - software such as OSes, device drivers, etc. Just for fun, Swift is advertised as a systems language as well. In its defense, it does have facilities for bypassing the preferred way of managing memory (ARC) and working with memory directly.

krenoten 12y ago

This is so much more important than people are generally aware of. We are leaving the point in time that writing highly bug-prone C or C++ is justifiable due to performance concerns. The justifiability of these up until now is a huge reason why governments and organized crime have been able to buy the keys to our servers and personal machines. We are going to be able to replace ubiquitous, critical, buggy code with something that will significantly increase the costs of finding and exploiting RCE vulnerabilities. This is so huge.

Ygg2 12y ago
For now, I don't think Rust is as performant as C/C++. Although it should be able to match C/C++ speed, I think there are some cases where the output was slower than expected.
- krenoten 12y ago
  You are absolutely correct. I should say that the THEORETICAL performance of Rust may be competitive with C++, maybe even faster in some cases, but that work remains to be done to get it there. My above statement assumes that this day will come, or that the performance at least reaches a point that will allow a reasonable engineer to choose Rust over C or C++ for something that performance is a crucial consideration for.
- brohee 12y ago
  There are actually cases where Rust is faster than C already, one of the reasons being the compiler emitting better code thanks to mutable aliasing being forbidden. http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html
  - zzzcpan 12y ago
    It's not why C is faster, it's more about being able to use hand crafted SSE2 instructions and existing libraries with such optimizations. Nothing competes with C when performance really matters.
    - krenoten 12y ago
      Feel free to use the asm! macro in rust when you need to. FFI support is also quite good.
    - pcwalton 12y ago
      You can use "hand-crafted" SSE2 instructions and libraries with the same in Rust. Servo heavily relies on Skia, for example…
    - hetman 12y ago
      Technically Fortran does compete. For computational applications it is faster than C and hence why it's so popular in supercomputing.
    - bjz_ 12y ago
      There is also a case for making highly optimized C performance easier to attain, without needing to resort to unsafe code. You can do this by providing more invariants to the compiler via a better type system, which gives it more room to optimize. It may never get to the performance of hand-optimized stuff, but for that there is unsafe code blocks.
  - deleted 12y ago
    [deleted]
- NateDad 12y ago
  I think the point is that machines are fast enough that being as fast as C++ doesn't matter anymore.
  - furyofantares 12y ago
    True for many things. But there are still plenty of things that we still want to do faster or cheaper or that we want to feed more data to, and we also still find plenty of new things to do as computers get more powerful.

pron 12y ago

I find comparing Rust and Go baffling. Both are relatively new, and both compile to native binaries, but their approach and purpose are completely different. The Go runtime provides GC, its own scheduler, time abstractions -- basically everything a JVM is required to do (plus the scheduler)[1]. It's an AOT-compiled Java. Because of its high-abstraction runtime, interoperation with native libraries is hard to nearly impossible (depending on the direction). It is to be used to write server-side applications. It's Java without the JVM, for better or worse (native binary, short startup, but no dynamic code swapping, no multiple languages support, no instrumentation, no JIT, and no deep monitoring) Rust, on the other hand, is a modern C/C++ replacement. It is meant to be used anywhere C or C++ are used. It can be used to write applications, device drivers, operating systems, or fully native libraries (that can be called from Java, Go, Python or Fortran). Neither approach is better than the other, but the two are so different that they can't even be compared directly. One is Java minus the JVM, and the other is a C/C++ replacement. [1]: GC (or rather the illusion of infinite memory), abstracting OS time plus some other OS abstractions -- all provided by Go but but not Rust), are the only things required from a JVM. Runtime bytecode interpretation or JIT -- what most people usually associate with JVMs -- are actually not required; some JVMs, particularly those for hard realtime and safety critical code, perform AOT compilation.

krenoten 12y ago
They are compared because as humans, we are much better at learning new things when contrasted to other things that we are aware of. A concept that has absolutely no parallels with a previously encountered one is much more difficult to understand. From this perspective, it is actually quite useful to compare these two things.
austinz 12y ago
I always thought it was because both languages were (at least at some point) referred to and advertised as 'systems languages', which naturally invited comparisons. However, 'systems' meant different things for each language. For Go, 'systems' as in the sense of software running on servers providing services to user applications. For Rust, 'systems' as in the sense of (http://en.wikipedia.org/wiki/System_programming_language http://en.wikipedia.org/wiki/System_programming_language) - software such as OSes, device drivers, etc. Just for fun, Swift is advertised as a systems language as well. In its defense, it does have facilities for bypassing the preferred way of managing memory (ARC) and working with memory directly.