2 ms·

Yes, it can link dynamically: $ ldd pidigits.rust linux-vdso.so.1 (0x00007fff8b9e7000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10

by dbaupp 12y ago

Yes, it can link dynamically: $ ldd pidigits.rust linux-vdso.so.1 (0x00007fff8b9e7000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f5c233be000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5c231ba000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5c22f9c000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5c22d86000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5c229de000) /lib64/ld-linux-x86-64.so.2 (0x00007f5c2372b000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5c226dc000)

acqq 12y ago
You see, I'm certainly not the only one who wouldn't know all this unless there are good benchmark examples (or have the luck of being able to ask and receive the answer from you. I believe Go couldn't do that once, I don't know the current state. Thank you. But a lot of people wouldn't get so far. Therefore please do promote good examples of the fast code that do something real, like these benchmarks.
- dbaupp 12y ago
  Linkage and FFI are described (to some degree, at least) in the FFI guide. http://doc.rust-lang.org/nightly/guide-ffi.html http://doc.rust-lang.org/nightly/guide-ffi.html Do you prefer reading benchmarks over the textual documentation? (genuine question)
  - acqq 12y ago
    Yes I do prefer one good benchmark over ton of stale manuals. The good written benchmark code should show the best possible aspect of the language: how the code looks when it has to compete in speed too. If the code is demonstrably cleaner and almost as fast as C, then it can be a winner. If it's more than 2 times slower, I don't care, unless it has some fantastic libraries or framework which solves something much easier than other languages. Fast and looking nice when solving something like a real problem. Benchmarks can demonstrate that. Manuals and references typically not.
    - dbaupp 12y ago
      > Fast and looking nice when solving something like a real problem. Benchmarks can demonstrate that. Manuals and references typically not. They certainly can. The actual "specification" documents probably not, but guides and tutorials (like Rust offers) can and (some of them) do.

by dbaupp 12y ago

acqq 12y ago

You see, I'm certainly not the only one who wouldn't know all this unless there are good benchmark examples (or have the luck of being able to ask and receive the answer from you. I believe Go couldn't do that once, I don't know the current state. Thank you. But a lot of people wouldn't get so far. Therefore please do promote good examples of the fast code that do something real, like these benchmarks.

dbaupp 12y ago
Linkage and FFI are described (to some degree, at least) in the FFI guide. http://doc.rust-lang.org/nightly/guide-ffi.html http://doc.rust-lang.org/nightly/guide-ffi.html Do you prefer reading benchmarks over the textual documentation? (genuine question)
- acqq 12y ago
  Yes I do prefer one good benchmark over ton of stale manuals. The good written benchmark code should show the best possible aspect of the language: how the code looks when it has to compete in speed too. If the code is demonstrably cleaner and almost as fast as C, then it can be a winner. If it's more than 2 times slower, I don't care, unless it has some fantastic libraries or framework which solves something much easier than other languages. Fast and looking nice when solving something like a real problem. Benchmarks can demonstrate that. Manuals and references typically not.
  - dbaupp 12y ago
    > Fast and looking nice when solving something like a real problem. Benchmarks can demonstrate that. Manuals and references typically not. They certainly can. The actual "specification" documents probably not, but guides and tutorials (like Rust offers) can and (some of them) do.