On: Tsc-ts: TypeScript written in TypeScript

[tallowen]

The back and forth between writing tools in javascript and go or rust seems like it's in an unstable equilibrium right now:

- Go / Rust: It's easier than ever to rewrite existing tools in more performand languages

- Javascript: The v8 runtime for vercel or cloudflare workers is a much cheaper way to run certain workloads (e.g. conversational agents) than running a heavy weight vm. See just bash as another example project for taking advantage of this (https://github.com/vercel-labs/just-bash)

I'm curious to see what happens!

[cxr → tallowen]

That's because there's no such thing as a "performant language". A programming language is inert. It's notation. Programming languages don't get run. Binaries do.

The only thing that can be compared are language implementations. That a given implementation, such as GCC, has an excellent code generator that emits efficient code is saying something about how great that code generator is. It's not that the input language is inherently "performant"; C programs compiled with GCC and Clang are fast. The same program compiled with My Toy C Compiler, with none of the work that has gone into LLVM and the GCC backend, is going to have different runtime characteristics.

[jeswin → cxr]

> That's because there's no such thing as a "performant language".

That's not true. Many languages make tradeoffs for performance. There are many things in JS (or Python) which make optimizations difficult and sometimes impossible. For example - obj[key] = "haha".

[cxr → jeswin]

The fact that language designers take into account things like efficiency (or ease) of potential implementations doesn't change the fact that performance is a property of the implementation. Languages don't perform. There's no such thing as a performant language.

[ameliaquining → tallowen]

Running Rust code in V8 via WebAssembly works today, though the tooling could benefit from a bit more polish. Go sort of works, but less well; IIUC fixing this would require adding more features to Wasm, most especially interior pointers, so that its garbage collection behavior can be made semantically compatible with Go's.

[CharlieDigital → tallowen]

    > ...than running a heavy weight vm.

Serverless containers are a thing (GCP Cloud Run, Azure Container Apps) and seems like the right analogue.

[ameliaquining → CharlieDigital]

Those offer a more streamlined developer experience than traditional cloud VMs, but still require just as much compute resources (apart from being able to scale to zero if you can tolerate cold starts). E.g., you still have to choose how many data centers they run in and which ones, which is laden with tradeoffs, whereas every Cloudflare Worker runs in every Cloudflare DC, for free.

[aftbit → ameliaquining]

Cloudflare workers don't have cold starts? How do they manage that? I thought they'd still have firecracker or something underneath. Are they trusting the V8 sandbox that much?

[ameliaquining → aftbit]

Yes, they're trusting it that much (https://developers.cloudflare.com/workers/reference/security...). This is nonzero controversial. Of course, spinning up a new isolate takes more than zero time, but it's quick enough that handling it in parallel with the TLS handshake eliminates most of the cold-start time (https://blog.cloudflare.com/eliminating-cold-starts-with-clo...), and also it's less likely to be needed if there's already an instance running somewhere (https://blog.cloudflare.com/eliminating-cold-starts-2-shard-...).

[CharlieDigital → ameliaquining]

Cloud Run scales to zero and can handle concurrent requests. I'd make the case that as long as you point a scheduled HTTP request to the Cloud Run instance and keep it "hot", handing an incoming request off to a thread sitting in a thread pool is always going to be faster.

[ameliaquining → CharlieDigital]

You can also do that with Cloudflare Workers if you want.