6 ms·

Just like with Javascript, everything must be rebuilt again!..

drzaiusapelord 9y ago
Except Rust has incredible memory safety, without cumbersome and slow GC, and runs close to C++ speeds, unlike the heavy, wasteful, and slow frameworks you mention like Electron or HTML5. Rust is a modern C/C++ replacement, or at least tries to be. That's no mean feat.
- mseri 9y ago
  Plus alacritty looks great and is much faster and lighter than most other terminal emulators, ripgrep is a great replacement for grep and can be a serious improvement when you are searching through millions of lines on thousands of giant files. To mention just the two of them...
  - bpicolo 9y ago
    I only use ripgrep these days.
  - Spiritus 9y ago
    Alacritty is full of render issues and missing features. It's fast because it barely does anything, and doesn't even do it correct. Just check the ever growing laundry list of issues it has on Github. With that said, it's a very interesting project. Especially with regards to its rendering engine.
- wulfklaue 9y ago
  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.
- rurban 9y ago
  I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything. For fairness you need to compare Rust to D or Pony or SBCL, which are also close to C++ (even faster), plus added concurrency safety or memory safety, which can be circumvented in Rust.
  - adwn 9y ago
    > I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything. In idiomatic Rust code, you typically have very few reference increments/decrements, making it faster and more efficient than both, GC and traditional RC-based approaches. The reasons for this are that objects are often allocated on the stack, passed by reference (a safe pointer), and directly integrated into a larger structure, requiring fewer heap allocations and very few – if any – refcounted objects. In Rust, unlike C or C++, you can do this safely and ergonomically because Rust enforces clear and well-defined ownership semantics.
    - rurban 9y ago
      I do know rust, their RC problems, their unsafe problems, their concurrency and locking problems and their type system problems. What is problematic is that the rust community does not care about it and still repeats wrong sentences all over. (Besides downvoting, but this just shows how much they don't care to learn)
      - steveklabnik 9y ago
        You haven't actually demonstrated any problems, just repeated that they exist. Unsubstantiated criticism usually gets downvoted on HN, Rust or not.
      - adwn 9y ago
        > I do know rust, their RC problems, their unsafe problems, their concurrency and locking problems and their type system problems. Please elaborate. In particular, what RC and concurrency problems?
freyr 9y ago
Yeah, hard to imagine that things can improve over time!
baq 9y ago
try ripgrep, it'll blow your socks off.
- majewsky 9y ago
  What makes ripgrep fast (AFAIK) is mainly using mmap() instead of open()/read() to read files, and relying on Rust's regex library that compiles regexes to DFAs which can run in linear time. Those are things that you can do just as well in C. To witness, https://github.com/ggreer/the_silver_searcher https://github.com/ggreer/the_silver_searcher (aka "ag") is about as fast as ripgrep, but written in C. This is not to say that Rust does not have benefits. But the benefit is not "speed", but "speed plus security".
  - bpicolo 9y ago
    Here's a much more thorough post on why it's fast. mmap is only a small part of it (a bunch of the grep implementations mmap) http://blog.burntsushi.net/ripgrep/ http://blog.burntsushi.net/ripgrep/
    - j1f4 9y ago
      That's a great blog post. The `linux_literal` section is particularly interesting re: mmap.
  - joshuata 9y ago
    Ripgrep only uses mmap() when it is searching very few files. For anything beyond that it uses intermediate buffers.
  - pcwalton 9y ago
    I switched from ag to rg a while ago. The speed benefits are noticeable.
  - burntsushi 9y ago
    > Those are things that you can do just as well in C. [..] But the benefit is not "speed", but "speed plus security". But nobody said otherwise? I don't understand your point. Speed + safety is indeed precisely the point. I would implore you to do your own comparative analysis by looking at the types of bugs reported for these search tools. (I can't do this for you. If I could, I would.) > What makes ripgrep fast (AFAIK) is mainly using mmap() instead of open()/read() to read files, I think you're confused. This is what the author of the silver searcher has claimed for a long time, but with ripgrep, it's actually precisely the opposite. When searching a large directory of files, memory mapping them has so much overhead that reading files into intermediate fixed size buffers is actually faster. Memory maps can occasionally be faster, but only when the size of the file is large enough to overcome the overhead. A code repository has many many small files, so memory maps do worse. (N.B. My context here is Linux. This doesn't necessarily apply to other operating systems.) > and relying on Rust's regex library that compiles regexes to DFAs which can run in linear time. There's no confusion that such things can't be done in C. GNU grep also uses a lazy DFA, for example, and is written in C. The "linear time" aspect doesn't show up too often, and none of my benchmarks[1] actually exploit that. There's a lot more to the story of how ripgrep beats the silver searcher. "About as fast" is fairly accurate in many cases, but to stop there would be pretty sad because you'd miss out on other cool things like: - SIMD for multiple pattern matching - Heuristics for improving usage of memchr - Parallel directory iterator (all safe Rust code) - Fast multiple glob matching In many cases, this can make a big difference. Try searching the MySQL server repository, for example, and you'll find that the silver searcher isn't "about as fast" as ripgrep. (Hint: Take a peek at its .gitignore file.[2] This has nothing to do with memory maps, SIMD or linear time regex engines.) And yes, I could have done all of this in C. But it's likely I would have given up long before I finished. [1] - http://blog.burntsushi.net/ripgrep/ http://blog.burntsushi.net/ripgrep/ [2] - https://github.com/mysql/mysql-server/blob/5.7/.gitignore https://github.com/mysql/mysql-server/blob/5.7/.gitignore

Except Rust has incredible memory safety, without cumbersome and slow GC, and runs close to C++ speeds, unlike the heavy, wasteful, and slow frameworks you mention like Electron or HTML5. Rust is a modern C/C++ replacement, or at least tries to be. That's no mean feat.

mseri 9y ago
Plus alacritty looks great and is much faster and lighter than most other terminal emulators, ripgrep is a great replacement for grep and can be a serious improvement when you are searching through millions of lines on thousands of giant files. To mention just the two of them...
- bpicolo 9y ago
  I only use ripgrep these days.
- Spiritus 9y ago
  Alacritty is full of render issues and missing features. It's fast because it barely does anything, and doesn't even do it correct. Just check the ever growing laundry list of issues it has on Github. With that said, it's a very interesting project. Especially with regards to its rendering engine.
wulfklaue 9y ago
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.
rurban 9y ago
I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything. For fairness you need to compare Rust to D or Pony or SBCL, which are also close to C++ (even faster), plus added concurrency safety or memory safety, which can be circumvented in Rust.
- adwn 9y ago
  > I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything. In idiomatic Rust code, you typically have very few reference increments/decrements, making it faster and more efficient than both, GC and traditional RC-based approaches. The reasons for this are that objects are often allocated on the stack, passed by reference (a safe pointer), and directly integrated into a larger structure, requiring fewer heap allocations and very few – if any – refcounted objects. In Rust, unlike C or C++, you can do this safely and ergonomically because Rust enforces clear and well-defined ownership semantics.
  - rurban 9y ago
    I do know rust, their RC problems, their unsafe problems, their concurrency and locking problems and their type system problems. What is problematic is that the rust community does not care about it and still repeats wrong sentences all over. (Besides downvoting, but this just shows how much they don't care to learn)
    - steveklabnik 9y ago
      You haven't actually demonstrated any problems, just repeated that they exist. Unsubstantiated criticism usually gets downvoted on HN, Rust or not.
    - adwn 9y ago
      > I do know rust, their RC problems, their unsafe problems, their concurrency and locking problems and their type system problems. Please elaborate. In particular, what RC and concurrency problems?

freyr 9y ago

Yeah, hard to imagine that things can improve over time!

baq 9y ago

try ripgrep, it'll blow your socks off.

majewsky 9y ago
What makes ripgrep fast (AFAIK) is mainly using mmap() instead of open()/read() to read files, and relying on Rust's regex library that compiles regexes to DFAs which can run in linear time. Those are things that you can do just as well in C. To witness, https://github.com/ggreer/the_silver_searcher https://github.com/ggreer/the_silver_searcher (aka "ag") is about as fast as ripgrep, but written in C. This is not to say that Rust does not have benefits. But the benefit is not "speed", but "speed plus security".
- bpicolo 9y ago
  Here's a much more thorough post on why it's fast. mmap is only a small part of it (a bunch of the grep implementations mmap) http://blog.burntsushi.net/ripgrep/ http://blog.burntsushi.net/ripgrep/
  - j1f4 9y ago
    That's a great blog post. The `linux_literal` section is particularly interesting re: mmap.
- joshuata 9y ago
  Ripgrep only uses mmap() when it is searching very few files. For anything beyond that it uses intermediate buffers.
- pcwalton 9y ago
  I switched from ag to rg a while ago. The speed benefits are noticeable.
- burntsushi 9y ago
  > Those are things that you can do just as well in C. [..] But the benefit is not "speed", but "speed plus security". But nobody said otherwise? I don't understand your point. Speed + safety is indeed precisely the point. I would implore you to do your own comparative analysis by looking at the types of bugs reported for these search tools. (I can't do this for you. If I could, I would.) > What makes ripgrep fast (AFAIK) is mainly using mmap() instead of open()/read() to read files, I think you're confused. This is what the author of the silver searcher has claimed for a long time, but with ripgrep, it's actually precisely the opposite. When searching a large directory of files, memory mapping them has so much overhead that reading files into intermediate fixed size buffers is actually faster. Memory maps can occasionally be faster, but only when the size of the file is large enough to overcome the overhead. A code repository has many many small files, so memory maps do worse. (N.B. My context here is Linux. This doesn't necessarily apply to other operating systems.) > and relying on Rust's regex library that compiles regexes to DFAs which can run in linear time. There's no confusion that such things can't be done in C. GNU grep also uses a lazy DFA, for example, and is written in C. The "linear time" aspect doesn't show up too often, and none of my benchmarks[1] actually exploit that. There's a lot more to the story of how ripgrep beats the silver searcher. "About as fast" is fairly accurate in many cases, but to stop there would be pretty sad because you'd miss out on other cool things like: - SIMD for multiple pattern matching - Heuristics for improving usage of memchr - Parallel directory iterator (all safe Rust code) - Fast multiple glob matching In many cases, this can make a big difference. Try searching the MySQL server repository, for example, and you'll find that the silver searcher isn't "about as fast" as ripgrep. (Hint: Take a peek at its .gitignore file.[2] This has nothing to do with memory maps, SIMD or linear time regex engines.) And yes, I could have done all of this in C. But it's likely I would have given up long before I finished. [1] - http://blog.burntsushi.net/ripgrep/ http://blog.burntsushi.net/ripgrep/ [2] - https://github.com/mysql/mysql-server/blob/5.7/.gitignore https://github.com/mysql/mysql-server/blob/5.7/.gitignore