suplexer

We need much more of these type of direct call outs! Shed light on the AI grifters so the community knows what projects to avoid like the plague.

It's embarrassing to be honest. The eolix guy couldn't even respond to the very first piece of evidence by the Photopea creator, before spewing some clearly and poorly generated, LLM response. So of course he'd resort to issue-closing, title-changing, banning, bullying and then Whatabout-ism.

Beautiful rainbow of moral failures...

Goodluck with that "internal audit" buddy. The internet never forgets.

A side note: I wonder what pre-Microsoft Github would do in such cases. I don't think I've ever seen modern Github take action against any clone repo with legitimate copyright issues.

Porting to native disrupts the previous ecosystem. It's amazing when users of your software can modify it to fit their needs, in the same language.

Adding another barrier in the name of performance is justified only if your project actually hits hard limits. It's annoying when I hear these claims of JS is slow, then look at the code in questions (if it's public).

The code always has immediate problems. In some sense, maybe it is better to just switch languages then to challenge these assumptions.

Yes, only in that it's often easier to just rewrite it in a lower level language and be done. No, if you consider the time and effort for a bug-for-bug port.

They could have rewritten the Typescript compiler in better Typescript. I just peeked at random files in last TS compiler branch before the port (v6.0.3). Simply put, I would not have written it that way. That style would surely hit it performance cliffs.

If anyone from the TS team is lurking, I can be paid a reasonable consulting fee to talk lol. No free work from me, I'm already too busy with my own language.

Or contract me to match (or maybe even exceed) the Go port.

But I suspect Anders and the TS team are plenty satisfied with their Go port. So maybe, it'll be more of an educational adventure.

The point of an asm.js style is so that you can eliminate almost all of the dynamic variance so that ahead-of-time compilation is possible.

Asm.js can be transformed into whatever PNaCL takes to get even faster - there is no limit. Especially if someone were to say, write new enchancements to asm.js to restrict it even further.

It will be hell write that in pure JS of course, but that's beyond the point. You can use all manner of (unnatural) signals/semantics to indicate, for example, in-depth type information about a language construct.

It is hard when dynamic language users do very dynamic things. My whole point is, you have to be doing some very, very dynamic things to get into the 10x plus range in most cases.

For the Python, Ruby, Perl family of purely interpreted languages no doubt 10-100x is normal. For quality, lower-level JS no way. In those cases, they are usually reaching into features inaccessible to a JS runtime. It could also be due to a VM performance bug/limitation. As a compiler/transpiler guy, I could connect those gaps if shown the code - in variety of "creative" ways. ;)

Yes, much faster. Conversely, I don't think Anders is claiming his Typescript implementation to be particularly fast - he believed JS wasn't fast enough to solve his performance problems. Which isn't true.

The TS compiler has always been slow. There are/were several TS-in-Rust/Go compilers long before Anders announced and released the offical Go version. I've also been writing transpilers since before TS was a thing, the TS team could have made it work in JS.

But it's often easier to switch to a language that gives you that structure/performance for free. "Free" in that large companies have the budget to afford a bug-for-bug port/rewrite.

Java/.NET by default have an edge due to being less dynamic than JS and having a more mature VM. Both of these qualities are not static properties, as in: 1) You can programming JS in a style that is stricter than standard JS and even Java/C# 2) You can run JS on other virtual machines, including Hotspot VM (transpile to Java Bytecode)/GraalVM.

This stricter style js (asm.js) was the precursor to Webassembly; it still exists. You can also be very meticulous to craft monomorphic code through your project to get great performance.

Almost no one does this, cause it's harder, yet people still claim to know the limits of JS performance.

The AI Rust -> Typescript will provide the default structure V8 needs to run fast.

In Google sheets case, because they are being processed through two separate transformation pipelines, then they compare the result from different runtime environments (i.e. server vs client). The automated translation via J2CL is surely producing very suboptimal code in JS versus Wasm. The end result doesn't matter if it's incomparable.

In Amazon's case, are they using specialized vector instructions (i.e. SIMD) in the Rust version, different graphics apis, specialized algorithms? They just said it's 10 to 25 times faster with no code. Ok...sure.

I don't mean to say you should, I just wanna stress that it's important to be critical of claims others make without evidence.

Anyone can claim anything is true!

"But why bother when you already have the speed up? And why didn't TypeScript deliver it in the first place?"

That's a question for them.

As someone who is creating a serious programming language whose bootstrap compiler is currently in (a restricted form) of JS. I am immensely skeptical of their claim on all fronts.

I bet if you took the AI-generated Rust codebase and another 120k to reverse it right back to Typescript you'd get keep most of that same speed up!

1) Google Sheets use case

Long story short they are comparing the performance of server-side Java to client-side JS (Java transpiled through GWT/J2CL). So something like: Java -> Hotspot -> native vs Java -> GWT/J2CL -> JS -> V8 (in Chrome) -> native

Apples to oranges.

They then used J2CL (I presume, not clear from the article) to port Java to Wasm and eventually got around 66% of the server-side Java performance. The Wasm performance story also was nowhere near straightforward - hence the immense efforts spent on optimizing WasmGC and validating the transpiler output.

The root of the problem is likely the GWT/J2CL transpiler output. There shouldn't be that much of a peformance drop off between to high-level languages if you're transpiling with speed in mind. I bet there are probably lots of expense runtime checks in the generated output, among others things.

2) Amazon Prime Video use case

Blog seems mostly fine on the surface. But my complaints are always the claims about the limits of performance one could get from a JS-based system - especially in environments where you can call out into native audio/visual libraries.

"In those experiments, code written in Rust and compiled to Wasm was 10 to 25 times as fast as JavaScript."

What does the JS versus Rust code look like? Are they using the similar libraries/graphics apis/techniques? Did they exhaust every possible low-level tool in JS (Worker Threads, SharedMemory, etc). I feel there are a also rainbow of optimization opportunities available if one controls V8 and the underlying C++ stack.

Not that their eventual Wasm architecture is bad per se, it's just layering Rust+JS -> Wasm/C++ is much more complex than simply JS -> C++ back and forth.

As a side note, it very annoying that SIMD was taken out of development for JS. Big TC39 wants wants JS to fail.

https://github.com/tc39/ecmascript_simd

Yea, it does require great discipline but I've been surprised by the lack of tools to help with writing high performance js.

Surely there can be some middle ground were you just want some small part of your app to run faster without including another tech ecosystem (locked within a Wasm sandbox).

It's late for me. I've commented plenty on this thread but I'll revisit this particular comment tomorrow with my assessment of these two blog posts.

Just skimming the Google Sheets wasm one, looks like pure technical debt chaos so I'm already plenty suspicious.

Suffice it to say that all these pseudo-technical but actually marketing blog posts should be taken with a truckload of salt. Apples-to-oranges unless proven otherwise.

Instead of writing utilities, libraries, guidelines, build-time transformations, etc to help (or even) force JS devs to stay on the happy path, the industry "experts", large companies, and thought leaders chose to go the exact opposite route with React and adjacent tools. The results speak for themselves...

Even the V8 team gave up on documentation: https://v8.dev/blog

There is nothing stopping JS devs from working with byte buffers with near-zero overhead.

JS has Web Workers in the browser and Worker Threads module in nodejs for parallelism. Most apps don't need to them to be fast, but many slow apps would be less slow if Workers were used more often.

Low average skill unfortunately includes them as well. I say unfortunate because, like the build tool developers, they serve an outsized audience with their poorly written apps.

But, to be fair, large tech corporation have many other roadblocks to better software quality, well before you reach testing individual skill levels. Moral decay and office politics to say the least...

Or just write faster JS using it's lower-level language features. Nothing about whatever collection of build tools the JS ecosystem uses "requires" rust/zig/c++/go for performance. It's a closed text transform problem.

The native languages are easier to get decent performance for sure but, braking the entire ecosystem and a generation of future contributors, for what should realistically be single or low double digit percent gains is not worth it.

To all reasonable software developers out there, please don't listen to the prevailing groupthink. Javascript (the language) has many semantic problems but speed (from the VM) is one of it's best features! Like, you have to be writing some questionable code in very questionable styles/dialects to have a 10x (or more!) slowdown vs native.

Obviously - using native non-portable language/compiler features - you can reach some worthwhile speedup for certain workloads. But I have yet to see any of these "we rewrote our build system to Rust" type blog posts utilize any them.

It's always the apples-to-oranges marketing style drivel. Just because the some assertion comes from a very (very!) large company or well-known community member doesn't mean it is true.

In all my years of lurking this site, this port mortem is one of the few articles on this topic I trust: https://zaplib.com/docs/blog_post_mortem.html

This argument can also be applied to the separate, startup time performance axis. Though there are more tradeoffs there.

A programmer that can write a small efficient weather app in assembly can also easily do so in JS. Especially writing it in a c-style imperative way.

Modern Javascript has many low-level facilities and a great VM. You're conflating the low, average skill of the JS community to what the language is capable of.

There's no need to even contextualize your argument, it is the reality. The whole point of spending such heroic efforts on a fast VM implementation is so that even faster peformance becomes a niche use cases.

But alas, many unskilled programmers use Javascript to make useful things - sometimes beyond their ability. Even a state-of-the-art virtual machine like V8 cannot hope to fix that class of peformance problems.

I will withhold my opinion on the "faster than compiled languages" part though. ;)

Not that we care at all, but for your own good, it'd be best to follow experts in your field/hobby on Twitter. You never know what inspiration might hit you!