Hacker News Reader

A more generous interpretation would be that if you have a communal library, rather than everyone having their own individual libraries, it's easier to vet it for correctness. Rust takes the communal approach. The parent was suggesting that every company has an insular library approach. NIH.

Many people that go off the beaten track often fall into the same ditch.

Correctness yes but what about other requirements people have such as performance, extended functionality, domain-specific optimizations, predictability, etc.

Third-party libraries were not born out of the thin air but because of different parties having different and very much often disjoint requirements so it's not particularly NIH syndrome.

There is a huge gap between something like boost that is designed to be reused and internal libraries that are subject to the usual corporate constraints (the least amount of work is done if even that).

> There is a huge gap between something like boost that is designed to be reused and internal libraries that are subject to the usual corporate constraints (the least amount of work is done if even that)

You're somehow trying to imply that libraries are not reusable if they are not widely shared, which makes no sense at all.

The best argument you could make is regarding stability, but you simply cannot lay any such claim just from the library's licensing.

Accusing internal libraries of being half-baked, badly designed, or bug-riddled is just a cheap blanket putdown.

> It sounds like you're talking about using libraries as if it was a bad thing.

I don't see the relationship... how do you make such a leap?

> Where do you think "off-the-shelf" stuff comes from?

I worked on proprietary projects that eventually went public domain. So, I can tell you where off-the-shelf comes from from personal experience. Proprietary in-house tools have the benefit of not having to deal with many things that an off-the-shelf tool would have to deal because they can choose the kind of hardware to run on, the kind of supporting libraries, their versions and combinations to use, the kind of developer tools to support and so on. off-the-shelf tools, in order to be successful must cover a much wider area of ecosystem in order to be relevant.

Here to give you a better example: C doesn't have its own concurrency primitives, no concurrency model etc. But, you could build an extension, let's call it CC to have some sort of concurrency based on pthreads library. If, for your internal needs, you only use CC on Linux -- you are golden and everything works fine. Once you try to make CC into off-the-shelf product you have to do something about pthreads missing from other platforms.

Off-the-shelf products are typically born as in-house products, but they need an extra step to become what their name implies.

In the specific case of what OP described as their own extension to C, I can vividly imagine a language that doesn't cut it as an off-the-shelf one. Making an off-the-shelf language would've also guided OP to a much larger departure from C because memory safety is only one of the big problems with the language. And this is what happened to a bunch of other languages which already walked a big chunk of that departure journey. This is why I would've been frustrated having to use the language like OP's: it would've felt like not enough change and too much headache to adjust to my target environment than could be had by using actual off-the-shelf languages.

> You're showing a tremendously naive and misguided belief that libraries are somehow bad.

I have no idea where you get this from. If anything, I say the exact opposite...