> We write a lot of TypeScript at Cloudflare. It’s the lingua franca of software engineering.
This scares me more than Im able to admit, typescript sucks and in my opinion its way worse than the more commonly used lingua franca of computing, which I would attribute to C. At least C can be used to create shared objects i guess?
I used to dislike JavaScript a lot after learning it and PHP, then using languages like C#. Then TypeScript came along making JS much easier to live with, but has actually become quite nice in some ways.
If you use deno as your default runtime, it's almost Go-like in its simplicity when you don't need much. Simple scripts, piping commands into the REPL, built-in linting, testing, etc. It's not that bad!
Of course you're welcome to your opinion and we'd likely agree about a lot of what's wrong with it, but I guess I feel a bit more optimistic about TS lately. The runtime is improving, they've got great plans for it, it's actually happening, and LLMs aren't bad at using it either. It's a decent default for me.
You look at libraries like Effect, and it's genuinely incredible work, but you can't help feeling like... Man, so many languages partially address these problems with first-class primitives and control flow tooling.
I'm grateful for their work and it's an awesome project, but it's a clear reflection of the deficiencies in the language and runtime.
I think it sucks because it transpiles to JavaScript and is an interpreted language. Users have to resolve the dependencies themselves and have the correct runtime. I definitely prefer my CLI tools be written in a compiled language with a single binary.
I agree, though one cool thing arriving lately (albeit with some major shortcomings) is the ability to compile binaries with deno or bun (and nodejs experimentally, I think).
With Go you can compile binaries with bindings for other binaries, like duckdb or sqlite or so on. With deno or bun, you're out of luck. It's such a drag. Regardless, it's been quite useful at my work to be able to send CLI utilities around and know they'll 'just work'. I maintain a few for scientific data processing and gardening (parsing, analysis, cleaning, etc) which is why the lack of duckdb bundling is such a thorn. I do wish I could use Go instead and pack everything directly into the binary.
you can already "compile" TS binaries with deno, but it'll include the runtime in it and etc. so it'll take some disk space but I think these days it's less of a concern than before
Personally I haven't felt like Typescript has bought me enough over JavaScript to use it in contexts that I don't have to. I have to use TypeScript for work, and it's "fine", but I guess I haven't found that it helps all that much.
I'm not sure why; I guess it's because the web itself is already really flexible that I find that the types don't really buy me a lot since I have to encode that dynamism into it.
To be clear, before I get a lecture on type safety and how wonderful you think types are and how they should be in everything: I know. I like types in most languages. I didn't finish but I was doing a PhD in formal methods, and specifically in techniques to apply type safety to temporal logic. I assure you that I have heard all your reasoning for types before.
It’s fast in terms of a response from a LLM model - but it is part of the system I am quite active on at the moment to ensure it’s performant as possible
Hi, no it doesnt, this example of course breaks using temporary registers used after the optimisation. But thats why peephole is a fallback to ir optimisation, since they are only local.
I honestly didnt think of this possibility while building the optimisation. Since constant folding is done as an ir pass i will remove the peephole pass, thanks for noticing :)
Your site is the second one I've seen using the JetBrains Mono typeface -really easy on the eyes, even when set light grey #eff1f5 on a very dark #07080d background.
Assembly requires way more work than compiling to, say C. Clang and gcc do a lot of the heavy lifting regarding optimisation, spilling values to the stack, etc
I have a couple interpreters I've been poking at and one uses 'musttail' while the other uses a trampoline to get around blowing up the C stack when dispatching the operators. As for the GC, the trampoline VM has a full-blown one (with bells-and-whistles like an arena for short lived intermediate results which get pushed/popped by the compiled instructions) while the other (a peg parser VM) just uses an arena as the 'evaluation' is short lived and the output is the only thing really needing tracking so uses reference counting to be (easily) compatible with the Python C-API. No worries about the C stack at all.
I mean, I could have used the C stack as the VM's stack but then you have to worry about blowing up the stack, not having access (without a bunch of hackery, looking at you scheme people) to the values on the stack for GC and whatnot and, I imagine, all the other things you have issues with but it's not needed at all, just make your own (or, you know, tail call) and pretend the C one doesn't exist.
And I've started on another VM which does the traditional stack thing but it's constrained (by the spec) to have a maximum stack depth so isn't too much trouble.
This scares me more than Im able to admit, typescript sucks and in my opinion its way worse than the more commonly used lingua franca of computing, which I would attribute to C. At least C can be used to create shared objects i guess?
reply