> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent

Oh, that is such a nice thing.

Type annotations are lazily evaluated by moving them behind a special annotations scope as of 3.14:

https://peps.python.org/pep-0649/

https://docs.python.org/3/reference/compound_stmts.html#anno...

With 3.15, using lazy typing imports is more or less an alternative to putting such imports behind an "if TYPE_CHECKING" guard.

Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for years

Opus 4.7 did this in my code and I had never seen it before

You can get the L_k distances between the two counters. E.g. if you sum the absolute value of the difference of the counts, you get the L_1 distance between the counters. If you raise them to the n^th power and then sum them, you get the L_n distance. For n=2, that's the Euclidean distance (squared).

It’s completely the opposite. LLMs write awful python. Horrendous. They write pretty reasonable go and do it quite quickly.

We started in Python because of “the ecosystem”. It was a mistake. The amount of time we spend ripping out each dependency and pruning it to what we need is way higher than if we’d spent the month building out what we need. I miss compilers and LLMs will NOT generate config driven code or things that serde well. Everything has layers and layers of adapters by default and the domain model slowly erodes over time.

I think the purpose of go is to write CRUD. Stray from that and you're on your own.

Or just use Django. You can later identify hot spots and bottlenecks and spin out Go services where applicable.

Try another language? The Go ecosystem tends towards libraries as opposed to "frameworks."

I personally chose C# for this reason, because ASP.NET is mature and (IMO) well designed. But there's also Java/Spring and and lots of other options in different languages depending on your preferences.

Same here. Django is my last holdout for Python. Everything new is go.

Try gofiber, i love python, i eat thanks to python but Django...... Gofiber isnt perfect, but it's really great

why not Rails?

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

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.

Try a few, pick what you like

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.

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.

You can test on the device directly, without needing to recompile to try something.

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

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.

Uhm what? All of those things are totally ordinary.

Ok, good to see that they checked that possibility. Looks like there was no situation in which the previous behavior could have been usable, so yeah, agreeing with the change then.

> If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code

I think about this on the regular -- I know the answer is currently "you own the code, so you have to understand it", but to unlock the true productivity multiplier, in the future, the answer has to be "no one really".

I think about it using the concepts from my job (academia) -- to actually have PhD student-level intelligence means that you have to trust that it does a good enough job that you can focus on other stuff. Professors often bring the correct ideas or intuitions, but they have to trust the PhD student to write the code and/or fill in the gaps in the proofs -- they can advise them on the high-level issues during a consultation, but that's about it.

I am pretty bad at working in the current LLM workflow -- it is tough for me to focus on reading a TCS paper for review, keeping all the details and invariants in my head, but every 5-10 minutes go to my PC, completely switch contexts/projects, read the code and think about the LLM's comments, suggest the next step, and then go back to reading.

I do, with different tools and most of the time at a higher level of abstraction. The same way we understood the machine code 2 years ago, even though we didn't write it directly. Just another layer, nothing more.

My working methodology has been , LLM output is a jumping point and to use my experience, knowledge and basic understanding to N+1 it.

So for bleeding edge stuff it works out well or in places where documentation is not great like Apache Flink.

In its inception 35 years ago the creator of python could not foresee how far python would go and how the environment would look like today. But nowadays there are a lot of security mechanisms they could leverage to adapt (from chroot by default to namespaces, cgroup, etc. on Linux, pledge, unveil on OpenBSD).

The very idea that you offer a (python) package installer that is gonna pull a tree of code published and updated by random people in an unvetted manner open the door to all the supply chain attacks we are seeing.

Around the same time (early 90s) Java was designed with high isolation in mind but the goal and vision was very different. And Java had its own problems.

I'm saying that because at some point the security problem is gonna really hurt the python ecosystem.