Hacker News new | ask | show | jobs
by foxrider 310 days ago
Python 2 situation opened my eyes to this. To this day I see a lot of py2 stuff floating around, especially around work environments. So much so, in fact, that I had to make scripts that automatically pull the sources of 2.7.18 and build them in the minimal configuration to run stuff.
1 comments

Python 2 is a warning about doing backwards compatibility changes too late. As soon as you have a few massive libraries, your backward compatibility risks grow exponentially.

C# did just as big of a change by going from type-erased to reified generics. It broke the ecosystem in two (pre- and post- reified generics). No one talks about it, because the ecosystem was so, so tiny, no one encountered it.

It certainly didn't help that they were annoying about it; like, they actively dropped some of the forward compatibility they had added (a key one being if you had already carefully used u and b prefixes on strings) in Python 3.0, and only added it back years later after they struggled to get adoption. If they had started their war with Python 3.5 instead of 3.0 it would be a lot less infuriating.
Not being a python dev, there must have been some huge superficial 'ick'. Back when, I was talking to a python guy and mentioned that Python 3 was coming out. He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did. (or they really sobered-up and rewrote in Go or something.)
> He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did.

"It" was fixed long before the 2.7 official sunset date. Even before the original planned date before it got extended, frankly.

When did c# have type erasure?
C# 1.0 did not have generics, period. So the standard dictionary (Hashtable†) type took keys and values typed as "System.Object". As seen in the linked documentation this class still exists in the latest .NET to this day.

Occasionally one would still encounter non-generic classes like this, when working with older frameworks/libraries, which cause a fair bit of impedence mismatch with modern styles of coding. (Also one of the causes of some people's complaints that C# has too many ways of doing things; old ways have to be retained for backwards compatibility, of course.)

https://learn.microsoft.com/en-us/dotnet/api/system.collecti...

The paper that the other commentator was referring to might be this: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Yeah, that does not mean type erasure. There were just no generics. That is just making use of polymorphism in the language. At no point is there a difference between what the language knows a container can contain, and what the runtime knows it can contain. There is nothing erased.
I do recall some paper mentioning it. But now I'm not sure if Google is gaslighting me or it never existed. But it seems you are right.