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.

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?

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)

The person said: "deleted 100k+ lines this year already moving them to faster languages"

Are you saying that when you move code to another language/rewrite in another language, you leave the original languages code in your repo?

They didn't say they deleted it from their git history. I delete code all the time (doesn't mean its "gone", just that its not in my git head).

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]

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.

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.

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).

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.

I’ve also written C++ and Java in Notepad long ago. Not ideal, but hardly a problem.

People have so many verbal tics and filler words too. Anthropic’s Dario says “you know” after every third word, for example.

Or they meander around unrelated/unimportant details.

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.

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.