Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs-ng: Emacs with Deno runtime and TypeScript

github.com

Post reply on HN
Print view View original

131–140 of 154 posts

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#131

Post by skissane »

bitwize wrote: post #120
blacktriangle wrote: post #113

Earlier quoted context omitted.

Meet your users where they are is great advice for consumer apps you want people to onboard to quickly and the users only interact with them periodiclly. We're talking about the power tools of our profession. Nobody designs a band-saw to meet their users where they are either. These are apps we spend 8hrs+ per day living in, and frankly the buffer wording is superior because a buffer is not a file, but a file is in a…

> Meeting your users where they are is how we got everybody moving from Textmate to Atom and now to VSCode as the new hotness that would finally kill Emacs and vi. And yet that's the mentality that prevented those newer editors from having the legs to really last. I'd like to think that too, but the sad fact is that most developers these days use VSCode. It is the new hotness that killed Emacs and vi. Emacs and vi ar…

> Emacs and vi are both mere footnotes compared to VSCode in terms of market and mind share

According to StackOverflow's 2019 developer survey [0], 50.7% of editors used VSCode, 25.4% used Vim. So that doesn't really support your claim that vi is a "mere footnote". 25% of market share isn't 50%, but it is still decent and more than a mere "footnote".

[0] https://insights.stackoverflow.com/survey/2019#development-e...

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#132

Post by taeric »

vitus wrote: post #125
taeric wrote: post #106

Earlier quoted context omitted.

Agreed. I didn't mean that necessarily as a criticism of anything. Just hard to have an intuition for just how much it slows down. I suppose there is a bit of something in there about using the right algorithm. But I can understand picking one that will take time for comparing speed. I'm not sure either is really representative of work you expect an editor to do, though. Curse of benchmarks.

The speed of the naive recursive fib scales with the number it computes, which is roughly 1.6 ^ n (the eigenvalue of the matrix for the recurrence relation is the golden ratio, phi). Intuition: if you were to expand and flatten the recursive calls, you'd end up with something like (+ 1 0 1 1 0 1 1 0 ... 1 0) with exactly (fib n) 1s (base case (fib 1)), and no more than (fib n) 0s (base case (fib 0)). Simple example:…

Right. I "know" how tree recursion scales up. It is still neat to "see" the impact on the speed.

That is, knowing all of these facts, it is still impressive how fast you can get (fib 1000000) using iteration and bignums.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#133

Post by hvis »

vitus wrote: post #130
vitus wrote: post #126

Earlier quoted context omitted.

This was emacs 27.1 (which is the version in the Arch repo). I can install native-comp via AUR. It'll take some time.

I think this is what you're looking for. time emacs --script fib-0b03fe9a-6b386e71.eln emacs --script fib-0b03fe9a-6b386e71.eln 22.47s user 0.09s system 99% cpu 22.664 total About 50% faster, which is nothing to sneeze at, but still appreciably slower than most other things I tried. (I copied the .eln from the cache to confirm that's what I'm running against; I got a similar speedup from running against fib.elc.)

Thank you. That's an interesting result.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#134

Post by monsieurbanana »

Kaze404 wrote: post #98
monsieurbanana wrote: post #70

Earlier quoted context omitted.

> A side effect of that is that emacs does everything I need I'm certain you're telling the truth. And I'm sure that's the case for a lot of old-timers emacs users. But I have the feeling it's less and less true. People that have used emacs for a long time don't need anything else, so they don't want any change. People for whom emacs doesn't cover everything want change, but clash against the first group of people (w…

I've used Emacs for 2 years and haven't had to write a single elisp function.

I've used Emacs for... 10 years now? I didn't customize it for an embarrassing long amount of time, but by now I'm comfortable writing elisp code. It is a game changer.

Given enough time I can make Emacs do pretty much anything. I just don't have that much free time (anymore).

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#135

Post by vitus »

taeric wrote: post #132
vitus wrote: post #125

Earlier quoted context omitted.

The speed of the naive recursive fib scales with the number it computes, which is roughly 1.6 ^ n (the eigenvalue of the matrix for the recurrence relation is the golden ratio, phi). Intuition: if you were to expand and flatten the recursive calls, you'd end up with something like (+ 1 0 1 1 0 1 1 0 ... 1 0) with exactly (fib n) 1s (base case (fib 1)), and no more than (fib n) 0s (base case (fib 0)). Simple example:…

Right. I "know" how tree recursion scales up. It is still neat to "see" the impact on the speed. That is, knowing all of these facts, it is still impressive how fast you can get (fib 1000000) using iteration and bignums.

There, that runtime is roughly O(n^2) when dealing with bignums, since addition scales linearly with bit length of the operands, and bit length increases linearly with the number of iterations (~0.7 bits per iteration).

Which is still not fast -- on my laptop, Python takes about 9s for fib(1000000). But compared to an exponentially-growing function, that's a blink of an eye.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#136

Post by Ar-Curunir »

anthk wrote: post #114
Ar-Curunir wrote: post #104

Earlier quoted context omitted.

Yeah, and now imagine if you didn’t have to worry about simple things like memory safety or overflow or null pointer checks or so many C problems that Rust fixes. The point of Rust is to enable newbies to write systems software.

>That's what Go has been built for, but if you trust a newbie writting low level stuff, bad shit will happen either sooner or later.

So the solution is what, exactly? To isolate people and gatekeep them from learning systems programming?

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#137

Post by anthk »

Ar-Curunir wrote: post #136
anthk wrote: post #114

Earlier quoted context omitted.

>That's what Go has been built for, but if you trust a newbie writting low level stuff, bad shit will happen either sooner or later.

So the solution is what, exactly? To isolate people and gatekeep them from learning systems programming?

Yes? This is a meritocracy, if don't know how to do low level stuff, head to the College, or learn it properly.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#138

Post by anthk »

vitus wrote: post #125
taeric wrote: post #106

Earlier quoted context omitted.

Agreed. I didn't mean that necessarily as a criticism of anything. Just hard to have an intuition for just how much it slows down. I suppose there is a bit of something in there about using the right algorithm. But I can understand picking one that will take time for comparing speed. I'm not sure either is really representative of work you expect an editor to do, though. Curse of benchmarks.

The speed of the naive recursive fib scales with the number it computes, which is roughly 1.6 ^ n (the eigenvalue of the matrix for the recurrence relation is the golden ratio, phi). Intuition: if you were to expand and flatten the recursive calls, you'd end up with something like (+ 1 0 1 1 0 1 1 0 ... 1 0) with exactly (fib n) 1s (base case (fib 1)), and no more than (fib n) 0s (base case (fib 0)). Simple example:…

  With scm, using (trace proc):
 
 scm -f fib.scm
 
 call fib 9
    call fib 8
      call fib 7
        call fib 6
          call fib 5
          retn fib 5
          call fib 4
          retn fib 3
        retn fib 8
        call fib 5
          call fib 4
          retn fib 3
          call fib 3
          retn fib 2
        retn fib 5
      retn fib 13
      call fib 6
        call fib 5
          call fib 4
          retn fib 3
          call fib 3
          retn fib 2
        retn fib 5
        call fib 4
          call fib 3
          retn fib 2
          call fib 2
          retn fib 1
        retn fib 3
      retn fib 8
    retn fib 21
    call fib 7
      call fib 6
        call fib 5
          call fib 4
          retn fib 3
          call fib 3
          retn fib 2
        retn fib 5
        call fib 4
          call fib 3
          retn fib 2
          call fib 2
          retn fib 1
        retn fib 3
      retn fib 8
      call fib 5
        call fib 4
          call fib 3
          retn fib 2
          call fib 2
          retn fib 1
        retn fib 3
        call fib 3
          call fib 2
          retn fib 1
          call fib 1
          retn fib 1
        retn fib 2
      retn fib 5
    retn fib 13
  retn fib 34
  call fib 8
    call fib 7
      call fib 6
        call fib 5
          call fib 4
          retn fib 3
          call fib 3
          retn fib 2
        retn fib 5
        call fib 4
          call fib 3
          retn fib 2
          call fib 2
          retn fib 1
        retn fib 3
      retn fib 8
      call fib 5
        call fib 4
          call fib 3
          retn fib 2
          call fib 2
          retn fib 1
        retn fib 3
        call fib 3
          call fib 2
          retn fib 1
          call fib 1
          retn fib 1
        retn fib 2
      retn fib 5
    retn fib 13
    call fib 6
      call fib 5
        call fib 4
          call fib 3
          retn fib 2
          call fib 2
          retn fib 1
        retn fib 3
        call fib 3
          call fib 2
          retn fib 1
          call fib 1
          retn fib 1
        retn fib 2
      retn fib 5
      call fib 4
        call fib 3
          call fib 2
          retn fib 1
          call fib 1
          retn fib 1
        retn fib 2
        call fib 2
          call fib 1
          retn fib 1
          call fib 0
          retn fib 0
        retn fib 1
      retn fib 3
    retn fib 8
  retn fib 21
  55
 
 scm -f fib-iter.scm
 
 call fib-iter 1 0 10
    call fib-iter 1 1 9
      call fib-iter 2 1 8
        call fib-iter 3 2 7
          call fib-iter 5 3 6
          retn fib-iter 55
        retn fib-iter 55
      retn fib-iter 55
    retn fib-iter 55
  retn fib-iter 55
  55

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#139

Post by otabdeveloper4 »

bitwize wrote: post #108
otabdeveloper4 wrote: post #94

Earlier quoted context omitted.

No, Deno is built with V8, and V8 is written in C++.

V8 is the only C++ component of Deno. The other bits of the runtime are written in Rust, and Rust is the native extension language.

The "other bits" are the ones that don't matter.

It's like saying that a browser skin is "built on Rust" when inside it's still Webkit and Chromium.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#140

Post by blacktriangle »

skissane wrote: post #131
bitwize wrote: post #120

Earlier quoted context omitted.

> Meeting your users where they are is how we got everybody moving from Textmate to Atom and now to VSCode as the new hotness that would finally kill Emacs and vi. And yet that's the mentality that prevented those newer editors from having the legs to really last. I'd like to think that too, but the sad fact is that most developers these days use VSCode. It is the new hotness that killed Emacs and vi. Emacs and vi ar…

> Emacs and vi are both mere footnotes compared to VSCode in terms of market and mind share According to StackOverflow's 2019 developer survey [0], 50.7% of editors used VSCode, 25.4% used Vim. So that doesn't really support your claim that vi is a "mere footnote". 25% of market share isn't 50%, but it is still decent and more than a mere "footnote". [0] https://insights.stackoverflow.com/survey/2019#development-e...

Wow even Emacs doing better than I would have thought at 4.5%.

People overestimate the value of massive community and apply a winner takes all mentality too often. You don't need a giant community, and almost by definition giant communities tend to have a lower average user quality leading to lower quality of libraries and support (looking at you JS ecosystem).

Post reply on HN