Hacker News Reader

Comment by phkahler | Hacker News Reader

>> I fail to see how this is even being considered.

To me it stinks of an ego-centric person thinking they're a "language developer" and knowing better than the actual users of the language what's best for them. Just because something can be misused doesn't mean you have to take it away.

I haven't noticed, but since Rust came along is there a trend among languages to enforce "safer" programming at the language level? I could see that kind of thinking getting way out of hand. If that's the case, I would see this one as "I'm going to save the world with this dumb little change that breaks things for a bunch of people!"

I would hope a PEP like this came about from frequent user requests but that doesn't seem to be the case.

View on HN

It's interesting that you mention Rust, since Rust takes backward compatibility quite seriously; that's why it's still on version 1.x. Granted, sometimes there is a compiler bug that causes some old code not to compile with newer versions of Rust, but that is rare and never intentional like this PEP.

(Just to be sorta pedantic) I don't think it's the version 1.x that promotes backward compatibility, but editions.

In 2016, you could call your function `fn async(...) { ... }` without any issues, and you can still compile this code with the modern version of rustc. If you want to use the async features of Rust, you need to change your edition to at least 2018, which brings breaking changes in the language.

And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate.

(So, I guess the ideal world would to first look at the package management in Python, and *then* try to introduce breaking changes. And I'm withholding how much I'm angry at the PSF for postponing having a decent package manager for 20 years and investing in removing the GIL and adding JIT.)

Not meaning to apologize for Python here, but you have significantly more ability to segregate “editions” when you statically compile code.

All the more reason to take a breakage very seriously. This is even worse than the walrus operator. At least I can ignore that. This breaks working code for some notion of purity.

Code compilation doesn't really have much to do with it. Python already has a somewhat similar ability - opting into certain language features of python on a file-by-file basis - using __future__[0]. It'd be pretty easy to add something like Rust editions by looking for a special statement in the file. And to make it more convenient, put it in the __init__.py and have it be transitive to the module.

[0]: https://docs.python.org/3/library/__future__.html

> And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate.

I'm curious - if you had a `pub fn async(...){...}` in some 2016 crate, can you still call it from a 2024 codebase?

You can: https://doc.rust-lang.org/rust-by-example/compatibility/raw_...

Wow, this is nice and looks well thought out. Thank you!

>> It's interesting that you mention Rust, since Rust takes backward compatibility quite seriously;

I mentioned Rust because the memory safety guarantees are a significant new thing for a language like that. I forgot about "managed" languages like C# because that's quite far from my mind, but that's another significant attempt at safety. This kind of little detail in the PIP is really insignificant by comparison, so I was speculating that it might be driven by some kind of "save everyone" mentality. If so, wondering if that's a trend lately and I hadn't noticed.

They do take it seriously, I agree. However, the commonly repeated meme that Rust only makes backwards-incompatible changes by mistake or to fix soundness issues is wrong. They allow themselves to make changes if they're judged to have a low (but nonzero) risk of causing backwards incompatibility in the wild. For example, adding a new function to a standard trait can be backwards incompatible but they do it all the time.

Indeed. Although it's worth noting that the same is true of e.g. stable enterprise favorites like Java, which regularly makes minor breaking changes that are judged to have little impact (which is why every Java release is accompanied by a compatibility guide; see the "Important Changes", "Removed Features", and "Other Notes" sections of the most recent release notes: https://www.oracle.com/java/technologies/javase/23-relnote-i...).

No. A serious language designer will try to make things they like at the beginning, not trying to patch it later. Patching via breaking public API (language design) is never a good thing.

Let me just grab my time machine and go back 40 years

>> A serious language designer....

That's why I put "language developer" in quotes.

There have been people trying to enforce safer programming at the language level at least since Java positioned itself as the safer alternative to C++ way back in the 90s.

I'm pretty sure Bertrand Meyer's OOSC[0] from 1988 had something like "if a language has a feature which comes with warnings that you shouldn't use it, it shouldn't have that feature" (paraphrasing).

[0] https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...

can these language improvements be implemented at linter level?

so that people can opt-in or opt-out selectively, per their own discretion, for these kinds of rules

I dont see the point of this being part of the language since it break compat and brings zero benefits at runtime

In the PEP, some of the comments noted this was basically a linting issue. No reason to break the language over it.

Linters already flag this as error

Flake8 already provides this for anyone concerned about it.

https://www.flake8rules.com/rules/E722.html

So does pylint which has been there forever https://pylint.pycqa.org/en/latest/user_guide/messages/warni...

Rust had extremely successful marketing based on its security claims. It's no surprise that other languages jump on that bandwagon to not get left behind, is it?

Reply on news.ycombinator.com