ssh is pretty hard to do right. i will never get, why platforms have to stay "pure"... and implement everything on earth another time within their platform instead of calling reasonable external c-code (or anything else for that matter). i bet this implementation does not parse .ssh/config correctly either.

I'll tell you why. Because the c-libs probably block and having dependencies that have to be compiled increases the risk of something going wrong.

Why should this library parse .ssh/config? This is an application level library. IMO it shouldn't be reading .ssh/config at all.

"having dependencies that have to be compiled increases the risk of something going wrong".

come on. reimplementing crypto is way worse.

re .ssh/config: application level libraries might need it as well. one of the many grieves i have about mysql-workbench (or any other java tool that does ssh), is that i have to configure keys and hostnames in it another time. multihop does not even work in them. both is easy in .ssh/config.

Re .ssh/config, this only makes sense for cli tools.

If you're on a Mac and writing a desktop sandboxed GUI app, reading .ssh/config isn't even an option. Same for W8 Metro apps (if those can even contain a Node.js runtime; not sure about that).

And if you're using an ssh lib on a web site to access user-provided data using user-provided credentials, you most certainly don't need .ssh/config.

why? what about the usecase i presented? mysql-workbench is no cli app. still, i'd like it to support multi-hop. and it should do so without me configuring it separately.

edit: to make this more clear. of course a heavily sandboxed app might not support .ssh/config. but it should not be able to read my keys as well. so i don't really see the point. a web-app is a very different thing. but node is not only about web apps anymore.

libssh2 exposes its socket interface and can be used with any async event library.

I think it's quite simple, and we're all guilty of it at some time or other: it's much easier to reinvent and reshape already solved problems in our own image than it is to innovate in any useful manner.

This explains the abundance of languages that can all trace their conceptual heritage to the 60s, the abundance of basically identical Javascript frameworks, web frameworks, ORMs, and so on, the majority of which IMHO should never have left the spinning rust in the original developer's machine (highly applicable to many of my own projects).

It's also one reason why the 'code cleanup guy' on a team might not be doing anyone a favour – what hard work is he avoiding by endlessly obsessing over his preferred syntactical representation for a 5 line function? etc.

I think this also relates to a youthful rejection of 'good enough' – the desire that, this time around and if only everything was all beautiful and homogenous, it's all going to be perfect.

The reason why Erlang does this, is that in an event-loop based system, anything that blocks breaks everything. The Erlang solution is to launch untrusted C code in a separate process and communicate via sockets.

I imagine that Node faces a similar problem with "untrusted C code".

i am familiar with erlangs ports. why shouldn't the same work for node?

(and btw: cryptography might take a big computational chunk. it's hard to write cpu-intensive stuff in node's callback style. but i guess the person(s) doing it will sort this out.)

I'm just explaining one motivation for wanting to be "pure". Node could certainly do something like what Erlang does. Erlang has, in the past, also gone the 'pure' route. IIRC, they had their own slow/limited regexp implementation, for instance, so that it'd run in the VM and not block.

oh. and erlang is not event-loop based. it has preemptive multitasking for its threads. so it is not as necessary in erlang than it is in node.

Being multi-threaded is a relatively recent thing for Erlang. And IIRC, it only starts enough of them to cover all the system cores.

It has preemptive multitasking for its "processes", but seeing as how those are all in the same Unix process, and time is allocated to them via Erlang's own virtual machine, calling out to something in C that blocks would be a problem for Erlang.

Erlang, at a basic level, is event based, and this kind of protection is necessary.

There's several things left to do: https://github.com/mscdex/ssh2/blob/master/TODO

But I wouldn't be so negative, there's plenty of reasons why this might be great / a good idea. (And a lot for it to be a bad one, crypto, security, etc.)

Well I know SSL is a pain point in node that needs fixing and I also know that there is a performance price to pay for crossing the JavaScript / C barrier with libuv so it could be if you do a lot of processing it's quicker to stay in v8.

Perhaps this is trying to help those points.

Writing a good novel is pretty hard to do, why are people not just republishing old ones?

Am I the only one who thinks JavaScript should be confined to the browser for strategic maintenance purposes?

node javascript and browser javascript are 2 different things. the javascript node uses is pretty decent , and as ES6 kicks in it will be a language as good as PHP (even better , since it will not have all the java inspired non sens php has). On the client , javascript is pretty much stuck since you need to support a wide range of browsers.