Does "Neu" framework still exists?

[vovkasm]

List contains link to "Neu" framework:

Neu - A C++ 11 framework, collection of programming languages, and multipurpose software system designed for: the creation of artificial intelligence applications.

1. Link "https://github.com/andrometa/neu" points to not existent repository.
2. Search in google expose phoronix news page "http://www.phoronix.com/scan.php?page=news_item&px=MTY4OTg" and some other pages all from first half 2014.
3. Phoronix article contains link to home page "http://neu.andrometa.net" which shows nothing.

Is framework that doesn't ever exists can be in "awesome" list?

PS. Some sort of "policy" about libraries in lists would be good to have. Something like "library should be used in at least 3 real world projects and at least 10 users vote to include it in list" or other criteria.

[ghost]

In my opinion just blasphemy of you to call it for such rule. It is already not enough programmers C++, and you still increase an entrance threshold in technology — idiocy.

[ghost]

Да и вообще, надо было мутить PR для удаления, а не пиздеть наставлять правила раньше времени)

[fffaraz]

You are 100% right. I try to list only well-known and mature libraries. Usually I look at the stars and fork count, commit history, contributors, etc. It's a good idea to have a written policy and some basic rules as you said in our contribution guidelines.
Neu had about 60 stars at the time. I don't know what happened to it. It's not feasible for me to check all these links every day and decide if they still deserve to be listed or not. That's why we have these lists on GitHub! Please send a PR to remove it from the list as your friend suggests.

[vovkasm]

Thank you @fffaraz for answer!

Just created pull request to remove Neu framework.
I decide to write issue instead of PR primary because someone can still have sources of the library in public...

And my sentences about policies was written because i thought: "If list has explicit policy then some scripts can be written to automate maintenance work".

Anyway this issue can be closed, thank you!

[jpetso]

Regarding rules for libraries to include, I would like to note the very first sentence in the README:
A curated list of awesome C/C++ frameworks, libraries, resources, and shiny things.

In general I think it's a good idea to err on the side of listing too many projects compared to too few. awesome-cpp has helped me find a number of interesting projects that way, and in the end it's up to me to consider the respective characteristics and trade-offs of each project and decide whether I want to use it for my own purposes.

On the other hand, I think the curated part still has a role to play. You're the owner of this repo, so you decide what to include and what to leave out. I think it's a bad idea to turn pull requests into popularity contests - some projects are newer but still cool, some cover a niche that most people don't need but the ones that do should know about it, some are popular but otherwise inferior to a replacement on all fronts.

In my opinion, the role of a curated list should be to try and list projects that offer tangible benefits or sensible trade-offs compared to others that would seem like a more obvious choice. Ideally I would like to get a quick overview of the relevant characteristics compared to another. For instance, Boost.Log's strength are portability, tags, extensibility, decent API, availability as part of Boost and reasonable documentation, weaknesses are performance, no threaded "instant returns" (although that can also be a strength depending on your use case), no support for no-RTTI, high threshold for contributing. However, it's understandable that a proper analysis and comparison of projects against each other requires a lot of work, deep knowledge and also more space in the README than is probably reasonable.

So I think awesome-cpp should mainly look for throwing out projects that are clearly worse than the rest in most or all aspects, and allow other projects to duke it out among themselves. I think the list has been doing a pretty decent job so far, except I'd probably get lost among all the JSON parsers. But hey, it's possible that they all offer unique benefits or trade-offs, or are at least not worse than any of the other ones. You've already got that ⚡ icon which I think stands for the more popular ones, so according to that I should most likely consider nlohmann/json, RapidJSON and LIBUCL. That seems sensible to me and I think it's a good system.

In summary, I think the approach so far has been working and if obsolete projects get cleaned out every now and then, awesome-cpp will continue being useful. In the end, you should be making a judgment call based on popularity, (perceived) quality of code and documentation, usefulness and whatever factors seem appropriate. But it's your repo, and you're the curator. Embrace that power! :)