Hacker News Reader

Comment by t8sr | Hacker News Reader

Very much so, insofar as code written a few years ago probably doesn’t work anymore. Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years.

10 years ago: range 5 years ago: xrange Today: range again, LOL!

I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again.

View on HN

> I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again.

It is weirdly comforting to observe how certain things never change over the years, even in tech. One of them is the hyperboles people deploy when attacking programming languages that they do not like: "I don’t know of any tech companies using Python for anything serious anymore". I mean, except for being the 4th most popular language amongst professional according to last year's Stack Overflow survey. Only JavaScript, SQL and HTML/CSS are more popular. Yes, yes, I am sure it is dying... any moment now.

You just read what you want to read, friend. I don’t particularly dislike Python, in fact I wrote about 50k lines of it a few years ago.

My claim is that the big names don’t really use Python outside of data pipelines. Where I’ve worked (including an org that had had Guido on it for a while) usually had guidance saying “no new Python projects”. You can ask people at Google, Meta, etc when was the last time they wrote production Python code if you don’t believe me.

That’s not mutually exclusive with web devs on Stack Overflow using the language, nor does it take away from its success in academia.

The criticism is that the Python team will deprecate and remove functionality as it's not needed? Boy, you're gonna hate PEP-594.

Also Python 2->3 transition was a one-time thing that developers had over a decade to perform, it may have been painful for some but saying it's a random thing that happens "every few years" is a bit dishonest.

PEP-594 is actually causing me some anxiety - I deal with a good amount of code that uses some of those “batteries to be removed”.

Some of them (telnetlib) I can vendor in, but I wonder how many people who use them will be caught pantsless?

My feeling is that if you're the sort of org who will update the Python version you use, you're going to be switched-on enough to handle this somehow. From the sounds of things it it's a bit of an inconvenience for you that you'd understandably rather not have, but you have it under control. I don't personally use any of these "dead" batteries though, so I can't speak with any authority on the matter

Are you saying there will never be a Python 4, or are you saying that the 2->3 transition was so badly flubbed nobody will make that mistake again?

Well yeah given that some people are still talking about issues from a software release that happened 15 years ago, it would be incredibly unlikely that they'd want to repeat that.

What has me a little bit confused is that we're in a thread talking about how Python somehow "flubbed" after 2->3, despite an explosion in popularity during that period culminating in it being arguably the most popular programming language around. And the counterexample is supposed to be Perl, a language which I have enjoyed using but which has fallen off a cliff during the same period, and which has had an even more enormous and self-defeating flub (Perl 6 aka "Raku").

As I said, I understand if Python 3.x was painful for some organizations. I think the suggestion that it was a failure and that Perl showed us the right way to go is a pretty silly one though.

Saying that the Raku Programming Language is a flub, indicates to me that you do not know it at all. Getting Unicode support right by itself should be an indication that it is better than Python 3 in that respect. And let's not start about the fact that the Raku Programming Language does not have a GIL, allowing true multi-processing features and event handling.

https://raku.org

In terms of execution the development and release of Perl 6 was undeniably a flub. What eventually got released was ultimately a fine language, but it was years late, largely incompatible with existing Perl code (hence the rename) and a sizeable portion of what was left of the Perl community didn't adopt it and stayed on Perl 5.x. Sizeable enough that there are now some rumblings around tidying 5.x up a bit and releasing it as Perl 7.

> Very much so, insofar as code written a few years ago probably doesn’t work anymore.

Citation needed? Just a week ago I used a Python library completely unchanged from 2013.

> Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years.

"Seemingly random" is both wrong and insulting. The BDFL did step down and was replaced with a steering council, so maybe that's what you're seeing. I do agree that `match` was a bad addition to the language, but that's one small example among many supporting the opposite opinion.

> 10 years ago: range 5 years ago: xrange Today: range again, LOL!

Huh? Python 3.x has only ever had range(), so it's been range() for at least 10 years.

How about a fortune 300 company I consulted for that uses python pretty much exclusively for the deployment processes of their 200+ web/cloud apps? Some of those apps have 1 VM plus a DB and a dozen users. Some have environments that cost £30k a month and 5k users. Python is the only language used for CI/CD. Plus power shell for stuff that needs windows server.

70% is python 2, 30% written/rewritten recently is python 3.

> 70% is python 2

I hope they are paying for security updates since python 2 has hit EOL 3 years ago and libraries had been actively shamed if they didn't drop support for it long before that.

Nope, not for python 2, but there was tracking of published vulnerabilities. None that were discovered during my time there affected existing python 2 code.

Python 2 code is being transitioned to 3 and there is a plan to do so for all of it, but it's definitely not a highest priority task. Usually done when new features are requested.

This isn't ideal, but it's not a reason to panic. None of the code is externally facing, none of it accepts user input directly beyond a press of a button in third party software that triggers it. All it does is pretty simple stuff. Infrastructure provisioning etc.

> but a lot of it is the language itself making seemingly random changes in direction every few years.

Outside of 2 -> 3, I can recall only one or two instances of dealing with this in the last 15 years. One was the introduction of "with" and "as" as a keyword. The other one I can't even remember.

None of the code I have written on my personal PC in all these years needed modification due to these changes (all of them were in 3rd party code I needed to patch). I still have Python 2 scripts continually running! I have Python 3.10 installed, and never had to fix a broken script of mine since I switched to Python 3 several years ago.

> 10 years ago: range 5 years ago: xrange Today: range again, LOL!

Eh? When I began using it heavily (before Python 3 existed), both range and xrange were heavily in use - one was a list the other was a generator. Since Python 3 has been stable and fast (circa 2013 or 2014), it's been only range.

> it’s getting rewrote in Go or Rust, not Python again.

Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?

Why wouldn't you tag your 1 year old code with the compiler it was written for?

And same question for grandparents. I'm not a great dev, average at best, but at least I control my systems.

If that's what best practices are for these languages, I now better understand my collegues who will not move away from C/C++. Having to identify a specific compiler version for each bit of code sounds like a nightmare.

it's very easy. you make a file called `rust-toolchain` next to your `Cargo.toml` that contains the version of rust you intend this to compile for.

It will then compile for that version.

C and C++ projects of any notably complexity & size often suffer from those exact same kind of "library or build tool or compiler updated—now the project won't build" problems. Absent some pretty heroic & unusual levels of discipline from all involved, anyway (which is also a way to avoid those issues in most other languages that have them).

[EDIT] Check out issue trackers for such projects, some time. "Build broke due to [thing] being too new" is a routine issue to encounter.

Why should you need to? Just use a stable language, or a language that has a standard or a specification.

Rust is a stable language.

Stable features will never be removed or broken. If you don't use unstable features, and aren't relying on something that is unsound, your code will continue to compile. If it doesn't, this is considered a bug and should be reported.

This isn't just a hollow promise either, they run tests against most of the crates on crates.io when making changes to the language to ensure that old code is not accidentally broken.

Claiming that rust isn't a stable language is pure misinformation, but sadly not uncommon.

It's also worth noting that some of the language is specified informally, this is the "reference", there are also RFCs for new features that describe exactly how the feature is intended to work. This isn't a complete formal specification, and could use a lot of work, but I don't think a formal specification with a committee is any better than an informal reference, assuming the reference is exhaustive!

> Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?

I have, more than once; it worked perfectly fine.

The only time it's broken for me is when the code had unstable nightly-only features, hidden behind a "nightly-only" feature flag, which was rejected by the parser on a newer Rust compiler, even though it would not be compiled due to the feature flag being disabled (even though it wouldn't be compiled, it still had to be parsed; IIRC, it was the change to the inline assembly syntax, and the fix was just to change from "asm" to "llvm_asm").

Not my experience, though I think it was more due to libraries (but need to update a library -> needs newer compiler version -> needs to update another library, etc)

This goes against my own experience. I moved from Perl 4 to 5 and from Python 2.x to 3.x and have dozens of projects written in Python that have been constantly updated over the past 10 years, none of which broke due to those things - and they are not all in the ML space.

Your sample size of one needs expanding.

Maybe Perl is stable cause its dead.

Latin and Sanskrit are stable af.

Latin is pretty stable, but not entirely fixed: https://www.nytimes.com/2003/05/14/world/vatican-introduces-...

I took a medieval Latin course in college that was especially challenging because after the empire fell, Latin was absolutely not stable.

Reply on news.ycombinator.com