I know the author of CK, and he's very, very good. Better than me, I am sure of that!

I believe CK offers a delete-supporting hash, too, so it has a full O(1), which liblfds does not yet have.

While your humility is refreshing, why wouldn't people just use CK instead of liblfds?

The libraries are not identical; I'm not particularly up to speed with CK, I'm not a user, but there's so much that can be done with any data structure library that there will be things liblfds has done which CK has not, and naturally vis-versa, such that for some one of the libraries will be a better (or possibly the only) choice.

What those things might be I cannot much tell you, where I'm not particularly au fait with CK.

Might want to get acquainted then... if you've got competition for your library and you expect users to pick you, you should know why you're better IMO: http://concurrencykit.org/man.html

It's free and open source but in some regards it's similar to product design/marketing. If you don't pitch it, some reviewer on the internet will make a stackoverflow post about it, and they won't know your strengths as well as you do.

A blog I read recently outlined some things to figure out: https://blog.orangecaffeine.com/the-art-of-saying-no-db012a2...

From the other comments here it sounds like some unique things you have are:

* versioned datastructures that won't change during library upgrades

* self-documenting code style

It depends though where you're coming from.

I write the library for the pleasure of it. I'm aiming to create something I think beautiful - for better or for worse, from other people's point of view :-)

I'm not actually looking for it to be used as such. It may well be, if my idea of beautiful is any good, it will come to be used, but that's... it's like a side effect.

When you paint a picture, or sculpt a sculpture, or write a song, you're not competing with other artists to make what other people will judge to be the better picture, sculpture or song.

How does ConcurrencyKit compare to this? I've used concurrencykit a bit, and it's great. The only problem I have is that sometimes the documentation is lacking.

I went full-on, for documentation.

Many, many years ago, back at Uni, a friend of mine received 100% for his Uni project. I could code many years before I went to Uni, but I was shallow in all other ways - all the ways in which we actually produce quality, reliable, usable software. He showed me some of his project, and I saw his docs. What he'd done was absolutely fantastic - a page per API function, documenting the standard set of information that you need to use an API function. The approach you see in all the major projects today, the MS API docs, for example - this from a twenty year old!

That experience permanently set my expectations for documentation, and is reflects in the library docs. One page per function, per enum, per struct, etc, etc, etc. It's ALL documentated. Painstakingly, exhaustively.

There's absolutely no point in writing an API which people cannot use, for whatever reasons.

When I come to make a release, and I'm done (or rather, I think I'm done) with development, I write the docs.

This induces, always, a large final round of development work, as I come to realise, from attempting to document them, that some of what I've done is simply too complex or too awkward or too inherently confusing to use, and has to be rewritten.

I am of the view from my experiences that all developers should write their own documentation, because of the improvement in code quality that is induced by the code changes which come from keeping the docs comprehendable.

That is an amazingly nice home page for a project. No clutter, to the point, all the info I needs, and loads fast.

Thankyou! I hope you're right :-)