Serious question. I'm not trolling or shitting on guys that use Go or Rust for everything.


Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043

Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043

Warning: Attempt to read property "comment_date" on null in /var/www/wptbox/wp-includes/comment-template.php on line 1043

Serious question. I'm not trolling or shitting on guys that use Go or Rust for everything. Why would I bother writing a CLI tool in something like Go or Rust when I can use Node or Deno instead?

With Node, I have access to a wider ecosystem and can implement a c++ addon anyway. It is also possible to implement a really comfortable plugin architecture, so users of your tool can customize it and add functionality without needing to recompile or try to push code upstream. For example, look at these two tools: Jekyll and Hugo. Both are static site generators. With Jekyll, you can write some ruby and stick it in a directory, and it gets picked up by some hooks when Jekyll runs a command. Hugo supports no such thing. I don't think this is possible with a compiled language.

Second argument is speed. Node is probably the greatest balance between fast and widely used. It is faster than Ruby and Python.

Third argument, code reuse. If I do write a useful tool with Node, I can easily import and embed that code in another application -- maybe a desktop app with Electron or a mobile app with React Native, or maybe I want to use the tool on the backend of some website. It seems like the perfect choice for this kind of work, so why not?

  1. 3 months ago
    Anonymous

    Does Node produce standalone binaries ever?
    >faster than Ruby and Python
    This is not a great accomplishment.
    >Jekyll supports plugins, Hugo doesn’t
    Fair cop. I added the function I wanted to Hugo proper. Writing reflection-heavy code was not pleasant.
    >code reuse
    I struggle to see how bat or fzf can usefully be integrated into some kind of website frontend. dart-sass is a different story.

    • 3 months ago
      Anonymous

      >I struggle to see how bat or fzf can usefully be integrated into some kind of website frontend.
      I agree, but many use cases do exist. Have you ever used the website transform.tools before? that is what I'm talking about, it is essentially just a website that wraps a smaller CLI utility. This could be accomplished with RPC but not as elegant.

  2. 3 months ago
    Anonymous

    no serious person would ever use or contribute to a CLI tool written in node.js

    they would rewrite it in Go with 10x less code and 10x simpler and 10x faster

    • 3 months ago
      Anonymous

      You are being completely disingenuous. Do you have any actual point or are you just spamming threads and wasting time?

      • 3 months ago
        Anonymous

        I think Go is utter rubbish, but he's got a heck of a lot better point than you or OP.

        • 3 months ago
          Anonymous

          Sounds good, tim.

      • 3 months ago
        Anonymous

        sure... in javascript everything is some weird callback hell of asynchronous promises and your build breaks then the "odd" package is replaced by a malicious NPM user. And then it breaks again when some package throws a totally unexpected exception and you need to update your tool *AGAIN*.

        In Go they have an obssessive focus on backwards compatibility so your tool you wrote once will compile to bytecode and run blazing fast for all eternity. And you will have handled every possible error case possible because errors are a first class citizen of the language and you are instantly warned if you ever forget to handle a single case. And your source code will look EXACTLY the same as every other Go codebase, since the language was designed with simplicity and consistency in mind.

        • 3 months ago
          Anonymous

          I think those are valid points. Why didn't you just include those to begin with? I do have a few points though.

          >your build breaks then the "odd" package is replaced by a malicious NPM user.
          Your build should not be breaking at all if you are pinning your dependencies. Supply chain attacks are common across all programming languages with a supply chain to attack, but I do agree that Node suffers the most. You need to mitigate this by pinning your dependencies and upgrading in a test environment. The package-lock.json file exists for this reason.

          >some package throws a totally unexpected exception
          I see your point. I think newer languages like Rust are doing this the best, by forcing you to handle some actual error or result type instead of relying on you to "know" what code can throw an exception. But the thing is, this isn't really a JavaScript or Node problem. So many massive languages rely on the try/catch paradigm of error handling that it just isn't really a good argument here.

          >In Go they have an obssessive focus on backwards compatibility so your tool you wrote once will compile to bytecode and run blazing fast for all eternity.
          That is why I really like Go and why I started this thread. I think languages that compile down to a single binary are great for longevity, but at the same time, you still have a reliance on dependencies in some form. If you don't have your binary and need to recompile, you need to download a Go compiler. You also need to download the dependencies for your project. These two requirements need to be satisfied every time a new build is created, so I don't really end up feeling any less "detached" from the internet or that my bulid chain is any more robust. It doesn't feel that different from making sure that you have Node installed and doing an npm install when you need to install your stuff.

          > And your source code will look EXACTLY the same as every other Go codebase
          I do like this. ESLint is not the best.

          • 3 months ago
            Anonymous

            >If you don't have your binary and need to recompile, you need to download a Go compiler. You also need to download the dependencies for your project

            you can run 'go mod vendor' and then commit the new 'vendor' folder into Git to store your dependencies once and forever. No need to re-download on future builds.

            • 3 months ago
              Anonymous

              I'm not familiar with the Go ecosystem, can you explain a little more? this seems akin to storing your node_modules in your git repository. Is this widely accepted in the Go world? I guess it might be more acceptable because I would bet that Go projects generally have a lighter dependencies folder. node_modules is commonly 150mb or more.

              • 3 months ago
                Anonymous

                In my experience it's common and the vendor folder is not big. Go is smart enough to only pull in the matching *.go files that it needs to complete the build. It omits the rest of the dependency files.

        • 3 months ago
          Anonymous

          >errors are a first class citizen of the language
          if err != nil is far from "first-class citizen" lmao. Go probably has the worst error handling ever. Even C has more features out of the box for error handling.

          • 3 months ago
            Anonymous

            As if that's any better than a labyrinth of 20 try-catch statements where you STILL miss critical errors.

            Get raped by my simple, single line, and foolproof err!=nil checks, loser 😉

  3. 3 months ago
    Anonymous

    >Why would I bother writing a CLI tool in something like Go or Rust
    Can't use multiple CPUs efficiently with JS. It's okay if your machines only have 1 or 2 CPUs. Also, callbacks are a very bad limitation. "Async" does not solve that issue, only makes it "more readable". Functions are untyped (everything is). JS is like some inefficient kind of assembly, that's still alive because of browsers.

    • 3 months ago
      Anonymous

      Because it's slow. I swear, the amount of effort webshitters will go through to use their shitty language anywhere is ridiculous.

      >Can't use multiple CPUs
      Out of the box, Node will run a single thread and use the event loop to handle async. If you want to "use multiple CPUs" or run something in parallel, Node can do that too.
      https://nodejs.org/api/cluster.html#cluster

      >Because it's slow.
      Yeah, relative to a faster language, it is slow. That is obvious. But my point is that it is one the fastest scripting languages out there. Look at this: Go is slow compared to C. That is true. Does that mean Go is slow? No.

  4. 3 months ago
    Anonymous

    Because it's slow. I swear, the amount of effort webshitters will go through to use their shitty language anywhere is ridiculous.

  5. 3 months ago
    Anonymous

    because it's slow

  6. 3 months ago
    Anonymous

    >Why would I bother writing a CLI tool in something like Go or Rust when I can use Node or Deno instead?
    Mentally ill freetards btfo. I hate when I find a good open source CLI program, and it turns out to be in fucking C, Go, Rust, etc. just for its own sake while a scripting language would have been much better for the goal. I'm sure as hell not touching any of that shit, and neither does anyone else.
    >Second argument is speed. Node is probably the greatest balance between fast and widely used. It is faster than Ruby and Python
    Speed is absolutely true, but the thing is, JS is is fucking disgusting while Python is pretty simple and comfy. In most cases, you don't need speed of execution, you need speed of development. Python libraries are of higher quality on average, and it's much more widely used for purposes which are not client-side JS, it's the lingua franca of computer science. And if you thought Python packages were a mess, boy are you in for a surprise when you try Node where everything just breaks every other week.
    >code reuse
    >Electron
    This is what makes Node appealing to me, it's fucking great how it solved the cross-platform desktop app with GUI problem.

    • 3 months ago
      Anonymous

      Worthless webshitter

  7. 3 months ago
    Anonymous

    Because you need the right version of node installed to use them.
    Imagine having to rewrite it if they drop a new version that isn't compatible.

    • 3 months ago
      Anonymous

      I don't think this is a huge thing you should worry about. Generally a project will support the oldest supported version of Node and higher for practical reasons, but I can't think of an instance where someone with a newer version of Node than the author originally had will be unable to run the code.

  8. 3 months ago
    Anonymous

    >I have access to a wider ecosystem
    wider ecosysem of supply chain attacks on jsfags

    • 3 months ago
      Anonymous

      You see more supply chain attacks in the Node.js world because more Node.js applications and packages exist. For example, I grew up in Idaho, and all the rednecks in that state parrot "FORD -- found on road dead!" 24/7. In reality, you see more broken down Ford vehicles because Ford is one of the top selling manufacturers. More exist, so more fail.

  9. 3 months ago
    Anonymous

    Node is very based OP. Never find myself wanting between Node and occasional Nim.

    • 3 months ago
      Anonymous

      Nim seems great, but I am speaking as an outsider. I lean toward things like Swift, Objective-C and Java to compliment Node. I am an app developer and I use them to write native code when more speed is needed for my applications. I think Rust is also nice looking from a Node perspective, because of tools like Neon.

  10. 3 months ago
    Anonymous

    >building a cli on something that needs a runtime
    >not compiling your cli to a fast binary
    >ignoring cobra, the best CLI lib, used by kubernetes and so on is for golang
    >ignoring go has one of the best standard libs for shit a cli does such as opening a ssh tunnel and IO

    I have converted some bash scripts i used for work to a go CLI with cobra and it was a piece of cake, now i have a quick way to reset dbs, fetch db dumps from s3, start dev env, turn on work vpn, etc and all my coworkers needed to do was put the binary in their usr dir, in node that would no be the case.

    • 3 months ago
      Anonymous

      >all my coworkers needed to do was put the binary in their usr dir, in node that would no be the case.
      In Node in would be even easier: npm install tool -g

      This is another hang up I have with "compile to native" languages. Everyone touts that as an advantage, but it really doesn't have an advantage at all. You still need to download the binary and put it somewhere in your path. That isn't any easier. It isn't like someone who has no idea how to use a terminal would suddenly be empowered to use your code. And you also miss out on straightforward upgrades. You can get around this by installing your binary tool with a package manager like Homebrew, but then you are back to square one -- using a package manager to install the tool. You could have just used NPM, or Bundler, or PIP.

      Tools like Homebrew even abstract the process more, installing Node.js silently in the background if you happen to install a tool that uses it.

Your email address will not be published. Required fields are marked *