Hacker News Reader

Comment by explaininjs | Hacker News Reader

Don’t bring TypeScript into this. It is very possible to write sub 100ms procedures in TS, but an inelegant algorithm will be slow in any language, eventually.

View on HN

> It is very possible to write sub 100ms procedures in TS, […]

I won’t dispute this statement since I currently lack the means to assess inshellisense. Would it be possible for you (or someone with a functional Node + NPM setup) to install inshellisense and share the actual performance figures? You could use a tool like hyperfine (https://github.com/sharkdp/hyperfine) for this purpose.

As an attempt to test this myself, I used a Docker image (version 21.1.0-bookworm from https://hub.docker.com/_/node/). The TypeScript tool installed without any issues, along with the binding, which simply adds the following line into ~/.bashrc:

    [ -f ~/.inshellisense/key-bindings.bash ] && source ~/.inshellisense/key-bindings.bash

However, when I initiated a new Bash session within the same Docker container to activate the updated Bash configuration, I encountered the following error:

    bash: /root/.inshellisense/key-bindings.bash: line 1: syntax error near unexpected token `$'{\r''
    'ash: /root/.inshellisense/key-bindings.bash: line 1: `__inshellisense__() {

Due to this issue, I am unable to perform a performance test using hyperfine.

The version of Bash available in this Docker image is 5.2.15(1)-release.

I verified that the content of /root/.inshellisense/key-bindings.bash is exactly the same as https://github.com/microsoft/inshellisense/blob/main/shell/k...

I'm pretty sure that the scripts generated by inshellisense are CRLF, and the carriage returns aren't recognized by unix shells.

You should be able to fix it with:

    vi $HOME/.inshellisense/key-bindings.zsh -c "set ff=unix" -c ":wq"

The claim should be tested by measuring the latency of a well-engineered TS-written language service provider. The language services for TypeScript themselves run in far fewer than 100ms, and that is a far more dynamic and complex use case. The shell language service on the other hand is trivially cacheable and on the whole quote simplistic, at least compared to the full TS semantics.

100ms is a long time to wait for each completion suggestion.

I was going to say the same thing. In what world is 100ms fast on a computer? (for something not making a network round trip)

The claim isn’t that 100ms is fast, it’s that the blame for the latency lies in the engineering, not the language.

Jakob Nielsen says that 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result...

https://www.nngroup.com/articles/response-times-3-important-...

Depends on what they are waiting for. If there were 100ms of keystroke to paint latency with typing you'd def notice it.

In gaming, delay of 100ms is huge enough for anyone besides the most casual players to notice.

Obviously this are different use-cases, but wouldn't be suprised if it was big enough for people to at least notice

>>In gaming, delay of 100ms is huge enough for anyone besides the most casual players to notice.<<

I agree. I used to play a drum beat game with my daughter and son-in-law, who are both professional musicians, and they could hit beats within a 10ms window, while I struggled to get under 100ms.

But 100ms seems like a reasonable upper limit for autocomplete to me.

PS: My son-in-law is a professional drummer and can't play Rush YYZ on Rock Band (just had to include this tidbit cause it'll piss him off)

In absolute terms, that's a few hundred million CPU instructions.

Man, we are doing a CLI autocomplete for duck sake, and You guys want to spin ENTIRE FUCKIN BROWSER for it, and then argue "well, it isn't THAT slow, so what's the problem".

I'm not some extreme purist that thinks everything should be made in C and then hand optimized in assembly, but Jesus, how wasteful can You get before the slightest amount of self awareness starts to kick in.

And for what reason, to save a week of engineering time learning GOlang?

You know, JavaScript runs without a browser... There are several JavaScript implementations, most of them aren't bundled with a browser.

https://en.m.wikipedia.org/wiki/List_of_ECMAScript_engines

Or, spend the 10 minutes learning that Node isn’t spinning up an entire browser.

This thread is filled with a shitload of this knee jerk idiocy. If you want to promote Go, at least learn how to complain about factual things instead of writing some fiction and complaining about that. Node has legit issues you could complain about. FFS, whine better.

JavaScript doesn't belong in the shell, thanks.

I disagree. Using the same algorithms, a language like Typescript or Javascript will inevitably be slower than ones that are “closer” to the CPU.

Reply on news.ycombinator.com