[ramijames]

This is such nonsense. All the stuff that we use, someone wrote. If nobody makes them, then how is that going to work?

The messaging here is that you should be careful about using what you build on your own because it:

- hasn't been battle tested

- likely has bugs

- isn't mature

The only way that it will be all of those things is if someone invests time and energy in them.

From an ecosystem perspective this is absolutely the right thing. You want duplicate projects. You want choice. You want critical knowledge to be spread around.

[Swizec]

> If nobody makes them, then how is that going to work?

I see it as “Dont write your own X, unless you want to maintain X. Here be dragons, this problem is deeper than it appears, the first 80% will be easy, the next 15% will annoy you, and the last 5% will consume your life for weeks, months, or even years. Or you could use a library”

[ahartmetz]

The latter, if you want to get it completely right. I occasionally read the commits in the Qt framework, and from that, I can tell you that date-time stuff is complicated, and not in an instructive way, but in a super tedious way.

[mattmanser]

It's about exposure.

The things that people write that everyone uses have had HUGE exposure.

They've been exposed to all the edge cases, they've been tested millions, if not billions of times. All the bugs ironed out.

The people who've worked on them are now the greatest domain experts on that little corner of comp-sci.

Yours won't unless it hits prime time.

So yours will be weak, brittle and dangerous.

[zelphirkalt]

This assumes, that the practices/methods used to create a working library are suitable for solving the problems. They might be ill-advised and include tons of workarounds for bad design decisions. Too often following the advice of never reinventing anything (and possibly doing better), is how we ended up with stacking broken stuff on top of other broken stuff, limiting us at every turn with leaking abstractions and bad designs.

It is very possible to have a clean implementation with good design choices overtake an established in time, enabling more extensibility, modularity and maintainability.

An example: People still way over-use regexes for all kinds of stuff. Even in code editors people for syntax recognition, where people really should know better.

[gmueckl]

In order to have these mature libraries, someone hat to start building them. They all had to to be incomplete, immature and horribly buggy early in their lifetime, too.

[ozim]

I think there is missing point in this discussion.

Most of the time you build something else.

Like if you build a todo app and have to deal with scheduling you don’t spend time making date library because it’s not your goal. But people would do that.

Heck most developers instead of starting blog on a blog platform start writing code for their own blogging engine.

[mikestaas]

see https://rakhim.org/honestly-undefined/19/

[DANmode]

Holy shit.

The point is, before you release your new thing, make sure it addresses all of the pain points the previous solutions have already slogged through,

or that if it doesn't, people are still aware of when they can arise, and why your thing has chosen not to mitigate them yet,

or ever, if it's an opinionated piece of tech.

[commandlinefan]

Nah, finding that stuff is what users are for.