5 ms·

Looks cool! Any non-ruby alternatives with similar features?

by gear54rus 11y ago

skrebbel 11y ago
Why?
- giancarlostoro 11y ago
  From my own experience: Sometimes installing an entire programming language just to use one tool is not worth the time I could possibly waste just trying to figure out how to get it working (assuming it works). Instead looking for alternatives built around tech that's already available in my system makes more sense to me, because of a higher chance of familiarity and the benefit of less time possibly wasted. There's also the curiosity of wanting to see the project implemented in a language you're familiar with.
  - rmetzler 11y ago
    > Sometimes installing an entire programming language just to use one tool is not worth the time I could possibly waste just trying to figure out how to get it working (assuming it works). That's why I would love to see more Docker containers and docker-compose.yaml files for tools shared on HN. A Docker container for this would be super simple to build using an official Ruby Docker container and it would save so much time for anyone who wants to try the tool.
    - corobo 11y ago
      Docker for a command line tool? I thought docker was more for your public facing service sort of thing. Does it even have a full on terminal, being a container? I'll be honest I've not been keeping up with Docker. It shows, right?
      - jonesetc 11y ago
        -t when running a docker container allocates a pseudo-tty. Docker is useful for trying out cli interpreters like this, iojs, or any thing else of the sort. I wouldn't want to use docker if I planned on keeping it around to use more than a couple of times though.
      - xj9 11y ago
        A Docker container is like chroot, but portable. So yes. You can do docker exec -it $NAME /bin/bash to get a shell in a running container, or docker run --rm -it $NAME /bin/bash to get a shell in a new container that will remove itself upon exit. Neither of these require your docker host to be local.
    - archimedespi 11y ago
      I'm so sick of people wanting to package literally everything as a Docker container. That assumes: - You're running Linux (or have access to a Linux box) - The box running Linux is x86_64 - You have a modern kernel set up - The box has a bunch of ram - The box has a bunch of disk space (for installing Docker) Docker forces you to have modern Intel-based hardware. Which excludes people with stuff like the Novena[1] or an old Thinkpad (because 32bits). - [1]: https://www.crowdsupply.com/sutajio-kosagi/novena https://www.crowdsupply.com/sutajio-kosagi/novena
  - IgorPartola 11y ago
    This is why I advocate that software authors package their software for a variety of OS's in their native format. Yes, technically anyone can use Ruby gems or Python eggs or wheels or whatever Go calls their packages, but practically if I can apt-get/brew/emerge/rpm your package, I don't care what language it is written in. It is more effort but it makes a big difference in adoption IMO.
    - fizzbatter 11y ago
      > whatever Go calls their packages Just fyi, but go doesn't have packages (in this context). Just native binaries with no dependencies.
      - IgorPartola 11y ago
        Well, it has `go get foo` which I'd consider a kind of installer/package manager. That's what I'm referring to since I've seen a good chunk of Go software distributed this way. The README usually says "install Go, then run `go get foo`". Edit: in fact https://golang.org/doc/code.html https://golang.org/doc/code.html refers to this as "Remote packages".
        fizzbatter 11y ago
        That's fair - i just make the distinction because there's a difference, imo. In the case of `go get`, there is no preconfigured package, it's akin to a pull and make. Because of that, `go get` tends to be targeted at Go developers. Unlike Python/Ruby/etc, typically only Go developers have the Go compiler at hand. I mean, i'm in a similar camp with the OP (that you replied to), i don't like installing a runtime just for a specific package. But i typically look at projects that use Ruby as targeted for Ruby developers - not me. Go is slightly different though, because the compiler is mainly for developers. You don't have to know what Go is to run a "Go binary". So, it's worth an asterisk. That's all i meant :)
        slrz 11y ago
        Go get is a thin wrapper around git/hg/cvs/whatever. It's supposed to be used by developers, not end users. Note that your link is titled "How to write Go code". For distribution to end users just do whatever you'd do for a program written in C/C++/Java/Erlang/whatever. No need to rub your favorite programming language into your users' face constantly. But yeah, there's a bunch of Go programmers (presumably those coming from Python or Ruby) that don't really seem to get that you don't need to put source code and a compiler onto your production servers.
- a3n 11y ago
  I get sad when I see a ruby tool, and don't bother. I'm lazy. The ones I've tried have been dependant on a specific version of ruby. So you have to work through that. I'm not a resident of the ruby ecosystem, and I don't want to figure out the "why didn't you just" method of managing that. As the saying goes, it's hard to remember your objective was to drain the swamp when you're up to your ass in alligators. IIRC, vagrant just includes the version of ruby it depends on. Or maybe it just includes a ruby in case you don't have one. I like and use vagrant.
- slrz 11y ago
  Well, I've never encountered an ecosystem before where it is so totally painful to install and maintain programs coming from there. It's not necessarily the language but the community mindset that doesn't seem to care one tiny bit about backwards compatibility. Say I want to run two programs an a server, both written in Ruby. Those programs depend on a bunch of libraries. Ok, so I go on and just install those libraries. WRONG. The programs need specific versions of those libraries (both of which differ from the one coming with my Linux distro) and there's no single library version that works with both of them. To make things worse, one program needs a different version of the Ruby interpreter than the other. Only one of those is included in the Linux distribution I'm running. So instead of being able to (at least partially) rely on the maintenance done by my Linux distro, I'd have to maintain my own Ruby interpreters and libraries. Yeah, right. For that reason I consider running Ruby programs a liability. Sure, you have to deal with stuff like that everywhere but I never encountered an ecosystem where things are that bad and things break with any other update. I've heard the Javascript/Node people do an equally crappy job but I'm not going to find out personally. So while I saw a couple of quite nice things written in Ruby, we're not going to use them if their maintenance is such a pain.
martiuk 11y ago
I use HTTPie which is similar and easily installed through pip. https://github.com/jkbrzt/httpie https://github.com/jkbrzt/httpie
- archimedespi 11y ago
  HTTPie looks awesome, thanks for the tip!
ams6110 11y ago
curl in verbose mode.
zobby 11y ago
a web browser and hitting f12 and any plugin you want
blacksmith_tb 11y ago
I like httpie a lot personally, but I have also used Bat (if you like Go better than Ruby or Python) https://github.com/astaxie/bat https://github.com/astaxie/bat
- fizzbatter 11y ago
  Really cool, appreciate the link!
prakashk 11y ago
WWW::Mechanize::Shell (https://metacpan.org/pod/WWW::Mechanize::Shell https://metacpan.org/pod/WWW::Mechanize::Shell)
mato 11y ago
telnet?

Looks cool! Any non-ruby alternatives with similar features?

skrebbel 11y ago

Why?

giancarlostoro 11y ago
From my own experience: Sometimes installing an entire programming language just to use one tool is not worth the time I could possibly waste just trying to figure out how to get it working (assuming it works). Instead looking for alternatives built around tech that's already available in my system makes more sense to me, because of a higher chance of familiarity and the benefit of less time possibly wasted. There's also the curiosity of wanting to see the project implemented in a language you're familiar with.
- rmetzler 11y ago
  > Sometimes installing an entire programming language just to use one tool is not worth the time I could possibly waste just trying to figure out how to get it working (assuming it works). That's why I would love to see more Docker containers and docker-compose.yaml files for tools shared on HN. A Docker container for this would be super simple to build using an official Ruby Docker container and it would save so much time for anyone who wants to try the tool.
  - corobo 11y ago
    Docker for a command line tool? I thought docker was more for your public facing service sort of thing. Does it even have a full on terminal, being a container? I'll be honest I've not been keeping up with Docker. It shows, right?
    - jonesetc 11y ago
      -t when running a docker container allocates a pseudo-tty. Docker is useful for trying out cli interpreters like this, iojs, or any thing else of the sort. I wouldn't want to use docker if I planned on keeping it around to use more than a couple of times though.
    - xj9 11y ago
      A Docker container is like chroot, but portable. So yes. You can do docker exec -it $NAME /bin/bash to get a shell in a running container, or docker run --rm -it $NAME /bin/bash to get a shell in a new container that will remove itself upon exit. Neither of these require your docker host to be local.
  - archimedespi 11y ago
    I'm so sick of people wanting to package literally everything as a Docker container. That assumes: - You're running Linux (or have access to a Linux box) - The box running Linux is x86_64 - You have a modern kernel set up - The box has a bunch of ram - The box has a bunch of disk space (for installing Docker) Docker forces you to have modern Intel-based hardware. Which excludes people with stuff like the Novena[1] or an old Thinkpad (because 32bits). - [1]: https://www.crowdsupply.com/sutajio-kosagi/novena https://www.crowdsupply.com/sutajio-kosagi/novena
- IgorPartola 11y ago
  This is why I advocate that software authors package their software for a variety of OS's in their native format. Yes, technically anyone can use Ruby gems or Python eggs or wheels or whatever Go calls their packages, but practically if I can apt-get/brew/emerge/rpm your package, I don't care what language it is written in. It is more effort but it makes a big difference in adoption IMO.
  - fizzbatter 11y ago
    > whatever Go calls their packages Just fyi, but go doesn't have packages (in this context). Just native binaries with no dependencies.
    - IgorPartola 11y ago
      Well, it has `go get foo` which I'd consider a kind of installer/package manager. That's what I'm referring to since I've seen a good chunk of Go software distributed this way. The README usually says "install Go, then run `go get foo`". Edit: in fact https://golang.org/doc/code.html https://golang.org/doc/code.html refers to this as "Remote packages".
      - fizzbatter 11y ago
        That's fair - i just make the distinction because there's a difference, imo. In the case of `go get`, there is no preconfigured package, it's akin to a pull and make. Because of that, `go get` tends to be targeted at Go developers. Unlike Python/Ruby/etc, typically only Go developers have the Go compiler at hand. I mean, i'm in a similar camp with the OP (that you replied to), i don't like installing a runtime just for a specific package. But i typically look at projects that use Ruby as targeted for Ruby developers - not me. Go is slightly different though, because the compiler is mainly for developers. You don't have to know what Go is to run a "Go binary". So, it's worth an asterisk. That's all i meant :)
      - slrz 11y ago
        Go get is a thin wrapper around git/hg/cvs/whatever. It's supposed to be used by developers, not end users. Note that your link is titled "How to write Go code". For distribution to end users just do whatever you'd do for a program written in C/C++/Java/Erlang/whatever. No need to rub your favorite programming language into your users' face constantly. But yeah, there's a bunch of Go programmers (presumably those coming from Python or Ruby) that don't really seem to get that you don't need to put source code and a compiler onto your production servers.
a3n 11y ago
I get sad when I see a ruby tool, and don't bother. I'm lazy. The ones I've tried have been dependant on a specific version of ruby. So you have to work through that. I'm not a resident of the ruby ecosystem, and I don't want to figure out the "why didn't you just" method of managing that. As the saying goes, it's hard to remember your objective was to drain the swamp when you're up to your ass in alligators. IIRC, vagrant just includes the version of ruby it depends on. Or maybe it just includes a ruby in case you don't have one. I like and use vagrant.
slrz 11y ago
Well, I've never encountered an ecosystem before where it is so totally painful to install and maintain programs coming from there. It's not necessarily the language but the community mindset that doesn't seem to care one tiny bit about backwards compatibility. Say I want to run two programs an a server, both written in Ruby. Those programs depend on a bunch of libraries. Ok, so I go on and just install those libraries. WRONG. The programs need specific versions of those libraries (both of which differ from the one coming with my Linux distro) and there's no single library version that works with both of them. To make things worse, one program needs a different version of the Ruby interpreter than the other. Only one of those is included in the Linux distribution I'm running. So instead of being able to (at least partially) rely on the maintenance done by my Linux distro, I'd have to maintain my own Ruby interpreters and libraries. Yeah, right. For that reason I consider running Ruby programs a liability. Sure, you have to deal with stuff like that everywhere but I never encountered an ecosystem where things are that bad and things break with any other update. I've heard the Javascript/Node people do an equally crappy job but I'm not going to find out personally. So while I saw a couple of quite nice things written in Ruby, we're not going to use them if their maintenance is such a pain.

martiuk 11y ago

I use HTTPie which is similar and easily installed through pip. https://github.com/jkbrzt/httpie https://github.com/jkbrzt/httpie

archimedespi 11y ago
HTTPie looks awesome, thanks for the tip!

ams6110 11y ago

curl in verbose mode.

zobby 11y ago

a web browser and hitting f12 and any plugin you want

blacksmith_tb 11y ago

I like httpie a lot personally, but I have also used Bat (if you like Go better than Ruby or Python) https://github.com/astaxie/bat https://github.com/astaxie/bat

fizzbatter 11y ago
Really cool, appreciate the link!

prakashk 11y ago

WWW::Mechanize::Shell (https://metacpan.org/pod/WWW::Mechanize::Shell https://metacpan.org/pod/WWW::Mechanize::Shell)

mato 11y ago

telnet?