I suppose my comment sort of implies this. I think the naive knee jerk reaction is that if you can spit out perfect machine level code against a specification, then logically being closer to bare metal would help with performance. However, without knowing the details of how things worked it is tough to say whether it is truly "reasonable" or not.
But more importantly, the Typescript team themselves [1] picked Golang mostly out of ergonomics and ease of porting at the time. It is becoming more increasingly more to "taste" what ergonomics means. Notably, they did not pick it because they believed it to be the fastest option. But speed was on the mind, giving way to ergonomics and ease of porting. At least, this is my read.
Very interesting. With rust's ocaml heritage, I'd imagine a straight port from typescript would be simpler and more idiomatic than a port to go. I guess not.
pretty much most nontrivial programs need to have a different shape to fit into the rust mindset.
For example i wrote a digital logic simulator. The last step involved a linking step to turn all indexes into pointers, once the component graph is generated in full and becomes stable in memory. The simulator just chased pointers.
In rust all of that would have either had to keep using indices, be highly non idiomatic by boxing everything (and slower), or implemented in unsafe rust.
If I have to write a lot of unsafe rust, then i would actually switch to cpp because unsafe c++ is easier to get right than unsafe rust
The notable thing that these LLM-generated ports aren't doing is _rewriting in Go_. TypeScript 7 is a lot faster than the JS/TS-based version 6, but memory use is a major bottleneck.
However, it mostly represents a mechanical port of the old codebase to Go. What I haven't seen anyone do is try a true rewrite in Go optimized for performance (whilst keeping a strong emphasis on readability).
> you can spit out perfect machine level code against a specification
Typescript team explicitly mentioned the lack of Typescript specification as one of the reasons to choose Go. Typescript as the language is defined currently by its compiler which was Javascript based. Go port is as close to it as possible while Rust would be harder to reach fully identical behavior.
> then logically being closer to bare metal would help with performance
Once you move beyond interpreters, performance is mostly a property of how much effort you want to put into profiling and optimization, not any specific properties of a programming language (YMMV of course).
I agree, but certainly language constraints or features make analysis easier (and some analysis which was previously impossible now suddenly is) which in turn unlocks/enables a whole world of optimisations the compiler can do for you!
Was it ever a reasonable choice? At the time the choice was made the tooling ecosystem was already split between Rust and JS, and by putting TS in Go they chose to split it three ways. Why not split it 4 or 5 ways then? The pressure will always be towards less duplicated work.
The only real choice of language to build the next generation of JS tools in is JS. Anything else is a vote of no confidence in ourselves.
It's ok for a language (JS in this instance) to be good in a domain but not good in all domains. Pulling a language in every direction forces it to make compromises that hurt its applicability in specific areas.
The case against JS was specific: data marshalling neglects the Web Workers performance boost for an "embarrassingly parallelizable" project. And it was stated clearly.
So for context my beef with them is that they didn't try. I think you're being very "hand wavey" about why JS isn't a good host language, just as they were.
If the argument is "we need to show a 10x boost in raw throughput" then I think we first need to have an argument about why throughput is the right metric as a target for optimization. Throughput is the critical performance measure of a batch processing architecture. IDE's, like web UIs, "feel fast" when they're responsive, which is to say when they can start giving the user access to useful output (and interaction) at the soonest moment the program could possibly be ready to do so. In web perf we might measure this as INP: time from Interaction to Next Paint.
JS won't be winning prizes for throughput, no, but if we completed the move away from a batch processing mindset to an incremental recomputation mindset, and at the same time switched to measuring responsiveness metrics like INP, suddenly the perf characteristics of JS seem a lot more helpful. It's the closest language to the DOM, so when your IDE's interface is built on web technology you'll optimize INP by keeping the data layer in JS: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
There's an even stronger reason than the DOM though to see JS as the "native" layer for perf: plugins. An IDE's selling point is integration, and users want to extend their IDEs by writing Javascript code. Like it or not, JS is the most natural and highly-performant native kernel language for a system of JS plugins.
You may have missed the project history, this _was_ implemented in JS previously. I don't think they were interested in porting it back to a language it was originally written in.
I know my history just fine. What I'm saying is: you can't say that it means that JS is a bad language to write tools in. That's would be like saying "our design had bad perf and it was implemented as JS, therefore no design implemented in JS can have good perf". I hope we agree this would be a faulty deduction, or at least an unfounded one.
Language and compiler design/ implementation is very much a human task. There's lots of nuances to consider. I doubt they want agent spaghetti code in their codebase either.
It's extremely useful if your distribution platform is the web. However, I find it much more valuable as a type checker than a compiler. I use TypeScript extensively (in several projects) for defining schemas types.
For example, in the Breaka Club (https://breaka.club/) editor, which is not presently exposed to kids yet, we define behaviors for characters, props, mosaics (terrain tiles) and items in JSON. But the JSON has type checking and real-time completion as you type. Not naive property auto-suggestion, we have effect types and they're context aware in that you can refer to targets introduced higher in parent constructs of the JSON — and they're fully type checked. If you refer to a target that does not exist in a context, it won't validate and you cannot save the schema.
We use tsgo for development, but the editor (runtime schema validation) is presently stuck on TypeScript 6 because there's no WASM support.
Now, is it nutty that we're using TypeScript for JSON validation? A little. But it's extremely powerful. We're going far beyond what's capable with Zod or ArkType.
Theo is making a new twist on the idea of IDE which hosts the application itself. I'm sure there's going to be a video about it soon. But the idea is to embed the whole compilation and type-check in wasm in the browser which then runs the app immediately, as the agents edit the code.
I'm assuming they mean because it doesn't need a garbage collector or much of a runtime at all. You can target direct to WASM and use I guess WASI, while Go brings with it a garbage collector and so on.
Wasm is a first-class target for Rust, which produces faster and smaller Wasm binaries. My understanding is that you need to use TinyGo to reasonably target Wasm with Go.
Go having a garbage collector isn't necessarily bad, since Wasm has GC, but I think Go's GC can't easily use Wasm GC because Go has interior pointers.
With the caveat that Go cannot use WASM GC, because it is still a MVP and it does not support internal pointers, so languages like D, Go and C# have to keep shipping their own implementations.
I’m not saying it doesn't work. I’m saying it’s a waste of resources and won’t gain widespread popularity. The current trend is porting source code to languages that generate native code.
I dislike the WebAssembly advocacy of some folks, where they act as if there weren't similar attempts all the way back to UNCOL in 1958, and even in recent history, seem to only focus on JVM, while ignoring the CLR and BEAM.
However, there are indeed some cases where it does make sense since we have it around anyway, and one of them is running the Typescript compiler in the browser, now that it is written in a compiled language.
A waste of what resources? Other people's time? That isn't up to you to decide. I think your comment is a waste of resources. But how you spend your time isn't up to me. And how wasm people spend their time isn't up to you.
> The current trend is porting source code to languages that generate native code.
Cool story, but without wasm, how are you gonna run that native code in a browser?
GC doesn’t affect performance (at least visibly), memory allocations on critical paths do. Moreover, Rust ARC may cause memory fragmentation and perform worse than a GC.
Writing Rust, Zig, or Go, you would still control memory manually, where it matters.
GC absolutely has performance costs, even with minimal allocations, because tracing collectors must scan live objects. This is exactly what this post says. Don't know if its really improved over time in real world cases.
It does have an impact. Discord blogged about unavoidable GC delays in go that occurred because go needed to traverse live memory, their only option (in go) for reducing that pause was to reduce the size of their data set.
Not everything has to be ARC though and arenas are strictly better than GCs lacking synchronization issues for allocation and not needing any scanning for deallocation.
It depends on the workload. ARC can be more expensive than tracing GC, especially with heavily shared objects.
But my main point was that the presence of a GC has nothing to do with how close a language is to the metal. Memory management strategy and low-level capabilities are two separate things.
Rust could just as well have an optional tracing GC for shared ownership instead of ARC, potentially improving performance rather than reducing it. Having a GC doesn't inherently make a language slower.
Yeah but let's be honest; GC languages (Go, Java, C#) usually are slower than systems languages. Systems languages just give you more, low level control over the computer from within your program. You can use that control to improve performance. Eg, you can control data locality, memory access patterns, the emitted assembler, and way more stuff.
Of course you're right - if you misuse arc, you can make your program slow. So don't misuse arc then. Rust gives you lots of options for structuring memory. If you choose badly, that's on you.
I'm doing this right now with Codex. It's currently working on porting the Binder.
7-11 phases to go and so far it looks like it might only cost $100. I'm focusing on efficient execution strategy minimizing token in/out, turns, and rework.
Will prob post up something interesting when it's done.
I thought I would share. I don't see this discussed much and thought it was interesting (it's my own post) when doing some introspection today. Is it from moving up in my career and I just type a little less? Has the movement from typing in a code editor all day to writing more prose helped? It's hard to say for sure, but a fun observation. :) I am curious if anyone else has experienced the same.
I have experienced exactly what you describe here. I am battling RSI for more than a decade, it has nearly cost me my career. Like you and many others, I have tried all sorts of things. I got the most improvement from:
- An ergonomic split keyboard, with a custom layout
- An ergonomic chair and desk setup
- Relearning to type from the home row
- Using dozens of custom shortcuts to reduce awkward hand movements
- Yoga and stretching
- Building a more active lifestyle with total body movement as a focus
- Improving diet to reduce inflammation
Despite all those interventions I still suffered debilitating hand and wrist pain, which eventually crept into my shoulder blades and back muscles. Doctors and physios were useless or clueless. One doctor refused to acknowledge that RSI exists. No amount of physiotherapy helped.
Using LLMs to do (almost) all of my coding tasks has reduced my RSI pain and stress by half or more. I feel so much better and healthier. I still have pain, and I still have to work hard to manage it, but I will never go back to writing everything by hand.
Thank you for sharing, and for reading. Wishing you good health.
One thing that helped me was to avoid chords with one hand.
In the past, I’d twist my left thumb for a single handed ctrl-c or the right fingers for shift-; (to type a colon in vim). Similar for ctrl-a and ctrl-b.
I switched to a single F12 key for tmux, semicolon for vim, and either use specialized macro keys for cut/paste or got in the habit of using two hands for them.
I've never seen anyone else do this, but I press left Ctrl with the fleshy pad under my pinky. So it's just a small flick of the wrist instead of a large rotation I'd need to use the finger.
Long ago I worked on a project where the whole team was so productive I gave myself cubital tunnel from typing so fast for so long. I'd feel needle jabs in my forearms randomly. Like while standing around. Doctor recommended surgery.
Avoiding surgery involved months of finger stretches, forearm massage, 2 keyboards and 2 mice at different elevations, typing with my hands hanging slack like a zombie. It worked. But, even typing this out 20 years later I can still feel the RSI hiding in the shadows. Since then I've avoided RSI by spending 10x more time thinking about code than typing it.
All that is setup for: There have been many times recently where I've thought "I know exactly what I want this code to look like. But, damn. That's going to be a lot of keypresses..." The effort is nothing. Risking nerve damage is the concern.
In those cases I have been thrilled be able to tell AI exactly what to make, how to refactor it, how to clean it up, clean it up more, yet more, still not done. All in less than 10% of the keypresses that would have been required to type it by hand.
Thanks for sharing. I feel the same way but did not express it in my post. I've sat down to do some side projects in the past and realized that even though my mind has energy (I hear this can be rare.. but it is true for me!) the hands would be tired. I've probably completed more side projects this year than in the last few, even if the total amount of time spent on them is higher.
Like you, there was always this specter of "don't overdo it".
I'm not saying this to be snooty or whatever, but RSI is also solvable via a custom keyboard or learning Vim motions (or both). I had really bad RSI and it totally went away after the combo of learning to type properly (which you mentioned in your post) and switching to Vim full time. Vim motions reduce the amount of stretching you need to do by a LOT. Snippets also helped. I am of course talking about in The Before Times.
I am saying this to be a little snooty. Your take is very dismissive to a large group of people whose experiences you don't know. I agree that split/custom keyboards and vim are awesome; I have used them for 25 years. But the idea that you can reduce RSI treatment and everyone's situation to something so simple just isn't true. It is fine to recommend solutions to people who are suffering, but to dismiss their problems as being "solved" comes across as basically calling them stupid for not helping themselves.
I know you didn't say that, and you softened your language, but many people with disabilities or chronic conditions have to deal with everyone they share their problems with telling them their "cure". Its exhausting.
Thanks for saying this. I already use Vim (in my browser too). I've used it on and off in an editor as well. I've tried reading books (like I mentioned in the post) which is something you only do when you're truly desperate. For some of us, our body will only allow so much.
I am sure the OP was just trying to help. I, too, when I started having such problems chalked it up to "surely some adjustments will help". And they did! But it never quite ceased.
First off, I'm not going for a "gotcha" reply here, I hear all of what you said and I don't see your reply as adversarial.
> but to dismiss their problems as being "solved" comes across as basically calling them stupid for not helping themselves.
Yep, I did kind of say that now that I re-read it. It does come from a point of aggravation (again, in The Before Times) of people expressing, with pride, how little they know of their tools (editor and VCS mainly). And for sure, they probably made/are making a lot more money than I am, so I guess they win?
I must take exception, though, with you bringing up disabilities. This article never mentioned them, so I didn't either. This is a whole other can of worms, but I will say that after working with a couple of people who have pretty extreme disabilities, there are some extremely good (non-"AI"... although of course we know they have some sort of "pre-AI"-AI in them) tools out there are extremely good, and they rocked the f^ck out of them (yes, I intentionally used "extreme" three times there).
So ya, I guess I was being a bit snooty as I was always annoyed how few people learned their tools. Not even just their tools, but their programming language of choice as well! It's all a spectrum, of course. But, as I must admit, it turns out they were right so... ¯\_(ツ)_/¯
Also, as far as exhausting goes, I've never been more exhausted than trying to follow what these awful f^cking companies are doing.
It's generally also just less typing if you are using long running agents, you can input the goals, steer it a bit then go for a nice walk and check in again on it in 30-40mins. I hope we can normalise this workflow as it will be much better for everyones health and longevity in the field.
IMO LLMs are the best thing to happen to coding in my ~15 years of being in the game.
I wager they have probably added on another 5-10 years to my engineering career as I was contemplating getting out before they showed up.
Have also been convincing some friends that have "gone woods" over the years to put the woodworking tools down for a day or two and give them a go. So far so good, a few folks have found the spark again and it's been awesome to see them make digital things again too.
I'm so confused at how people think that this will be a reality, like, what kind of boss would look at this and go: yep sure my people will only work for a few minutes here and there, let's keep paying them their huge 6 figure salaries ??
The walk is usually work too, just instead of staring at the screen and trying to think I take a walk and actually think. So when I get back I can provide input to the robot that will result in meaningful output.
Companies that pay people to hit enter instead of using auto-approve/bypass are going to lose to companies that pay people to think and produce results, regardless of how much time they spend in front of the screen or how many prompts they input.
Before I learned any programming skills, I worked with a bunch of great coders and learned a lot from them. I remember being impressed with the guy that would log on to start his day, but then sit back and have some coffee, M&Ms and read the Calvin & Hobbes comic strip from the newspaper (yeah this was long ago.) When I asked him about it, he explained that it was one of the important aspects of the life of a programmer to be aware of: if they are walking around the office with a distracted look on their face, you still want to sort of "knock" before walking right up and dropping a big issue or request on them, they might be doing the most difficult work of their day!
I eventually learned to code and would often find it to be my favorite part of the job--the looking out the window and planning the attack phase.
That's been my experience as well. I remember the pain from the keyboard and also doing too much clicking when making wordpress websites. Now that I do more agentic development, I type a lot less and am working to dictate more with voice also.
Nah, we won't be engineers in 2 years, we'll be product steward/solution architects/etc, and our job will be to be liability lightning rods and customer/c-suite facing puppets for agents, while trying to add a small amount of taste/style into the outputs.
unless the CFOs can figure out the cost benefit of humans vs robots it might happen.. They might start to question the value of Steve’s $50k/month Claude spend.
