@Zergling_man @Suiseiseki @lispi314 I generally agree with this, but take it a step further. The package manager for modules/libraries in your programming language should be the distro package manager. NPM, rubygems, cargo, and the rest shouldn't even exist. Not only that, any language with pretensions to being a serious language should use ELF/PE as the module format. You can have header files too of course, and should have at least C headers. But the actual module should be a .so or .dll that is completely usable from C.
Why C? Because it's not so much C as it is bare metal. At the bottom, in machine code, you have structured data (structs) and functions. That's all. There are a couple different calling conventions for functions, but they are largely immaterial and the standard ones vary by platform and architecture. If your language can't both use and output executable (library) files that export functions which process structs, it's not a serious language; it's a self-contained toy. It can't even do the most basic thing in computers.
Does your language have secret overhead functions? That's fine. Export them too. C++ exports its constructors and destructors. Garbage collection? Custom allocators? Export hooks. Does your lib depend on other libs? Well, wouldn't you know it, ld already handles that automatically.
If every language did this, like serious ones already do, then it wouldn't even matter what language your deps are written in. After all, it's all just machine code underneath.
As for culture, you can't hand-wave it. Tards are gonna tard, and if your language gives krazy glue to tards, don't be surprised when they glue their hands together.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.