6 ms·

Rust and Go are languages with ecosystems, in which writing everything in a cross-platform way is the default. They also compile to a single statically linked b

Rust and Go are languages with ecosystems, in which writing everything in a cross-platform way is the default. They also compile to a single statically linked binary. You don't need an additional runtime + load of dependencies like node or python. They are lightweight and fast to start up as opposed to the jvm.

shawn 8y ago
Python is installed literally everywhere. If it’s a CLI tool, and it’s written in python, the chance that it won’t work is slim. Go has a massive number of problems. For example, I tried to run Keybase’s standard “go get” build instructions. It failed with 200 import errors. That was the end of my attempt to install keybase on my raspberry pi. Others had said that it works. Rust requires a massive amount of hard drive space and takes a long time to build. You also have to build it. That’s antithetical to rapid development. I can't wait until the pendulum swings back away from static typing and the next generation of programmers discover the benefits of literally ignoring everybody and doing your own thing. It’ll be painful, but at least it’ll be effective. And you won’t have to compile anything.
- cube2222 8y ago
  You don't need to go get or install the rust sdk if you just download the small, statically linked binary.
  - shawn 8y ago
    There is no such binary for the raspberry pi. If it was written in python, it would have worked. It likely would have turned out smaller, too.
    - burntsushi 8y ago
      xsv doesn't exist if it was written in Python. It would definitively be too slow. If you don't care about performance and would rather not wait a couple minutes to build the tool on your Pi, then go use csvkit, which is written in Python. The availability of software isn't a zero sum game.
      - shawn 8y ago
        Ohhh, you wanna throw down eh? Hmmm. This would be a fun weekend project to reimplement XSV in Python and prove this wrong. :) Now, to make this a fair comparison, are you excluding pypy? Or is that allowed for our game? How about LuaJIT or Node? Are those fair too?
        sanderjd 8y ago
        You should definitely do this. Personally, I strongly suspect you wouldn't prove him wrong if you did attempt this in any of the languages you mentioned. But if you're right and we're wrong, I'd love it! It would be great and eye-opening to dig into your implementation(s) to see how you pulled it off.
        JoshTriplett 8y ago
        > This would be a fun weekend project to reimplement XSV in Python and prove this wrong. I don't know as much about the internals or performance characteristics of XSV (though it certainly touts performance as a feature), but if you can reimplement ripgrep in Python and get anywhere close to the same performance, I'd certainly be interested to see that. > Now, to make this a fair comparison, are you excluding pypy? Or is that allowed for our game? PyPy is not available everywhere, unlike the CPython runtime or the ability to run compiled binaries.
        burntsushi 8y ago
        I would definitely love to be proven wrong, because if I am, I am certain I would learn something new. I am pretty comfortable with Python, so I am pretty comfortable saying that you could not write a tool as fast as xsv in Python without writing some substantial portion of it in C. Using Python's standard library CSV parser is certainly fair game, but writing more C code on top of that which included the loop over records in a CSV file feels like a cheat. The problem here is that you've already lost because xsv's CSV parser is faster than Python's parser at the C level[1]. :-) Assuming I haven't made any silly gaffes in xsv itself, I don't see how you're going to make up the difference. Because of that, I am willing to extend a handicap: if you can get within the same order of magnitude as xsv while doing the same amount of work in a robust way, then I think I might even learn something there too. :-) I am less certain about PyPy, LuaJIT or Node, but I am certain I'd learn something if you proved me wrong. Note that a problematic part of this challenge is that your program would need to correctly handle CSV in a robust manner. It is very easy to write a very fast CSV parser that doesn't correctly handle all of the corner cases. Python's CSV parser certainly passes that test, but I don't know if Node's or Lua's CSV parser does because I've never used them. [1] - https://github.com/BurntSushi/rust-csv/blob/master/csv-core/src/reader.rs https://github.com/BurntSushi/rust-csv/blob/master/csv-core/...
- h1d 8y ago
  > Python is installed literally everywhere. I figured Ubuntu 18.04 didn't have Python pre installed. Besides, installing all the dependencies with pip is another step to do and gets annoying when deploying to many servers. For something that gets distributed, a single static binary is very welcomed.
  - ptman 8y ago
    I think it has python 3, but not python 2
- mmirate 8y ago
  Which Python? 2 or 3?
- GordonS 8y ago
  > Python is installed literally everywhere Nope, not on Windows.
colanderman 8y ago
Everything you said applies to many other languages, including C, which is probably the most common language used to write CLIs if you rank by hours used. Why not advertise the unique properties of this tool (fast, easy to install) than its implementation language? Does this ultimately boil down to "go install" (or whatever the Rust equivalent is) is easier to deal with than "./configure; make"? Maybe I'm just a curmudgeon and don't understand why it seems to be in vogue to ignore OS package managers, which hide all this complexity anyway.
- leshow 8y ago
  I think the tools speak for themselves. They get use and then they get included in repos, not just by virtue of the fact they were written in lang X.
  - colanderman 8y ago
    Then why advertise that? Why not advertise their benefits instead (fast, cross-platform, easy install)? "Written in X" is only useful to advertise pedagogy or integration.
    - mmirate 8y ago
      Shorthand. Compare the lengths of these two strings: > fast, cross-platform, easy install > Written in Rust Also note how the second statement expresses a single concept; whereas the first statement is a list of concepts that must be memorized and reproduced by rote, and is therefore constantly at-risk of being stated incompletely or inaccurately. (And it is incomplete: there are many more reasons why "Written in Rust" might be important, such as correctness, security, and ease of maintenance/refactoring.) * * * * * Alternatively: why convey a set of vague descriptors when you can instead convey precisely why they are applicable, and let the audience's pre-existing memories fill in the details for them?
      - colanderman 8y ago
        Like I said, "written in X" conveys pedagogy and integration. (Or, if we're being cynical, hip language clickbait.) It's not a very good shorthand.
GyYZTfWBfQw 8y ago
I have had more problems with pip, go, and cargo, than pacman and ./configure && make && make install. I don't know what you are on about.

shawn 8y ago

Python is installed literally everywhere. If it’s a CLI tool, and it’s written in python, the chance that it won’t work is slim. Go has a massive number of problems. For example, I tried to run Keybase’s standard “go get” build instructions. It failed with 200 import errors. That was the end of my attempt to install keybase on my raspberry pi. Others had said that it works. Rust requires a massive amount of hard drive space and takes a long time to build. You also have to build it. That’s antithetical to rapid development. I can't wait until the pendulum swings back away from static typing and the next generation of programmers discover the benefits of literally ignoring everybody and doing your own thing. It’ll be painful, but at least it’ll be effective. And you won’t have to compile anything.

cube2222 8y ago
You don't need to go get or install the rust sdk if you just download the small, statically linked binary.
- shawn 8y ago
  There is no such binary for the raspberry pi. If it was written in python, it would have worked. It likely would have turned out smaller, too.
  - burntsushi 8y ago
    xsv doesn't exist if it was written in Python. It would definitively be too slow. If you don't care about performance and would rather not wait a couple minutes to build the tool on your Pi, then go use csvkit, which is written in Python. The availability of software isn't a zero sum game.
    - shawn 8y ago
      Ohhh, you wanna throw down eh? Hmmm. This would be a fun weekend project to reimplement XSV in Python and prove this wrong. :) Now, to make this a fair comparison, are you excluding pypy? Or is that allowed for our game? How about LuaJIT or Node? Are those fair too?
      - sanderjd 8y ago
        You should definitely do this. Personally, I strongly suspect you wouldn't prove him wrong if you did attempt this in any of the languages you mentioned. But if you're right and we're wrong, I'd love it! It would be great and eye-opening to dig into your implementation(s) to see how you pulled it off.
      - JoshTriplett 8y ago
        > This would be a fun weekend project to reimplement XSV in Python and prove this wrong. I don't know as much about the internals or performance characteristics of XSV (though it certainly touts performance as a feature), but if you can reimplement ripgrep in Python and get anywhere close to the same performance, I'd certainly be interested to see that. > Now, to make this a fair comparison, are you excluding pypy? Or is that allowed for our game? PyPy is not available everywhere, unlike the CPython runtime or the ability to run compiled binaries.
      - burntsushi 8y ago
        I would definitely love to be proven wrong, because if I am, I am certain I would learn something new. I am pretty comfortable with Python, so I am pretty comfortable saying that you could not write a tool as fast as xsv in Python without writing some substantial portion of it in C. Using Python's standard library CSV parser is certainly fair game, but writing more C code on top of that which included the loop over records in a CSV file feels like a cheat. The problem here is that you've already lost because xsv's CSV parser is faster than Python's parser at the C level[1]. :-) Assuming I haven't made any silly gaffes in xsv itself, I don't see how you're going to make up the difference. Because of that, I am willing to extend a handicap: if you can get within the same order of magnitude as xsv while doing the same amount of work in a robust way, then I think I might even learn something there too. :-) I am less certain about PyPy, LuaJIT or Node, but I am certain I'd learn something if you proved me wrong. Note that a problematic part of this challenge is that your program would need to correctly handle CSV in a robust manner. It is very easy to write a very fast CSV parser that doesn't correctly handle all of the corner cases. Python's CSV parser certainly passes that test, but I don't know if Node's or Lua's CSV parser does because I've never used them. [1] - https://github.com/BurntSushi/rust-csv/blob/master/csv-core/src/reader.rs https://github.com/BurntSushi/rust-csv/blob/master/csv-core/...
h1d 8y ago
> Python is installed literally everywhere. I figured Ubuntu 18.04 didn't have Python pre installed. Besides, installing all the dependencies with pip is another step to do and gets annoying when deploying to many servers. For something that gets distributed, a single static binary is very welcomed.
- ptman 8y ago
  I think it has python 3, but not python 2
mmirate 8y ago
Which Python? 2 or 3?
GordonS 8y ago
> Python is installed literally everywhere Nope, not on Windows.

colanderman 8y ago

Everything you said applies to many other languages, including C, which is probably the most common language used to write CLIs if you rank by hours used. Why not advertise the unique properties of this tool (fast, easy to install) than its implementation language? Does this ultimately boil down to "go install" (or whatever the Rust equivalent is) is easier to deal with than "./configure; make"? Maybe I'm just a curmudgeon and don't understand why it seems to be in vogue to ignore OS package managers, which hide all this complexity anyway.

leshow 8y ago
I think the tools speak for themselves. They get use and then they get included in repos, not just by virtue of the fact they were written in lang X.
- colanderman 8y ago
  Then why advertise that? Why not advertise their benefits instead (fast, cross-platform, easy install)? "Written in X" is only useful to advertise pedagogy or integration.
  - mmirate 8y ago
    Shorthand. Compare the lengths of these two strings: > fast, cross-platform, easy install > Written in Rust Also note how the second statement expresses a single concept; whereas the first statement is a list of concepts that must be memorized and reproduced by rote, and is therefore constantly at-risk of being stated incompletely or inaccurately. (And it is incomplete: there are many more reasons why "Written in Rust" might be important, such as correctness, security, and ease of maintenance/refactoring.) * * * * * Alternatively: why convey a set of vague descriptors when you can instead convey precisely why they are applicable, and let the audience's pre-existing memories fill in the details for them?
    - colanderman 8y ago
      Like I said, "written in X" conveys pedagogy and integration. (Or, if we're being cynical, hip language clickbait.) It's not a very good shorthand.

GyYZTfWBfQw 8y ago

I have had more problems with pip, go, and cargo, than pacman and ./configure && make && make install. I don't know what you are on about.