[brianwawok]

In the world of AI written code, Python just doesn’t make sense. Converted about 100k lines in the last few months to golang and the performance is life changing. Curious if we will see global Python adoption fall by 75% or more in the next few years.

[mau]

I think humans are still accountable for the code generated by agents.

You are free to switch language but you still need to understand it.

[tdb7893]

With a similar amount of experience with both languages I found Go much easier to read. I've always been a bit miffed why Python is seen as easy to read for experienced developers. I get the syntax is good for short code or people with little experience but my experience is those readability benefits went away quickly with time or complexity.

[mywittyname]

Why are you miffed about it? I legitimately hate reading golang with passion and find python to be pretty intuitive, outside of the odd ambitious list comprehensions. I worked in a golang shop for several years, so it's not just an familiarity situation either.

We are just different. That's not something to be mad about.

[Yokohiii]

In my opinion most interpreted languages today tend to produce very dense code. Fancy call chains and closures interleaving. If you look for a subtle bug those are hard to reason about, you have to know the details of a lot of different APIs.

Go is verbose partly for that reason, but a silly loop is a silly loop. The constraints are clear, you only have to do the logic.

[__loam]

[flagged]

[wiseowise]

> Python is a garbage language. Dynamic types are a disaster

Python has gradual type system.

[lijok]

We should all go back to writing assembly

[__loam]

No we should write one of the many modern programming languages that handle certain projects way better, including kotlin, go, or Java. The only things python is best in class at are scripting and as a harness for high performance c++ or fortran.

[3836293648]

> X is a terrible language because of the lack of static analysis available.

> (Mocking) Yes, that's why we should go back to Y with even worse static analysis.

Sure

[sieve]

Any language that uses error codes instead of exceptions is a non-starter for me. Produces code that craps all over the happy path.

Python has a different problem: it is slow as f---. I did a micro benchmark comparison against 5 other languages in preparation for my python replacement language. Outside of dictionary lookups, it is 50-600 times slower than C depending on the workload.

Go, Rust etc are fine. They land at 1.25-3x slower than C. But I prefer the readability of python minus its dynamic nature.

[adrian_b]

Exceptions are not the only alternative to error codes.

Many early programming languages handled errors by providing multiple return addresses to functions.

Thus a function returned to the place of invocation in the normal case, otherwise it returned to one of the error handlers that were grouped at the end of the function that invoked it, away from the happy path.

This was more efficient than the modern way of returning an error code, as it eliminated the superfluous testing of the error code and the expensive conditional jump based on the result of the testing.

Moreover, in my opinion in the majority of the cases maximum information about an error is inside the function that has invoked the function where the error happened and neither in an exception handler several levels above it, nor inside the invoked function, so the place where the error handlers had to be put in this old method is actually optimal for meaningful error messages.

From the point of view of the source text, this old error handling method is equivalent with using exceptions with the constraint of placing the exception handlers in the function that has invoked the function that generates the exception. This limitation enabled a more efficient implementation than for exceptions where the handler can be placed anywhere above the invoked function and a complex stack unwinding may be necessary.

[lern_too_spel]

For personal projects, yes. For code going into production, you still need human code review, and that has to happen in a language that the humans you've hired are comfortable with. One day, we'll all be YOLOing vibe code straight into production, but that day is not today.

[JackSlateur]

But that day is not today .. unless you are working for microslop or clownflare ? Half-kidding, sorry :)

[backwardation_b]

nothing about the performance characteristics of python changed with AI so why would you use python over golang if performance is a requirement/bottleneck? Trying to understand the reasoning as to me golang and python are equally simple to write and understand.

[Yokohiii]

If language X is a persons comfort zone, that person will often default to it. Python is certainly more widespread then go.

Also, even if it looks like that to you, there are still people that write code with their own hands.

[phainopepla2]

Regardless of whether golang and python are actually equally simple, python certainly has the reputation of being easier to write and read than almost any other language. That is a big part of its popularity.

[zozbot234]

Python is not really simple though, the semantics are actually quite bonkers. It just has "simple"-looking syntax, but that only helps you for trivial programs where the bonkers semantics does not get in the way.

[LPisGood]

What about the semantics are bonkers in your opinion?

[dec0dedab0de]

I think we'll eventually be generating machine code directly. But until then we should be using code that our team can actually read and understand. If you know go, then that works you, Not everyone does.

[H8crilA]

Doubt it. LLMs will always be more expensive per-token than compilers, and high level languages need fewer tokens than machine code. Also, type systems, warnings, overlap with natural language in names - those are very useful.