6 ms·

Why do "convert everything to rust" people appear to prefer solving already solved problems instead of focusing on problems we could not solve but are now possi

Why do "convert everything to rust" people appear to prefer solving already solved problems instead of focusing on problems we could not solve but are now possible thanks to Rust?

pests 8y ago
Guess we should all just stop doing anything then.
empath75 8y ago
If you’re learning a language, reimplementing something that’s already been solved is a fairly standard learning exercise.
carlmr 8y ago
Apart from the aspect that you're new to a language and just want to learn something you might make an improved version. ripgrep is a Rust version of grep. It's the fastest grep I know and it has better Unicode support than GNU grep (because of Rust language decisions). Looking at memory safety and portability it might also be a good idea to program them in Rust. There are whole classes of bugs that are excluded in Rust which still pop up every once in a while in some of our basic system tools.
- agumonkey 8y ago
  I guess porting something you know in a new language is one problem less.
kome 8y ago
because people want to learn and practice...
yoz-y 8y ago
"If people did not reinvent the wheel we would be still rolling around on wooden logs" I for one am very happy with tools such as ripgrep and fd which are more or less just rewrites of decades old programs but are much faster and have generally better though out interfaces.
- vram22 8y ago
  >"If people did not reinvent the wheel we would be still rolling around on wooden logs" Or doing this: https://jugad2.blogspot.com/2015/07/no-thanks-we-are-too-busy.html https://jugad2.blogspot.com/2015/07/no-thanks-we-are-too-bus...
jdub 8y ago
Besides the fact that these are great exercises, often enough they also demonstrate solutions that are now possible thanks to Rust. e.g. ripgrep is faster and makes better use of available hardware (concurrency, SIMD) than grep – thanks to Rust.
- madmax96 8y ago
  >they also demonstrate solutions that are now possible thanks to Rust This seems specious. If I started a grep implementation from scratch in C{,++}, it isn't clear to me that I couldn't achieve the same (or better) results as ripgrep. Comparing a totally rewritten program to one designed decades ago and concluding 'without Rust, we wouldn't have this faster program with better hardware use' doesn't seem quite right.
  - burntsushi 8y ago
    You are right. You could. I've said as much numerous times in the past, but this doesn't unfortunately stop folks from saying that the performance difference is directly attributable to Rust. The performance difference is primarily attributable to algorithms. I have, though, said in the past that I wouldn't have written ripgrep without Rust, which is a very different claim and is opinionated, and mostly a statement about developer productivity and maintenance burden. With Rust, it is very easy to keep ripgrep's trains running across Windows, macOS and Linux.
baq 8y ago
never written 'hello world' before? got to learn the tool before you can solve previously unsolved problems
Dowwie 8y ago
Have you used these command line utilities yet? They're great! Exa, ripgrep, fd, bat, broot, ruplacer And more...
- nurettin 8y ago
  I did try rip "grep". rg "^SECRET" Find nothing. Try to contact someone who is asleep for half an hour, then they tell me they put it in there. grep -r "^SECRET" . yep, it is there, in an .env file. "Uhh yeah sorry I was using ripgrep and it doesn't search hidden files by default but it has a flag for it" "you wut?" "nevermind, thanks bye." <- that is ripgrep. Maybe we got off on the wrong foot. Anyway thanks for listing all the tools you're great.
  - StavrosK 8y ago
    It does search hidden files, it doesn't search gitignored files. Why are you assuming it's identical to grep?
    - nurettin 8y ago
      Have you installed it? nurettin@ ~ () $ mkdir test nurettin@ ~ () $ echo "TEST SOMETHING" > test/.env nurettin@ ~ () $ cd test nurettin@ ~/test () $ rg "TEST" Why I don't know, because it has grep in the name? Do you now realize where the confusion might be lying?
      - burntsushi 8y ago
        This is part the whole point of ripgrep. If you don't want it to do smart filtering, then you either alias `rg="rg -uu"` or just use grep if it's fast enough for you. Some people might miss this, yes. That's why it's mentioned in the first couple sentences of the man page.
        nurettin 8y ago
        RTFM is an important thing we remind to eachother in order to reach for our own knowledge instead of relying upon others to give it to us. And yes, this most important bit of information is in the man page and the help text, but not at the top of the page people who came to actually download the tool will look first. Which is `https://github.com/burntsushi/ripgrep` https://github.com/burntsushi/ripgrep` .
AboutTheWhisles 8y ago
I don't think there is anything that Rust can do technically that wasn't possible before. I think it's benefits are more about implicit organization.
- steveklabnik 8y ago
  It depends on exactly what you mean. In some sense, yes. It's still all assembly at the end. But, there's some claims about what's realistically possible, rather than theoretically possible. For example, Stylo was attempted in C++ twice, and both times, it failed. The complexity was too much, and there were too many bugs. The Rust attempt succeeded on the first try. shared_ptr's implementation in gcc's libstdc++ uses a heuristic to try and determine if it should use atomics or not. In my understanding, this was done because they were really worried about bugs when people chose the wrong one. Rust has a clean, compile-time checked separation between Arc<T> and Rc<T>. These kinds of claims are much more interesting to me personally.
  - AboutTheWhisles 8y ago
    I'm not sure an anecdote about about a software project failing twice and succeeding on a third try can be used as evidence the the language of the third try enabled something to be pragmatically possible. I'm sure rust helped, but I'm also very confident that I could architect even a large scale project in C++ well enough that it would remain modular and progress could remain steady.
    - steveklabnik 8y ago
      The team said it, not me. (I realize I didn’t make that clear before) There was a talk at a Rust conference about it in detail. Modularity was not the issue. Complexity combined with concurrency was. Rust’s compile time checks was what made it feasible to be so aggressive without the bugs.
      - AboutTheWhisles 8y ago
        I was already assuming that concurrency was a big part of that statement. I respect Rust's attempt to solve these issues at the language level, but my experience has led me to think that they need to be solved at the architectural level of a program. As far as I can tell, concurrency is fundamentally about grouping data by dependencies to find chunks that can be isolated. I think that resources are more about lifetimes and ownership and that resources and data aren't the same thing. This doesn't contradict what Rust is doing, it is more about relying on the language less. You can see what I'm talking about in this link, though I don't think it has been digestible enough yet without video or examples. https://github.com/LiveAsynchronousVisualizedArchitecture/lava https://github.com/LiveAsynchronousVisualizedArchitecture/la... https://github.com/LiveAsynchronousVisualizedArchitecture/lava/blob/master/Overview.md https://github.com/LiveAsynchronousVisualizedArchitecture/la...
fnord123 8y ago
Consider GNU AWK. Part of AWK is regular expression compiling. GNU AWK periodically copy-pastes regular expression handling from GNU grep instead of depending on it like a library. It's ridiculous.

Why do "convert everything to rust" people appear to prefer solving already solved problems instead of focusing on problems we could not solve but are now possible thanks to Rust?

pests 8y ago

Guess we should all just stop doing anything then.

empath75 8y ago

If you’re learning a language, reimplementing something that’s already been solved is a fairly standard learning exercise.

carlmr 8y ago

Apart from the aspect that you're new to a language and just want to learn something you might make an improved version. ripgrep is a Rust version of grep. It's the fastest grep I know and it has better Unicode support than GNU grep (because of Rust language decisions). Looking at memory safety and portability it might also be a good idea to program them in Rust. There are whole classes of bugs that are excluded in Rust which still pop up every once in a while in some of our basic system tools.

agumonkey 8y ago
I guess porting something you know in a new language is one problem less.

kome 8y ago

because people want to learn and practice...

yoz-y 8y ago

"If people did not reinvent the wheel we would be still rolling around on wooden logs" I for one am very happy with tools such as ripgrep and fd which are more or less just rewrites of decades old programs but are much faster and have generally better though out interfaces.

vram22 8y ago
>"If people did not reinvent the wheel we would be still rolling around on wooden logs" Or doing this: https://jugad2.blogspot.com/2015/07/no-thanks-we-are-too-busy.html https://jugad2.blogspot.com/2015/07/no-thanks-we-are-too-bus...

jdub 8y ago

Besides the fact that these are great exercises, often enough they also demonstrate solutions that are now possible thanks to Rust. e.g. ripgrep is faster and makes better use of available hardware (concurrency, SIMD) than grep – thanks to Rust.

madmax96 8y ago
>they also demonstrate solutions that are now possible thanks to Rust This seems specious. If I started a grep implementation from scratch in C{,++}, it isn't clear to me that I couldn't achieve the same (or better) results as ripgrep. Comparing a totally rewritten program to one designed decades ago and concluding 'without Rust, we wouldn't have this faster program with better hardware use' doesn't seem quite right.
- burntsushi 8y ago
  You are right. You could. I've said as much numerous times in the past, but this doesn't unfortunately stop folks from saying that the performance difference is directly attributable to Rust. The performance difference is primarily attributable to algorithms. I have, though, said in the past that I wouldn't have written ripgrep without Rust, which is a very different claim and is opinionated, and mostly a statement about developer productivity and maintenance burden. With Rust, it is very easy to keep ripgrep's trains running across Windows, macOS and Linux.

baq 8y ago

never written 'hello world' before? got to learn the tool before you can solve previously unsolved problems

Dowwie 8y ago

Have you used these command line utilities yet? They're great! Exa, ripgrep, fd, bat, broot, ruplacer And more...

nurettin 8y ago
I did try rip "grep". rg "^SECRET" Find nothing. Try to contact someone who is asleep for half an hour, then they tell me they put it in there. grep -r "^SECRET" . yep, it is there, in an .env file. "Uhh yeah sorry I was using ripgrep and it doesn't search hidden files by default but it has a flag for it" "you wut?" "nevermind, thanks bye." <- that is ripgrep. Maybe we got off on the wrong foot. Anyway thanks for listing all the tools you're great.
- StavrosK 8y ago
  It does search hidden files, it doesn't search gitignored files. Why are you assuming it's identical to grep?
  - nurettin 8y ago
    Have you installed it? nurettin@ ~ () $ mkdir test nurettin@ ~ () $ echo "TEST SOMETHING" > test/.env nurettin@ ~ () $ cd test nurettin@ ~/test () $ rg "TEST" Why I don't know, because it has grep in the name? Do you now realize where the confusion might be lying?
    - burntsushi 8y ago
      This is part the whole point of ripgrep. If you don't want it to do smart filtering, then you either alias `rg="rg -uu"` or just use grep if it's fast enough for you. Some people might miss this, yes. That's why it's mentioned in the first couple sentences of the man page.
      - nurettin 8y ago
        RTFM is an important thing we remind to eachother in order to reach for our own knowledge instead of relying upon others to give it to us. And yes, this most important bit of information is in the man page and the help text, but not at the top of the page people who came to actually download the tool will look first. Which is `https://github.com/burntsushi/ripgrep` https://github.com/burntsushi/ripgrep` .

AboutTheWhisles 8y ago

I don't think there is anything that Rust can do technically that wasn't possible before. I think it's benefits are more about implicit organization.

steveklabnik 8y ago
It depends on exactly what you mean. In some sense, yes. It's still all assembly at the end. But, there's some claims about what's realistically possible, rather than theoretically possible. For example, Stylo was attempted in C++ twice, and both times, it failed. The complexity was too much, and there were too many bugs. The Rust attempt succeeded on the first try. shared_ptr's implementation in gcc's libstdc++ uses a heuristic to try and determine if it should use atomics or not. In my understanding, this was done because they were really worried about bugs when people chose the wrong one. Rust has a clean, compile-time checked separation between Arc<T> and Rc<T>. These kinds of claims are much more interesting to me personally.
- AboutTheWhisles 8y ago
  I'm not sure an anecdote about about a software project failing twice and succeeding on a third try can be used as evidence the the language of the third try enabled something to be pragmatically possible. I'm sure rust helped, but I'm also very confident that I could architect even a large scale project in C++ well enough that it would remain modular and progress could remain steady.
  - steveklabnik 8y ago
    The team said it, not me. (I realize I didn’t make that clear before) There was a talk at a Rust conference about it in detail. Modularity was not the issue. Complexity combined with concurrency was. Rust’s compile time checks was what made it feasible to be so aggressive without the bugs.
    - AboutTheWhisles 8y ago
      I was already assuming that concurrency was a big part of that statement. I respect Rust's attempt to solve these issues at the language level, but my experience has led me to think that they need to be solved at the architectural level of a program. As far as I can tell, concurrency is fundamentally about grouping data by dependencies to find chunks that can be isolated. I think that resources are more about lifetimes and ownership and that resources and data aren't the same thing. This doesn't contradict what Rust is doing, it is more about relying on the language less. You can see what I'm talking about in this link, though I don't think it has been digestible enough yet without video or examples. https://github.com/LiveAsynchronousVisualizedArchitecture/lava https://github.com/LiveAsynchronousVisualizedArchitecture/la... https://github.com/LiveAsynchronousVisualizedArchitecture/lava/blob/master/Overview.md https://github.com/LiveAsynchronousVisualizedArchitecture/la...

fnord123 8y ago

Consider GNU AWK. Part of AWK is regular expression compiling. GNU AWK periodically copy-pastes regular expression handling from GNU grep instead of depending on it like a library. It's ridiculous.