4x Smaller, 50x Faster • Hacker News Board

Re: 4x Smaller, 50x Faster

#121

Post by zupa-hu » Tue, Nov 30, 2021, 11:26 AM UTC

mping wrote: post #96

lxe wrote: post #2

The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.

Well the immutability hype allowed the author to build the previous incantions of the library. At this point, I hoped everyone understood the tradeoffs of using abstractions. Otherwise we should all be programming on assembly.

This. If the project was reimplemented in assembly, it would be faster and smaller and the same conclusion could be drawn: “finally the high level programming hype is over”.

come on..

Re: 4x Smaller, 50x Faster

#122

Post by detaro » Tue, Nov 30, 2021, 11:28 AM UTC

jcelerier wrote: post #119

bachmeier wrote: post #23

Earlier quoted context omitted.

This is an application where the goal is to squeeze every last drop of performance possible out of the processor. The "every last drop of performance" crowd has never been the source of the "immutability hype". Your comment is dismissive of many domains of programming - immutable didn't become a thing because others weren't as enlightened as you.

> This is an application where the goal is to squeeze every last drop of performance possible out of the processor. I have a hard time thinking of an application for which this isn't the case. If my cooking recipe app / website is too slow and/or eats too much battery (and god fucking knows they are) I'll look for a competitor immediately.

not being too slow and "squeeze every last drop of performance possible" is not really the same, and the latter is an expensive tradeoff to make.

Re: 4x Smaller, 50x Faster

#123

Post by kevincox » Tue, Nov 30, 2021, 11:31 AM UTC

ryansolid wrote: post #16

It's awesome to see performance-oriented projects to find their way to SolidJS( https://www.solidjs.com ). So satisfying to see success stories like this one. Great work.

I'm struggling to find out how it actually updates the DOM. The way that re-rendering happens is clear but it looks like the top-level function just returns a JSX.Element. There is no explanation how this is efficiently rendered.

Also how are mid-level invalidations handled? For example if I update a list to remove one element do the other elements get re-rendered or are they cached?

It might be because I am browsing the docs in mobile but I find them hard to navigate.

Re: 4x Smaller, 50x Faster

#124

Post by fnordsensei » Tue, Nov 30, 2021, 11:36 AM UTC

unnouinceput wrote: post #114

I get it, Clojure bad, Rust good. Yeah, absolutely nothing to do with the brain in the chair.

More like, know when to apply Clojure and when to apply Rust.

Having written a ClojureScript app with a Rust/WASM component, for me it's very clear that they have different strengths that can be complementary.

That the author dropped CLJS along with React is fair enough, in my opinion. The CLJS ecosystem is pretty React-centric.

Re: 4x Smaller, 50x Faster

#125

Post by RMPR » Tue, Nov 30, 2021, 11:56 AM UTC

Reposting here since the first submission didn't make it to the frontpage

I started using asciinema two months ago and I must say that it's excellent! One minor annoyance though, it forces the use of the default shell instead of using the shell you launched it in. Other than that I am very excited by this release, more speed is always welcome.

Re: 4x Smaller, 50x Faster

#126

Post by stjohnswarts » Tue, Nov 30, 2021, 12:06 PM UTC

codetrotter wrote: post #17

kazinator wrote: post #15

Earlier quoted context omitted.

Historically, you could embed an animated .gif into a web page going back before Y2K, and there are tools to make such a thing from recording terminal sessions. No Javascript, no third party websites.

You can’t pause and rewind or skip ahead in a gif in any of the major browsers.

9 times out 10 if you need something to be shown in video it's better to use an mp4 and screen recorder rather than stick it in a gif. It's usually smaller too.

Re: 4x Smaller, 50x Faster

#127

Post by tomxor » Tue, Nov 30, 2021, 12:11 PM UTC

atoav wrote: post #51

While I applaude the engineering effort that went into the project, I really dislike documentation that uses asciinema for regular non-interactive CLI interfaces: instead of showing me the commands in an overview I have to sit through the whole thing.

Those same authors would probably have used a youtube video instead, so asciinema's existence is not the cause of this.

Re: 4x Smaller, 50x Faster

#128

Post by stjohnswarts » Tue, Nov 30, 2021, 12:12 PM UTC

cunthorpe wrote: post #30

Maybe it’s just me, but I don’t think showing a string on screen requires React or any other view library. I’d probably paint it on canvas and then overlay an invisible plaintext node to allow selection.

People work with what they know and I'm sure they'd love to see a similar implementation done with the method you suggest. It's open source and hugs and thumbs up all around here :)

Re: 4x Smaller, 50x Faster

#129

Post by stjohnswarts » Tue, Nov 30, 2021, 12:14 PM UTC

agys wrote: post #88

For my own realtime browser based ASCII projects I update the DOM “manually”: the biggest bottleneck is frequent -horizontal- changes in color as each character with a new color needs to be wrapped in its own element. After all you can’t avoid a DOM repaint. After several benchmarks I realized that the fastest way to update the entire window is to compose a string and assign it to each line/line-element via innerHTML…

Maybe you could benchmark it against this. It would make an interest HN followup post.

Re: 4x Smaller, 50x Faster

#130

Post by knubie » Tue, Nov 30, 2021, 12:25 PM UTC

cjcampbell wrote: post #40

bsg75 wrote: post #29

Earlier quoted context omitted.

What is the connection between mutability and excessive hardware usage?

As an oversimplified example, in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer (though one could probably think of ways to optimize this for the use case). Excess comes either in the form of unnecessary (relative to mutable) memory usage and/or CPU cycles necessary to support high-levels of garbage collection.

> in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer

That’s actually not how clojure’s immutable data structures work. They use structural sharing, so only the portion that changes (roughly) needs new memory allocated, and only the parts that changed get garbage collected, so it is a bit more efficient than that.