Hacker News new | ask | show | jobs
by taesis 3445 days ago
It seems like the core thrust of this article is that someone isn't around to perpetually support the libraries the author would like to use; i.e., he/his company is unwilling to fork out the money for someone to keep the 'blessed' libraries fully up to date -- so now that's the implementer's problem! I can understand wanting stability and a promise of timely updates for all one's dependencies, but it doesn't seem like the core language team is the right group to foist that responsibility upon.
1 comments
rntz 3445 days ago
In the end, it doesn't matter who it's "fair" to assign responsibility to; a language you can't rely on is a language you can't rely on. All esr is pointing out is that there's a problem. Personally I think the Rust folks are pretty aware of this problem, and are managing just fine; Rust is definitely still in the early stages of language community growth, and locking things down too much would be a mistake.
link
taesis 3444 days ago
I suppose I'm not arguing from the perspective of fairness, but moreso about incentives + experience. If we applied the author's argument against other fields and languages, e.g. machine learning and python, then the cpython maintainers would be right in including TensorFlow in the python stdlib (or whichever competitor dethrones in and sticks around for long enough).

That doesn't sit well with me, at least. I'd want the top ML developers looking at TensorFlow, and the best language implementers doing the same for cpython, not the latter trying desperately to improve code they have no expertise in. From that perspective, what matters is community: is there a knowledgable community supporting codebase 'x', where x could be the stdlib or some third party library. Some other commenters in this thread proposed better library curation/discovery tools in place of a formal commitment of long term support by the core team, which seems ideal! Using such an approach, you rely on the language for the core-language bits, and on third parties for the third-party bits, which seems on the surface to be healthier than arbitrarily choosing the only constant group (core language devs) as your supporters of everything.

link