|
@rikarends | |||||
|
The most important reason to make the move from a dynamic (JS) to a static compiled language (Rust) is simply because moores law is plateauing. The only path to faster is either be less wasteful, or go parallel. With parallel being MUCH harder to do. Lots to do in less wasteful
|
||||||
|
||||||
|
Bat Bat 🦇🦇
@batmansmk
|
31. pro |
|
...and hardware acceleration/specialized instruction set! :) I know you moved a lot to the GPU with Makepad as well!
|
||
|
|
||
|
Rik Arends
@rikarends
|
31. pro |
|
Yeah, 'right now' makepad is fairly optimal as to its cpu/gpu balance. But SO much was won by simply decomplecting / writing code so the compiler can actually do things with it (no virtual dispatches anywhere).
|
||
|
|
||
|
Kamil Tomšík
@cztomsik
|
31. pro |
|
Maybe but certainly not for UI, web was once (DHTML, now called SPA) fast enough on single-core celeron 333mhz with 32, so javascript is totally fast enough it's just that today everybody does js and so the quality is very low.
|
||
|
|
||
|
Kamil Tomšík
@cztomsik
|
31. pro |
|
sorry, 32 MB RAM... And part of the problem is total number of pixels, and so the memory bandwidth.
BTW: this is also interesting mozillagfx.wordpress.com/2019/10/22/dra…
|
||
|
|
||
|
rektide de la fay
@rektide
|
31. pro |
|
It still makes me so sad when languages like TypeScript come along & turn a multi-phase programming environment, where folks can be generating new code at runtime, into a single phase pipeline.
And they throw away all the type information at compile time. Sad.
|
||
|
|
||
|
rektide de la fay
@rektide
|
31. pro |
|
There is decorator metadata to attach type information, but I believe it's been more or less unmaintained & un-upgraded since mid 2017.
typescriptlang.org/docs/handbook/…
|
||
|
|
||