I was so into Python for 10 years, was enjoyable to work in. But have deleted 100k+ lines this year already moving them to faster languages in a post AI codebot world. Mostly moving to go these days.
I was so into Python for 10 years, was enjoyable to work in. But have deleted 100k+ lines this year already moving them to faster languages in a post AI codebot world. Mostly moving to go these days.
This is straightforward in the first instance, but how do you see maintenance of those projects going forward - especially adding more complex features ?
I can see one way forward being to prototype them in python and convert.
I'm still on the lookout for a comprehensive Django-like web framework for go. That would be an instant hit for me.
Same here. Django is my last holdout for Python. Everything new is go.
Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?
Programs have to run in a lot of different contexts, not just as servers, and for some of those contexts (especially say glueing together other programs), an interpreted language is more convenient and easier to work with. In fact, unless I care about performance, I'm going to use an interpreted language because having the source close at hand when something breaks just turns out to be super useful.
Because it's quick and easy to radically alter and refactor your prototype as you learn the problem space. By the time it works you often find out that you don't need anything more. This is something that Perl had.
Once your program starts to get bigger you have abstractions that can cope fairly well and keep your code simple to use - this is what Perl didn't have.
If you need more speed then you can write extensions in some compiled language.I think TCL was better at this hybrid approach but Python is a nicer language in itself.
You can also just dump python and write everything in that other language but now you understand the problem space quite well and you won't be trying to learn about it using a language where change is "difficult."
IMO the main reasons people use Python are:
1. The very first steps are quite simple. Hello world is literally just `print("hello world")`. In other languages it can be a lot more complex.
2. It got a reputation as a beginner-friendly language as a result.
3. It has a "REPL" which means you can type code into a prompt and it will execute it interactively. This is very helpful for research (think AI) where you're trying stuff out and want to plot graphs and so on.
IMO it is undeservedly popular, or at least was. Wind back 10 years to when it was rapidly gaining mindshare:
1. While "hello world" is simple, if you went further to more complex programs you would hit two roadblocks: a) the lack of static type checking means large programs are difficult to maintain, and b) it's really really slow.
2. While the language is reasonable, the tooling (how you install packages, manage the code and so on) was eye-bleedingly abysmal.
3. While the REPL did technically exist, it was really bare bones. It couldn't even handle things like pasting code into it if the code contained blank lines (which it usually does).
However since it has become arguably the most popular language in the world, a lot of people have been forced to use it and so it is actually getting quite decent now. It has decent static types (even if lots of people still don't use them), the REPL is actually decent now (this changed very recently), and there's a new third party tool called `uv` to manage your code that is actually good.
The biggest issue with it now is that it's still horrifically slow (around 50-200x slower than "fast" languages like C++, Rust etc). It is pretty unlikely that that will ever change. People always try to excuse this by saying Python is a "glue" language and you just use it to connect components written in faster languages, but a) that's pure "you're holding it wrong", and b) that only works in some cases where there are nicely separated "slow bits" that can be moved to another language. That's the case for AI for example, where it's all numerical, but for lots of things it isn't. Mercurial was a competitor to Git that was written in Python and lost partly because it was way too slow. They've started writing parts in Rust but it took them 10 years to even start doing that and by then it was far too late.
> what would you suggest?
It really depends on what you want to make. I would pick something to make first and then pick the language based on that. Something like:
* AI: Python for sure. Make sure you use uv and Pyright.
* Web-based games: Typescript
* Web sites: Typescript, or maybe Go.
* Desktop GUI: Tbh I'd still use C++ with QtWidgets. Getting a bit old-school now tbf.
Also Rust is the best language of them all, but I dunno if I'd pick it as a beginner unless you really know you want to get into programming.
I think "Python is slow" is reductive and frankly just as useful as saying "Python begins with a 'P'". The story is more complicated than simply speed of execution.
Choosing a language is a game of trade-offs: potentially slower execution in return for faster development time, for example. If your team is already familiar with Ruby, will asking them to write a project in Rust necessarily result in a better product? Maybe, but it will almost certainly take much longer.
Anyway, how many Python programs are actually "too slow"? Most of the time, Python is fast enough, even if heavy computation is offloaded to other languages.
As for Rust being the best language of them all, that's, like, your opinion, man.
I agree with you; I've developed in Python for most of my career and a lot of Python criticism is malformed.
That being said, I'm starting all new large development work in Rust. Python is hard to reason about due to its dynamic nature in large codebases. And if I'm enabling strict typing everywhere, I might as well use a typed language and get a performance boost. Obviously, this is only because I'm the sole developer and using AI to improve productivity.
Work settings are completely different and one has to be a team player to find the language that works for everyone.
[dead]
ptpython has existed for a decade, maybe two, and python is high level, more readable than most languages. Exec speed hasn’t mattered in my near thirty years of using it for business and prototyping tasks which it promoted early.
Yes it strains at the big to huge project end, not recommended to take it there. Still there are better tools to help now.
Go is terrible for scientific/ML work though, the libraries just aren't there. The wrapping C API story is weak too even with LLMs to assist.
Try and write a signal processing thing with filters, windowing, overlap, etc. - there's no easy way to do it at all with the libraries that exist.
I think the purpose of go is to write CRUD. Stray from that and you're on your own.
crud is a pretty poor fit for go, you're better served by languages like python that can autogenerate classes that reflect the db schema. go's sweet spot is things like network servers.
you just need the right tools https://github.com/CaliLuke/loom
i don’t really see it this way. the value of a token in Python is much higher than it is in lower-level language
Thats very intersting, If I may ask was it from professional projects or personal projects?
Same, I’m not sure how Python survives this outside of machine learning.
All of our services we were our are significantly faster and more reliable. We used Rust, it wasn’t hard to do
the funny thing is that everyone, including myself, posited that python would be the winner of the ai coding wars, because of how much training data there is for it. My experience has been the opposite.
I felt the opposite, because Python isn’t a great language. It won because of Google, fast prototyping, and its ML interop (e.g. pandas, numpy), but as a language it’s always been subpar.
Indentation is a horrible decision (there’s a reason no other language went this way), which led to simple concepts like blocks/lambdas having pretty wild constraints (only one line??)
Type decoration has been a welcome addition, but too slowly iterated on and the native implementations (mypy) are horribly slow at any meaningful size.
Concurrency was never good and its GIL+FFI story has boxed it into a long-term pit of sadness.
I’ve used it for years, but I’m happy to see it go. It didn’t win because it was the best language.
> there’s a reason no other language went this way)
Except of course for those that did, Haskell, Fortran for example.
F# as well, and that tends to exist in parallel with some degree of C# written by the same devs… the indentation enables cleaner, smaller, simpler code function by function.
It’s pretty ok in Python, but meaningful indentation is amazing with a proper type system and compiler. Clean, consistent, efficient, and ensures working code is easily read and standardized.
I’m unaware of anyone accepting improperly formatted C# as ‘done’, and would reject any such PR out of hand because of the potential for legibility issues to hide bugs. So: if it were done when 'tis done, then 'twere well it were done by the compiler to save line noise.
> lambdas having pretty wild constraints (only one line??)
I will never understand why people are upset about this.
You HAVE multi-line lambdas. They're called functions.
Yeah, I know you want a function that's only used once to be able to be defined in-line, but tbh I've always found that syntax to be pretty ugly, especially once you're passing two functions to a single call, or have additional parameters AFTER the function (I'm looking at you, setTimeout/setInterval).
I’m always baffled when language complaints come down to syntax
That’s exactly how I think, too. But at the same time, I like indentation in Python, because I would logically indent in every other language as well. In fact, I find all those semicolons and similar things at the end of each line completely redundant (why should I repeat myself for something the compiler should do) and I hate them. And that’s despite having experience with Modula and 10 years of C++. But when I look at Rust, I find the syntax simply awful. From an ADHD perspective…
Lambdas are intentionally kneecapped in python because Guido van Robson doesn't want to make a functional language. (As in "functional programming", not that it doesn't work.)
Guido van Rossum didn't oppose functional programming, but he wanted to keep the language (and the interpreter) simple.
"I didn't envision Python as a functional language" https://python-history.blogspot.com/2009/04/origins-of-pytho...
"I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers). I also don't think that the current crop of functional languages is ready for mainstream." https://developers.slashdot.org/story/13/08/25/2115204/inter...
AI benefits from tools to verify its halucinations. That's much easier in a typed and compiled language. Then have a language that can't be monkey patched at runtime and the confidence increases even more.
If you mean "easy to get something out of it" then yeah, it's great.
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.
Not the most important thing, but it certainly helps.
a lot of the training data is either for python 2 or just generally very low quality
The quality issue doesn't seem unique to Python.
The versioning issue I've seen across libraries that version change in many languages.
I don't tend to hit Python 2 issues using LLMs with it, but I do hit library things (e.g. Pydantic likes to make changes between libraries - or loads of the libraries used a lot by AI companies).
I’ve found recent Claude to be much better in this regard. I think a lot rests on the quality of the harness and the work behind the scenes done to RAG up to date docs or search for docs proactively rather than guessing.
I also don’t have issues with quality of Python generated. It takes a bit of nudging to use list comps and generators rather than imperative forms but it tends to mimic code already in context. So if the codebase is ok, it does do better.
That could be it. I still see LLMs fail a set of static typing challenges that I created a couple years ago as a benchmark. Google models still fail it. I wonder if the lack of typing in a lot of the training data makes python harder to reason about?
The tons of python code would be great training data if there was any consistency across the ecosystem. Yet every project I've touched required me to learn it's unique style. Then I'd imagine they practically poisoned half the training set because python2 is subtly different.
You can test on the device directly, without needing to recompile to try something.
Three things I find unlikely about this:
- You wrote 100K lines of code (I've worked on several large C++ projects that were far smaller)
- You wrote those lines in Python (surely the whole point of Python is to write less code)
- You deleted them (never delete anything, isn't this what modern VCS is all about?)
But whatever floats your boat.
> You deleted them (never delete anything, isn't this what modern VCS is all about?)
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).
Well, they deleted it from somewhere. As I assumed they were using a VCS I assumed they deleted it from that. Or are they really short of disk space?
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?
In this context I would assume deleting code to mean deleting it from the current version of the software, not removing from the VCS history entirely.
100k lines is tiny what are you on about, especially in the monolithic app sass world where many Fyll stack apps that handle all business ops are probably written with Django.
Our entire business runs on 300k lines of Ruby (on Rails) and I can keep most of the business logic in my head. I would say our codebase is not exactly “tiny” and just cracking the ceiling into “smal” territory. And comparatively, people probably write even less code in equivalent rails apps to django ones. 100k lines of C++ is miniscule.
Obviously “deleting code” in this context doesn’t mean purging version control history but the current state of the codebase.
> 100k lines is tiny
No, no, it is not, or at least not in my experience (I do not and never have done web development - medium performance C++ code - I don't see how I could write, understand and support 100K lines of code in this area).
And so, what does your Ruby code actually do?
Your experience doesn't match mine. I have, mostly solo, and part time, written multiple codebases that on that kind of magnitude (it is about the level where it still will fit in one person's head pretty easily IMO). It doesn't take much to reach that kind of size. Now, if all of it was super dense and subtle code, then yeah, that would be a lot, but in my experience that's usually a pretty small part of any given codebase.
> in my experience that's usually a pretty small part of any given codebase
Our experiences differ then. Mine is that almost all of the code I write is directly targeted on the usually quite complex problem I am trying to solve. I don't do boilerplate, for example.
I tend not to have much boilerplate (and write abstractions to avoid it), but I do still find there tends to be a lot of supporting code around the 'difficult bits' (TBH, most of the code I write is supporting a small amount of relatively simple but subtle operations, but such is the nature of embedded software). But different codebases are quite different in this regard: this is why such different scales shouldn't be too surprising in different domains.
Uhm what? All of those things are totally ordinary.
> All of those things are totally ordinary. reply
I would need some evidence of that.