[_8j50]

C is enjoyable to write with although if others rely on your code, safety should have a higher priority.

The one thing I could never enjoy in C after getting used to languages like php and python is string handling. It isn't just dangerous but very tedious, complex and lacking elegance. Lack of a native string type and string operators really sucks.

I like being able to do "hello "+"world".

Another pro the author didn't mention is how my crapy code from 10yrs ago still works today. Can't say that about rust, go, python or most modern languages. It really sucks how "planned obsolecence" has crept it's way into programming languages.

[TwentyPosts]

> "planned obsolescence"

Cut me a break. In Go and Rust it's still easy to compile old code, and these languages have very strong backwards compatibility guarantees. You might need to compile it with a flag enabled, but it is going to compile and work.

Having the ability to improve on past language design mistakes over the years by deprecating old ways in favor of new ones is nice, and the burden of migration is generally minimal (or can be done automatically).

[conradolandia]

Go and Rust don't have old code. Talk in 30 years.

[TwentyPosts]

Sure, I agree that these guarantees still have to stand the test of time. So far they're holding up quite well.

[_8j50]

If they stuck to binary libraries that would have been nice but since you have to build deps locally and match up the right versions, go and rust programs have been a constant headache for me similar to python. The version from debian repos never seems to be good enough, I have to install it from upstream and maintain it.

[_8j50]

Not if you use any libraries. The whole venv/pyenv/pipx stuff of python needs to implemented for other languages too. Every program needing it's own virtual environment and tooling for every build.

[turndown]

10 years ago was 2014. What python code are you talking about? Deprecated, sure, and some things have been taken out of the standard distribution because nobody would maintain it(or there were reasons to not maintain it.) 2->3 conversion was 16 years ago.

[_8j50]

While I still do run into 2.7 code, even for 3 dependencies are the problem. You always use a library of some kind and that library could use a new python feature. You could pin it but then other scripts that need the new version break. And that is if you could even easily find the module and version. Just this week I helped someone troubleshoot a bug they've been trying to fix for weeks/months and it was just a matter of the library code being too new for 3.6. It's an ever growing planned mess.