kaleidawave

The "coding benchmarks" should be based heavily biased on what dependencies they use etc. Reduced characters etc.

Feeling glad I got a 2nd hand air M1 (16gb+512gb) for ~400 GBP last October, rather than waiting out for this.

No idea how the processors compare, but that RAM isn't a good sign

HTML?

Just seen this, was playing with complex Fourier series yesterday. Here < 100 LOC of python that calculates the coefficients and draws the circle animation https://gist.github.com/kaleidawave/bdaf8649e7917152b6cdd624...

Mind blowing that there might be a solar system out there with a collection of orbiting objects whose final object could have square orbit

Case of the “Vacuous truth”

Just one file at a time for this preview. Eventually want to decide some customisations/options inline with tsconfig.

Thanks! I could see why the name is a problem. Especially how N rotated 90 is Z. Unfortunate a bit late, given it was free on the package systems etc :/

Naming still remains the hardest programming problem ...

https://github.com/denoland/deno/issues/1739 just crossed 4 years. if they want people to do transpiling inside their own tool create an API so we can use our own tools rather than ones behind their black box.

Would be a much better use of their time than writing this nonsensical bs

Ezno a semi compatible TypeScript compiler does effect tracking. It’s possible but you do have to handle the way functions handle parameters which is why it’s type system is different to the way tsc handles things. And for functions outside of the user code you have to know what effects are internally run. Things like JSON.stringify look pure until you pass it an object who has a toJSON method that does something silly. A little complicated to show what stringify internally does but possible if you add additional metadata to the definition files.

Then rather than marking a function as pure you instead check it is pure by looking at what effects its function type has!

Not sure but I think startup time is impeded by the fact that tsc has to parse and synthesize around 20k+ lines of TS definition files. These require a parse for hoisting, require scanning lots of comments which are only used in LSP mode and are not a optimised format to parse.

On the other hand Ezno a semi compatible TypeScript compiler can use a more low level binary format which is only one pass and whose name references are already resolved https://twitter.com/kaleidawave/status/1596445852918325250?s... . This is only really possible because it is written in Rust so low level byte and memory management is relatively simple

It’s silly how the ‘async’ function modifier got a keyword before the function keyword and the generator modifier got a symbol ‘*’ after the function keyword…

Ah I didn't realise it did that? The homepage still makes several references to lazily downloading JS?

Eagerly downloading JS is something every framework does though and many only download for the current view through code splitting for the current page. It doesn't fix the later two problems..., struggling to find any benefits above existing techniques here :/

It is true that a button's click event can fire before a client re-render. *However* if that event changes state it does have to do a initial VDOM render to make a first frame before a second one to work how to change the actual DOM and the UI. and although that click event does run it needs to be redirected to the actual event handler. That redirect needs to do downloading, parsing and hydration. So "immediately usable" and "super responsive" are a stretch here...

Qwik does use a virtual dom: https://github.com/BuilderIO/qwik/blob/3ac5665141208ccfac04f...

No defiantly not an intention to render anything obsolete. I think React will be around for a while.

Instead if you like stricter types, `.map`, and `.push` JSX and want to reduce the runtime abstraction by moving it to compile time then it offers a possible alternative to React. Haven't gone into too much yet but there is a probably a lot of React applications that are too complicated for the optimiser to work :( and there it won't be an alternative.

Lots of great alternatives to React these days as well which I also want to promote!

Thank you. Just checked out the Bagel post (https://www.brandons.me/blog/the-bagel-language) and it looks really cool. Identifying pure functions (whether that is by syntax annotation or from synthesis) is a really good idea, gives me some ideas for doing function inlining in Ezno. I like the "Misc niceties" section, a few of those may of may not be on Ezno's todo list :)

The automatic / inferred generic restrictions is quite cool. https://hegel.js.org/ got there before me! Basic restriction modification is quite simple e.g. `(x) => Math.sin(x)`, x wants to be a number so can add that restriction. It gets more difficult with higher poly types. `(someObj) => Math.sin(someObj.prop1.prop2)` requires modifying not just `someObj` but a property on a property on it. And `(x, y) => printString(x + y)` requires doing even more complex things. But its definitely possible!

Recommend the brilliant Johnny Harris video about this issue https://www.youtube.com/watch?v=NY8Rv6PaXVI

In short not only is a collision bad but it could create a chain reaction leading to billions of small objects flying around in the orbit forming a impenetrable barrier that bars further space travel and more importantly putting other (actually useful) satellites at risk