Typescript wins in terms of training data IMHO, by which I mean that the training data is large enough that AI does great with TS, and the language is (IMHO) superior to Python in many ways.
I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)
It turns out that volume of training data isn't the most important thing. Elixir beats Kotlin and C#, which beat pretty much everything else. Kotlin is probably the sweet spot for most things.
Kotlin has the combination of JVM ecosystem, overall good performance and agents are good at writing it. I'd argue that it's a better default choice to reach for when working on non-frontend code than Go, though Rust and Python still have use cases.
Haha thanks. Funny thing is, I’ve been a long time Python fan, learning it in 2001 and using it extensively for a long time. But then I learned Clojure, Typescript, and recently Rust and I’ve found Python to be quite flawed. But it sure does have a cult following.
:) I use Python as well-- so i am not anti-Pythonic in any strict sense. However, I don't like culltification of technology, be it Python or whatever else. Have you tried F#? It gave me a very good experience.
Only briefly for fun (and OCaml too but very long ago). F# does seem like a language I feel I could really like, though.
I’ve tinkered a little in Gleam and Elixir too. Elixir was incredibly enjoyable, and Gleam is a wonderful language that I wish I could work with more, but I don’t really have a use case for it and nobody will pay me to write it…
Back in 2009, I also spent a few months playing with Factor (before switching to Clojure because despite Clojure being niche, Factor was even more so). It was an interesting and somewhat mind bending experience.
Deleted from the current head/trunk of the repo, ie the deployed code.
Deleting "from my codebase" doesn't imply deleting it from history or backups. Just that the code isn't present for future edits or deployments.
The way you're talking, it sounds like you never delete code from your codebase. Do you just comment it out when you change a line to something else or replace a function with a new one? Just add new files?
It’s GLM 4.7, GPT OSS 120B, or llama 3.1 8B so not exactly the latest or best models.
But GLM is good enough for many small tasks, certainly enough to get a taste for Cerebras’ high speeds!
[edit: actually that’s just their general models, I can’t see what Cerebras code offers. It was Qwen-coder when it launched but I don’t know what it is now. I think GLM 4.7 but I’m not completely sure]
> It was Qwen-coder when it launched but I don’t know what it is now.
This was also what I used at the time, the Qwen 3 Coder 480b on Cerebras. Worked great and was so stupidly fast it made me realize that if the hardware can be at that level and commercially available (say in a 5~10 years), for that price, then we will have entirely new bottlenecks. Human review at the pace it was going is completely impossible.
For small enough tasks with tight enough workflows, you can have it right now. Ie if you can constrain the task to work well with GPT OSS 120B/llama 3.3/qwen 3, then you can get upwards of 600 TPS on groq and up to 3k TPS on Cerebras.
Those models aren’t comparable to Opus, or even weaker models like MiniMax, but for certain task (focused context and prompts, strict workflows, single purpose requests) you absolutely can use these models and get insane speeds.
I’ve been programming C++ on and off for over 20 years and have had my moments where I’ve checked on godbolt to make sure classes got devirtualised.
This year, I’ve finally taken the plunge to properly learn Rust (I’ve used it for little things over the years, but never for anything particularly extensive) and one thing that jumped out at me is that you don’t need to think about it, because Rust makes it explicit: everything is statically known unless you explicitly ask for it to be virtual.
[edit: since it wasn’t clear, I mean polymorphism in rust is static by default while in c++ static polymorphism requires relying on the compiler or using templates, otherwise polymorphism is via virtual]
It’s was a little annoying at first because some things don’t just work automatically, but once I got used to it, it was wonderful to never have to think about when the compiler might do something. You also don’t need dynamism most of the time.
I still like tinkering in C++, but I do find you need to know too much about compiler heuristics.
In C++, you can’t have an interface without virtual unless you jump through hoops.
In rust, you can have traits without dyn.
That is, static polymorphism is the default in rust, while in c++ you must jump through hoops for it (eg, see the excellent EnTT’s static polymorphism companion library).
I feel like it’s still missing the point. In a discussion about devitalisation, I thought it was interesting that it’s not something that you have to think about in Rust, while in C++ you do.
I don’t see how that’s relevant when discussing specific language features or semantics, nor how it’s relevant to what I said about Rusts static polymorphism. Nobody is claiming C and C++ didn’t make great contributions or that they aren’t still heavily used.
Fair enough. I didn’t mean to push Rust, which is why I removed the last statement from my original comment. I was really just trying to make an observation that devirtualisation isnt something I need to think about in Rust (you could make an argument that dynamic should be the default and C++ got it right, and it would be an interesting, but different, discussion). I thought that was interesting, as a language design enthusiast.
In the OP, there are ten test cases. Some devirtualise. One only on clang, another only on GCC. In Rust, polymorphism is always "devirtualised" unless I say "no, actually, make this dyn", and in many cases, that's actually perfectly fine. It feels like the rational default, you only pay for the dynamic support when you need it. I don't dislike C++, but sometimes it gets exhausting having to remember all the situations where the compiler might do this or that, or I have to write far more complex code via templates or other techniques to get the behavior I want (sure, its been made easier with recent C++ versions, I admit I'm still on C++20 and even then not all of it; originally because compiler support was patchy, now because I just haven't used C++ as much lately). Its that difference that I thought was interesting.
While I certainly like parentheses highlighting and rainbow parentheses, I've programmed Clojure without syntax highlighting and while it’s not as nice as it would be with, it’s fine.
I’ve also written C++ and Java in Notepad long ago. Not ideal, but hardly a problem.
Agreed. Reviewing code takes so much longer and is far more exhausting than writing it, and you still don’t understand the logic as well or intuitively as you would if you write it.
Code reviews should be done by someone other than the author though, so the only thing that changes with ai generated code in that respect is the amount of it
Before: One person writes the code (and likely understands it thoroughly), another person reviews the code to spot obvious mistakes or shortcomings. Now: AI writes the code, a person reviews it to spot obvious mistakes or shortcomings.
In the before case, you have a person who has a deeper understanding of the code and in the AI case, you don’t, instead you have even more code to review.
When a competent programmer is writing the code, the human written code tends to be higher quality too. So it’s not just about review quantity but the quality of code being reviewed. Some people claim the AI writes great code, but that just hasn’t been my experience yet (at least with the models I’ve tried, including Opus). They still make ridiculously bad decisions regularly.
>When a competent programmer is writing the code, the human written code tends to be higher quality too
This is a great idea, but on average is deeply untrue. Far and away most programmers today write significantly worse code than LLMs. Also LLMs are fantastic at generating high level summaries and comments in code
> Far and away most programmers today write significantly worse code than LLMs
Your experience with LLMs do not match my own. Not to say that I haven’t experienced terrible human written code where I’ve wondered what the author could possibly have been thinking, but overall, I still find LLM written code to be on the poor side.
Like, the code itself is ok, but the wider picture reasoning and abstractions are bad. It also makes really dumb decisions far too often. Or doggedly shoehorns its first idea in no matter how badly it fits.
This is what I'm seeing - for people who were slow and didn't posses a lot of depth or breadth, their blast radius and impact has skyrocketed. They can now work in unfamiliar domains quickly, without any knowledge of the nitty gritty details of those domains!
For me personally, it's a tradeoff of generating the first pass code 10x more quickly, but then deeply knowing and validating the code is then 10-20x more work than it would have been if I'd written it myself (and if time is of the essence, then there's the option of shallow validation/understanding in exchange for speed - which is a compromise in rigor and path towards tech debt). In the end, none of this seems like a net win (unless you don't care about quality), and it is much less enjoyable.
TL;DR; While LLMs are faster to spit out first pass code, by the time I've validated and fixed the LLM's first-pass work, I could've had my "by-hand" implementation done correctly, and had much deeper understanding out of the box. Net loss.
I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)
reply