What the fuck I don't even
Please post civilly and substantively, or not at all.
CoreUtils implemented in pure JavaScript
111–120 of 128 posts
Re: CoreUtils implemented in pure JavaScript
#112Apart from this being of questionable usability, why do people feel the need to solve every problem with (Node)JS? I can think about a ton of languages better suited for systems programming at the top of the hat.
Here is my language-choosing thought process... Perl/Python/PHP/Ruby: Generally 10x or more slower than V8 Node.js, plus global interpreter lock = automatic no. C/C++/etc? Fast, but too complex to work with build system / platform compat / 3rd party modules = generally no. Java? Way too slow startup time; JVM install for users painful = automatic no Scala/Clojure/etc: Fine languages but same practical problems as JVM…
Why would threading with GIL be worse than no threading at all?
As long as IO is your bottleneck the GIL shouldn't be much of a problem. And Python (and I'm sure Ruby, too) has excellent async support.
Not saying Node.js isn't useful, but I wouldn't automatically say no to Python or Ruby.
Re: CoreUtils implemented in pure JavaScript
#113Earlier quoted context omitted.
Here is my language-choosing thought process... Perl/Python/PHP/Ruby: Generally 10x or more slower than V8 Node.js, plus global interpreter lock = automatic no. C/C++/etc? Fast, but too complex to work with build system / platform compat / 3rd party modules = generally no. Java? Way too slow startup time; JVM install for users painful = automatic no Scala/Clojure/etc: Fine languages but same practical problems as JVM…
Why would threading with GIL be worse than no threading at all? As long as IO is your bottleneck the GIL shouldn't be much of a problem. And Python (and I'm sure Ruby, too) has excellent async support. Not saying Node.js isn't useful, but I wouldn't automatically say no to Python or Ruby.
Fair point. I would probably use a multiprocessing approach in node.js or use https://www.npmjs.com/package/webworker-threads. If perf were very critical I would use Rust.
Re: CoreUtils implemented in pure JavaScript
#114Earlier quoted context omitted.
I keep wanting to like PowerShell but finding it limited in silly ways. Text output is crippled, and there's no sensible way to save the intermediate value of a pipeline in a file. The security ceremony required around PS is also an obstacle to getting started. And of course Microsoft have missed the opportunity to fix the path separator. I admit that Bourne shell is not great for anything over a few lines, and find…
and there's no sensible way to save the intermediate value of a pipeline in a file Sounds like you are looking for Tee-Object[0]. "Saves command output in a file or variable and also sends it down the pipeline." And of course Microsoft have missed the opportunity to fix the path separator. Windows supports both path separators in pretty much all cases (open files, changing directories, etc) PS C:\> d: PS D:\> cd /pro…
Text output is chopped at 80 characters unless you specify otherwise, even when directed to a file; I'm probably going to try converto-csv next time I want to input it into python, thanks for the tip.
The output of tee-object can't easily be read back in to a new pipeline. I suppose we're supposed to stash it in a variable which will be good enough for 99% of cases.
Re: CoreUtils implemented in pure JavaScript
#115Earlier quoted context omitted.
I believe they are doing code analysis, at least that's what the README for Rollup says: > Rollup statically analyses your code, and your dependencies, and includes the bare minimum in your bundle.
I don't think that's possible in all cases: var mod = {}; module.foo = function () { return 42; }; module.bar = function () { return -1; }; module[Math.random() > 0.5 ? "foo" : "bar"](); How can `Rollup` determine that I need both functions here?
That's why it only works with ES6 imports. ES6 imports must be made at the top of the file, and aren't dynamic. You must explicitly import what you need.
Additionally, this method only works with named imports. So for example, you can have two files:
File a.js
export a = 5;
export b = 6;
export c = 7;
export d = 8;
export default {a, b, c, d};
import {a, b} from "./a.js";
console.log(a);
console.log(b);
import a from "./a.js";
Note that it's possible I'm wrong as to the specific optimization method, but largely speaking this is how it should work.
Re: CoreUtils implemented in pure JavaScript
#116Earlier quoted context omitted.
From my own experience learning bat scripting then sh scripting and then powershell, the 40-line monstrosity is what happens when you first learn another scripting language. Sometimes the paradigm can be so different that simply trying to port one script to another language ends up being more difficult (but better, from a learning standpoint, for me) than simply starting over.
Well, I never claimed I properly learned Powershell :-). Like everything on the Internet, lack of success with a technology should be taken to mean a failure of that technology as much as a failure of the programmer attempting to use it. It may well have been a problem above the application layer.
Would you say the same about people who haven't been able to master sed? Success with any technology is as dependent on the technology as it is on the user. :)
Re: CoreUtils implemented in pure JavaScript
#117Earlier quoted context omitted.
Is your unit of simplicity really "I already have this installed"? Because then this hello world line I just wrote is more complex than your OS.
Maybe simplicity isn't exactly what I'm talking about, but yes. In fact, I couldn't run your hello world without running my OS. So from a practical point of view, me running your hello world has a dependency on my OS. From that perspective, it's easier for me to run my OS than your hello world.
I see. So you have these coreutils installed? Because if not, they're exactly as "simple" as cygwin, which is also not installed.
Re: CoreUtils implemented in pure JavaScript
#118I hope the goals are - short-term : POSIX compliant - long-term : runs *nix binary / programs p/s: love anything CLI, so I may be biased
How would they run *nix binaries in a node.js environment if they call it "Cross-platform Linux without the suck"? You are talking about Cygwin here which is what these guys hate for some reason.
well, I mean what's the point of the project if it's JUST to run linux commands? we already have Bellard's JS VM for that
OR
maybe I didn't see their long-term goal?
Re: CoreUtils implemented in pure JavaScript
#119Earlier quoted context omitted.
Maybe simplicity isn't exactly what I'm talking about, but yes. In fact, I couldn't run your hello world without running my OS. So from a practical point of view, me running your hello world has a dependency on my OS. From that perspective, it's easier for me to run my OS than your hello world.
I see. So you have these coreutils installed? Because if not, they're exactly as "simple" as cygwin, which is also not installed.
No, I don't. I have a vague recollection that cygwin was a huge and confusing monolith, but I haven't looked at it in years. This new javascript thing sounded more straight-forward. It's not really objectively supported.
I don't even like javascript.
Re: CoreUtils implemented in pure JavaScript
#120Earlier quoted context omitted.
I don't think that's possible in all cases: var mod = {}; module.foo = function () { return 42; }; module.bar = function () { return -1; }; module[Math.random() > 0.5 ? "foo" : "bar"](); How can `Rollup` determine that I need both functions here?
That's why it only works with ES6 imports. ES6 imports must be made at the top of the file, and aren't dynamic. You must explicitly import what you need. Additionally, this method only works with named imports. So for example, you can have two files: File a.js export a = 5; export b = 6; export c = 7; export d = 8; export default {a, b, c, d}; File b.js import {a, b} from "./a.js"; console.log(a); console.log(b); c/d…
That much makes sense, but if I understand GGGP's example properly, they are talking about pruning unused internal references within a module, but GGP's response implies that somehow Rollup will prune those out.