Live data from Hacker News

CoreUtils implemented in pure JavaScript

github.com

41–50 of 128 posts

Re: CoreUtils implemented in pure JavaScript

#41
post #30
post #7

Earlier quoted context omitted.

> UNIX shells suck. Javascript sucks. How could one implement a UNIX shell in Javascript and have it not suck? What do you mean by "UNIX shells suck"? I'm fairly sure most people would consider UNIX shells to be one of the bigger revolutions in computing.

Perhaps it's my own shortcoming, but for any given script I write, I find that, say, 20% of all my code is productive, and the remaining 80% is massaging the output of one tool into a shape that's compatible with the input of the next tool. Compare with the exprience of using Windows PowerShell where cmdlets return objects and you can grab precisely the fields you want with minimum ceremony. Things are better now wit…

I think that's the point- they're amazingly powerful. Additionally with POSIX, you can assume that the command you used on one OS behaves or at least outputs the same on another.

I feel like the interface for these commands is exactly what you'd want from a collection of executables that do only one thing.

As for shell scripting, you don't have to use bash/sh/whatever. You could write your script or executable in any language that will let you call system commands, so it's really a non-issue if you absolutely can't stand the syntax. I write plenty of bash scripts and I do feel your pain, they're not usually very pleasant if you have to go beyond trivial use cases- but it's also (generally) not impossible.

Re: CoreUtils implemented in pure JavaScript

#42
post #30
post #7

Earlier quoted context omitted.

> UNIX shells suck. Javascript sucks. How could one implement a UNIX shell in Javascript and have it not suck? What do you mean by "UNIX shells suck"? I'm fairly sure most people would consider UNIX shells to be one of the bigger revolutions in computing.

Perhaps it's my own shortcoming, but for any given script I write, I find that, say, 20% of all my code is productive, and the remaining 80% is massaging the output of one tool into a shape that's compatible with the input of the next tool. Compare with the exprience of using Windows PowerShell where cmdlets return objects and you can grab precisely the fields you want with minimum ceremony. Things are better now wit…

If you like PowerShell, try using jq in your Unix shell pipelines. Ingesting data into json is still a bit finicky, but once you know the patterns you need to use with cut and a csv-to-json tool things become much faster.

Re: CoreUtils implemented in pure JavaScript

#43

>Huh? Okay - think Cygwin, except: Oh boy, another one of these. Cygwin is useful because it provides a POSIX C API on Windows. It is not useful because of its shell and coreutils. And saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js require/export patterns instead of ES6 modules. >1/15th of the size [of Cygwin] Haha, and 1/100th the functionality

Is this indicative of what's going on in the JS world today, with all the churn of packages and libs? Does it boil down to being sucky and not useful if it isn't written in ES6/TypeScript/Whatever and not invented by your team? Why do the other things suck because they're not this?

EDIT: I've said it on other threads- I like the creativity and exuberance in the JS community. I'm not putting it down. There's just a lot of churn/NIHS.

(I didn't seem to be getting downvoted, but I also want to be clear that I'm not putting the community down)

END EDIT

I think it's a cool excercise. Why would I ever want to use this in the way it is saying it should be used? Why would I ever use this period?

Re: CoreUtils implemented in pure JavaScript

#44
post #5

As far as I can see, what's been implemented is a shell in JavaScript, which emulates a bunch of coreutils by treating them as built-in keywords. It's kinda cool I guess (I don't use Windows), I just don't get why the tagline is "Cross-platform Linux without the suck". Apart from the phrase "cross-platform Linux" not making sense in this context, I don't see why other implementations inherently "suck".

It's not just a separate shell. Each command can be enabled globally. It just might not be desirable for everyone who wants to use these.

Re: CoreUtils implemented in pure JavaScript

#45

>Huh? Okay - think Cygwin, except: Oh boy, another one of these. Cygwin is useful because it provides a POSIX C API on Windows. It is not useful because of its shell and coreutils. And saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js require/export patterns instead of ES6 modules. >1/15th of the size [of Cygwin] Haha, and 1/100th the functionality

Is this indicative of what's going on in the JS world today, with all the churn of packages and libs? Does it boil down to being sucky and not useful if it isn't written in ES6/TypeScript/Whatever and not invented by your team? Why do the other things suck because they're not this? EDIT: I've said it on other threads- I like the creativity and exuberance in the JS community. I'm not putting it down. There's just a lo…

In instances like this, there's no issue with it being ES5.

However, in the web world, ES6 modules have a huge (pardon the pun) advantage that's just being realized. Because of the static nature of ES6 imports, you can eliminate unused code when you package it all together. The newest Webpack versions and Rollup are both taking advantage of this, and it can result in huge savings in filesize.

For example, lodash is a large library with hundreds of methods, and a lot of the time people only use 3 or 4 imports from it. If you use an ES5 version, you'll get all of those functions in a compiled bundle no matter what. If you use an ES6 version with Webpack 2, all the methods you use will end up being the only ones that are actually included in the final code.

Re: CoreUtils implemented in pure JavaScript

#46

>Huh? Okay - think Cygwin, except: Oh boy, another one of these. Cygwin is useful because it provides a POSIX C API on Windows. It is not useful because of its shell and coreutils. And saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js require/export patterns instead of ES6 modules. >1/15th of the size [of Cygwin] Haha, and 1/100th the functionality

Is this indicative of what's going on in the JS world today, with all the churn of packages and libs? Does it boil down to being sucky and not useful if it isn't written in ES6/TypeScript/Whatever and not invented by your team? Why do the other things suck because they're not this? EDIT: I've said it on other threads- I like the creativity and exuberance in the JS community. I'm not putting it down. There's just a lo…

Not Invented Here Syndrome has been around a long time. But it used to indicate a sort of conservatism and fear in corporate culture.

This NIHS seems more the result of ADHD and impatience, sprinkled with a little enlightened precociousness.

You can see it in the satire surrounding computer programming. In the 90s, Dilbert had insight into the causes of NIHS. These days, Silicon Valley hits closer to the target.

(PS: the creator of this package looks to be getting a lot of flak here. Kudos to them for doing it, but they would benefit from understanding why it's such a shallow "replacement" for Cygwin.)

Re: CoreUtils implemented in pure JavaScript

#47
post #38

>Huh? Okay - think Cygwin, except: Oh boy, another one of these. Cygwin is useful because it provides a POSIX C API on Windows. It is not useful because of its shell and coreutils. And saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js require/export patterns instead of ES6 modules. >1/15th of the size [of Cygwin] Haha, and 1/100th the functionality

Simpler is better. Cygwin is overkill unless you are trying to mimic your exact non-Windows environment, and it doesn't mix well with Windows' vanilla CMD environment. For those of us who want to be working with more Windows than UNIX, but who are used to standard coreutil commands, 1/100th the functionality of cygwin actually sounds kind of great! Not saying that the commands need to be written in JS, but it seems l…

node.js is not simple or even simpler

Re: CoreUtils implemented in pure JavaScript

#48
post #42
post #30

Earlier quoted context omitted.

Perhaps it's my own shortcoming, but for any given script I write, I find that, say, 20% of all my code is productive, and the remaining 80% is massaging the output of one tool into a shape that's compatible with the input of the next tool. Compare with the exprience of using Windows PowerShell where cmdlets return objects and you can grab precisely the fields you want with minimum ceremony. Things are better now wit…

If you like PowerShell, try using jq in your Unix shell pipelines. Ingesting data into json is still a bit finicky, but once you know the patterns you need to use with cut and a csv-to-json tool things become much faster.

I do love jq :)

Hadn't thought of chaining that with a csv-to-json workflow, that's a neat idea -- but if that's the easiest way out, that's clearly a symptom of the problem I'm describing, isn't it?

Re: CoreUtils implemented in pure JavaScript

#49

>Huh? Okay - think Cygwin, except: Oh boy, another one of these. Cygwin is useful because it provides a POSIX C API on Windows. It is not useful because of its shell and coreutils. And saying it uses "pure ES6" is stretching it - it's using the plain ES5 Node.js require/export patterns instead of ES6 modules. >1/15th of the size [of Cygwin] Haha, and 1/100th the functionality

I suppose in this case "less is more".

More often than not, if I'm working on a windows machine, I'm not programming in C. I'm probably working on something in C# or Java. I don't care about the C API. I just want the terminal to work in more or less the same way it does on linux/osx.

Re: CoreUtils implemented in pure JavaScript

#50
post #46

Earlier quoted context omitted.

Is this indicative of what's going on in the JS world today, with all the churn of packages and libs? Does it boil down to being sucky and not useful if it isn't written in ES6/TypeScript/Whatever and not invented by your team? Why do the other things suck because they're not this? EDIT: I've said it on other threads- I like the creativity and exuberance in the JS community. I'm not putting it down. There's just a lo…

Not Invented Here Syndrome has been around a long time. But it used to indicate a sort of conservatism and fear in corporate culture. This NIHS seems more the result of ADHD and impatience, sprinkled with a little enlightened precociousness. You can see it in the satire surrounding computer programming. In the 90s, Dilbert had insight into the causes of NIHS. These days, Silicon Valley hits closer to the target. (PS:…

> (PS: the creator of this package looks to be getting a lot of flak here. Kudos to them for doing it, but they would benefit from understanding why it's such a shallow "replacement" for Cygwin.)

I agree. Like I said, I think it's a cool excercise. I'm all for doing things just to learn and explore. Which is what I'd classify this as. The things you learn doing stuff like this will likely help you in the future in some tangential way. No one should be excoriated for practicing their craft, especially in a case like this where it's a nifty project.

The problem is when you put down other projects or even OSes in this case that, frankly, are immensely more powerful and useful than what you've put forth. I think lacking the 'without the suck', it probably wouldn't have gotten much attention, especially the negative.

Post reply on HN