On 4/21/20 6:50 AM, Michał Górny wrote: > I realize Go is not isolated here. It's just brought as one major > example. Rust is no better. All these shiny 'write and forget' > languages share the same problem. Pay for some work hours, get > a working product, deploy it and forget unless customers want more > features. > > Today these languages are still young and the problems can be considered > largely theoretical. But some day -- well, unless all the cool kids > manage to move on to next shiny new language before then -- this will be > a major catastrophe.
Looking into an old language (25 years old): php So many security problems... Just a few essential ebuilds exists in ::gentoo and being very well maintained by Gentoo. I think the approach to the new languages have the same requirement. Minimizing the ebuilds to the required ones would allow to minimize the effort. Then we can use an overlay to deliver all other software that would be useful. So the goal in this cases would be to define the right sieve about those libraries and tools that are required to all and that fits in package maintenance procedures, so it could be merged into ::gentoo. But don't forget the tooling available to the overlays development, where another abstraction layer takes place, since it's focused on a specific target and not all community in main ::gentoo. That's why I consider go-module as a very cleaver solution since it gives a hybrid solution connecting immutable delivery model into the mutable reality. The PR present in this subject is related to missing eclass for JVM languages, to define the common procedures to use those languages and available builders.
signature.asc
Description: OpenPGP digital signature