It's strange to me that this blog post was written in English. If AI is available, why aren't we all communicating in Lojban? [0] It's an obviously superior language. What does it matter that many people already communicate in English and much of computing depends on that language? AI doesn't care about that. Plus, if you ever need to edit Lojban without AI, you should be able to pick it up in a few weeks, right? [0]…
what made you draw parallel between message that's being delivered by the blog, and how the blod should be delivered?
Using Clojure and Elixir and LLMs are fantastic with both. Sure, if I get to a super-stable situation then maybe I'd consider moving to Rust (or Jank?), but for now I'm just so happy with Clojure and Elixir in this new world. I'm solving new problems with fully bespoke architecture so the flexibility is key. Clojure for business logic and most DB. With Elixir, it's the actor model and hand-holding as I'm using it for…
> fantastic with both Most developers evaluate programming languages by comparing features in isolation, never stepping back to consider the overall experience of using one. Features are easy to talk about. They're discrete, nameable, and comparable. "Does it have Foo?" is a question you can actually answer. "What's it like to build and maintain a real system in language X for two or three years?" isn't. So people de…
Well in a recent project I tried TypeScript thinking, OK, LLMs, huge training corpus! massive adoption! api for everything already set up! swim with the current! and I tried various frameworks and so on, but for me reasoning about things and being able to make systems that I could adapt and pivot it was honestly inferior compared to niche Elixir and Clojure. But it's not like I hate JS; I use it in LiveView all the time. And don't mean to imply there are no problems in niche-land though; you've got to be willing to do more yourself and live in a tiny world. Really, LLMs kind of tamed Clojure for me because it seems so far at least that they can handle the glue code and stitching libraries together pretty decently as long as you don't get lazy with architectural choices and stay vigilant. And if I ever hire it pretty much has to be remote or learn on the job, though again LLMs reduce this pain greatly.
Python has a much more mature ecosystem than Rust, especially for AI/ML stuff. I ran into a rust crate that purported to do a certain ML algorithm but did not do it correctly. I managed to write a replacement with Claude though. I do think enforcing correctness at the type system level is a good idea for AI, which is why I often choose languages like C# and Rust over Python. However, for some things Python is definit…
I almost always pick Rust. Recently I wrote a plugin for something that was written in Go. I could have used Rust, but Go for one felt right because if the thing turned out well, others would surely find more value in having one toolchain. The main reason is that you’re capable of reading it if you need to. And the recipient ecosystem expects a language. That’s why some data science communities pick R, MatLab, Julia,…
C# feels kinda nice because it's a good balance.
Very good static typing, Roslyn analyzers, good tooling and decent hot reload (for a compiled language), really good ORM (EF Core) that implements UoW and reduces a lot of the need for transaction management (simplifying the code), flexible enough and fast enough for various kinds of use cases.
Source generators are underrated as well since they can make the code very terse and legible by generating a lot of standard boilerplate.
Claude writes java pretty well, and faster than Rust. It's a great middle ground for some projects. I've switched back from Rust to Java for some things. I don't know why you would use Python at all except for small iterative projects. If you hate java for some reason, there's Go...
It certainly makes sense to use python for ML or data science.
Right sorry, that's not in my wheelhouse so I didn't think of that. I should be more specific. For general backend / data processing/pipeline stuff, API servers ...
AI has not been trained on Lojban. And furthermore, this article is almost certainly primarily intended to be read by humans directly. I understand you're being facetious, but I'm not sure what point you're trying to make about programming languages in comparison.
It’s funny that in your reply “this article is almost certainly intended to be read by humans” you made what is the best case to keep writing code in Python even with AI. Sure, if you are going to have an AI do all your coding and maintenance you can use whatever language it’s best at. But if you want to participate in the writing, debugging, and maintenance, it has to be in a language that a human can read. I’m not…
I'd argue that while Rust has a high barrier to writing code due to lifetimes and other type constraints, its still quite easy to read.
Why Python? Because I have written it for 10+ years, know how to debug it and I can smell it within 10 seconds of the agent writing code if it does something that is going to end in a huge foot gun. With any other language, not so much; I would need to relearn a lot. So I am going to be preferring python; where even with the speed that AI crams out code, I still feel somewhat in control. If I did this with Go or Rust…
This is what I experienced as well, I can smell BS from AI generated code right from few lines it wrote in Python, so that why I keep using Python for most of my projects.
Read the first few comments and surprised I didn’t see it, but training data. The voluminous amount of Python in the training data. I could write in brainfuck with ai, but I presume, wouldn’t get the same results than if going with python. My follow up question: with AI now, why care about a lang until you need to?
Surprisingly, LLMs are actually much worse at reasoning in Python than other common programming languages for agentic coding tasks. Data here: https://gertlabs.com/rankings?mode=agentic_coding
Huh. This surprises me. Digging, it seems it looks like it comes down to interpreted + dynamically typed vs compiled and statically typed.
TIL. If i were to start a truly vibe project; Go would have a significant leg up.
Read the first few comments and surprised I didn’t see it, but training data. The voluminous amount of Python in the training data. I could write in brainfuck with ai, but I presume, wouldn’t get the same results than if going with python. My follow up question: with AI now, why care about a lang until you need to?
Admittedly, I have very little experience with LLM-assisted Python. However, based on the severe degradation in output quality I have seen from an LLM working with plain JavaScript as opposed to TypeScript, I can't imagine choosing to start a project in Python at the moment.
It does seem like LLMs write better Python when told to use type annotations, especially when coupled with a linter.
This seems to assume that all there is, is systems software, tools and frameworks. Why ignore the elephant in the room - business / enterprise / line-of-business software? The case for Rust, Go, Gleam and Zig vastly changes for these versus Java or C#.
Many here propose replacing Python with more performant, but less familiar languages - mostly Rust, Go. But I find the argument that the AI - HUMAN interface is the most important. A simple version of this is “no, stick with Python if that’s what you know”. A more interesting version is “use this new found AI leeway to move up the abstraction level”, “try something more expressive and human oriented”, “make a DSL and…
I honestly think Mojo is the dark horse in this race. That is assuming all the roadmap goals are fulfilled. We're talking about C++-like performance, Python syntax, complete compatibility with Python, designed from the start to interface with AI, compile-time metaprogramming like Zig, and all kinds of other goodies. So yes, people can bless Go and Rust all they want. Nothing is wrong with the languages, but I agree t…
I really wanted to like Mojo, but the more I read about it, the more it really wasn't Python even though, starting out, that was a major claim to fame.
There is an excellent chance it will be awesome stuff. But they did themselves a huge disservice with the initial claim about trying to be Python compatible.