[eddd]

These buzzword product descriptions are terrible. Documentation should say first, what does this piece of code do and when should I use it. The actual rationale for this project is buried down in the middle of the documentation with a sparse 3 sentences.

> The first is to be able to track each message individually (i.e. not using a single commit offset) to make suitable for asynchronous tasks. > The second is the ability to schedule messages to be consumed in the future. This make it suitable for retries.

That's a start - I'd love to see how did you solve the problem? How your solution compares to other similar products? Why should I care about stuff you are mentioning? It is not an issue of not mature product - I think one should start with defining exactly and precisely what is being solved here.

When solving a technical problem you always have to tailor your solution to a specific set of requirements and it is never like: "distributed, horizontally scalable, persistent, time sorted message queue." So please stop using such buzzwords.

[aquadrop]

Those aren't buzzwords, when used right. It's dense searchable technical terms and are perfect for title. Do you think title should consists of two paragraphs?

[falsedan]

I think that product pages should clearly communicate what the product is to the intended audience. These are 100% buzzwords, so the message I get is, "you will need to spend more time with this project to see whether it is worth looking into".

The most convincing technologies have clear, simple value that's immediately apparent (like zeromq not needing a central coordinator/exchange), or some real-world use-cases which have been improved by using this technology (actual, already-happened use-cases, not hypothetical: I'm more convinced by words from people who've integrated with the product rather than the authors + their innate bias).

I would have put the title as, 'open-source proof-of-concept messaging queue (Go, single author)'

[yeukhon]

Searchable terms are fine. But product pitch is what people want. How many times have you searched for a concept or a tool just to find the official documentation/official site offers vague introduction? Or sometimes it takes some effort to find a meaningful description on the site because the site come with some weird layout? Then you end up search on the Internet for an alternate explainations from other sites?

I have had this too many times, exactly what OP said, even in areas I am strong in... often I have no clue or little clue what to expect without doing additional research.

[manigandham]

Those words are very descriptive and I got the entire purpose from just the title. The only other detail was individual message acks.

What do you feel is missing or miscommunicated?

[eddd]

I'd say they are too descriptive. I don't believe that this project provides such universal solutions and I expect from the author to clearly state what problem exactly does it solve. Ideally, as a picture/graph.

[zdragnar]

I seriously do NOT want pictures in titles. It's fine as-is.

[j_s]

> How your solution compares to other similar products?

This would be a clear violation of the unwritten open source policy to never mention similar/competing projects!

[pas]

So, is it a job queue or a message queue then?

[notheguyouthink]

Pardon the ignorant question, but what is the difference in brief? I'm clearly not familiar with queue software. I imagine the difference is that a job/task queue has mechanisms to track the state of a job - eg, completed, etc. Where as a message queue does not track state?

[pas]

A message queue can be extremely simple, like Redis pub-sub. Fire and forget, if you missed something, that's it. No guarantees.

Kafka is a bit more durable, you can build exactly once delivery with it (but only in order), but no selective ACK. RabbitMQ (AMQP in general) has selective ACK, so it has a state DB, and needs compacting.

A task/job queue is of course pretty meaningless without a task/job executor. And so there every message has some metadata, such as when to execute it, how many times to retry, timeout, where to execute (if you have labels or otherwise tagged workers/executors, you can think of this as channels of course).

The distinction is not very clear, just as you implied. A message queue with selective ACK can be used to build a job queue, but then you need to create a small library to serialize and deserialize your arguments, to register workers/tasks, and you need an event loop that listens for the messages, unpacks it, loads the task, runs it, and ACKs it.

In advanced (complicated/complex) job queues you can report progress (which is handy for checkpointing - but that's very much just a DB that the running task uses to persist some data, so almost orthogonal to the task scheduling function).

[notheguyouthink]

Appreciate the clarification.

[dullgiulio]

The title clearly says message queue. It doesn't seem to automatically do any task management.

[kachnuv_ocasek]

The tagline clearly says

> It was developed to support asynchronous tasks and message scheduling which makes it suitable for usage as a task queue.