lovely-forks VS Confluent Kafka Golang Client

>One problem is discoverability. GitHub lists forks in an un-sort-able manner.

This obviously doesn't solve the problem generally, but I recently found an extension called lovely-forks[1], that automatically shows the most starred fork for every github repository.

1:https://github.com/musically-ut/lovely-forks

The post resonates with me as an OSS user and a contributor. Many a brave souls have taken to forking the project to fix the bugs but those forked projects almost always suffer from a discoverability problem. I have tried making fixes and tried forking projects only to discover that someone else has done it better elsewhere.

I've been burned by this problem often enough that I wrote a Chrome extension which would _tell_ me if there are any notable forks of the project I'm currently looking at on GitHub: https://github.com/musically-ut/lovely-forks .

Lovely forks is a chrome add-on built to bring your notice to notable forks (i.e., forks with the most stars) for GitHub projects. It helps to keep track of the community-appreciated fork by adding a subscription under the repository's name on the Github page of all projects with a link to that fork.

There are two main libraries that people use to write clients Confluent Kafka and segment io kafka

As my first "real world" (ish) project in Vlang, I'm trying to copy https://github.com/confluentinc/confluent-kafka-go, which is a Go wrapper for Kafka C client library, https://github.com/edenhill/librdkafka

You are right, but in practice that's not what happens. Companies do not rely on open source libraries, the developers working for such companies do.

I can give you a realistic example. If you want to use Kafka and Go, your probably only option is to use https://github.com/confluentinc/confluent-kafka-go. Its LICENSE explicitly says "no warranty". Now, what if I find a bug in the library? Only two realistic solutions from my side:

1. I submit the issue and hope for the maintainers to fix it

2. I dig deeper and try to fix the issue. I submit the PR

None of the above scenarios are guaranteed to have a happy ending. The issue could be ignored, or piled up among thousand of other (maybe higher prio) issues. My solution may not be optimal and could be rejected (or if it's optimal, nobody is taking a look at it, and it could remain open for weeks/months).

> If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them.

In the real world that would mean that I go to my manager and asks them to pay money to the maintainers of confluent-kafka-go to fix the issue I found. I don't think my manager would approve that, but let's imagine he does. The guys at confluent-kafka-go may not want money to fix the issue. These guys have probably already jobs that pay them well, and they work on the library at will.

Note: I'm talking about confluent-kafka-go, which I know is behind the Confluent software company. But I could as well be talking about libraries maintained by individuals like https://github.com/edenhill/librdkafka

it can be completely statically linked binaries. example: https://github.com/confluentinc/confluent-kafka-go/blob/db57ef6235/kafka/librdkafka_vendor/README.md

If you find the kafka input slow, try kafka_franz. It might be a bit faster, since it’s based on https://github.com/twmb/franz-go. The kafka one is based on https://github.com/Shopify/sarama. You can also write a custom input based on https://github.com/confluentinc/confluent-kafka-go, but this library relies on CGo, which can be annoying.

Last time I checked Confluent does not have a Schema Registry for Go, only for Java, so instead of that I rely on using the guidelines defined for the serialized data, specifically I've used gPRC+Protobuf for doing this, together with buf to detect breaking changes; buf has their own schema registry perhaps that could be something you could explore as well.

So, in the interests of full transparency - we at Zendesk are actually running a fork of confluent-kafka-go, which I forked to add, amongst other things, context support: https://github.com/confluentinc/confluent-kafka-go/pull/626

This bug actually happened because I mis-merged upstream into our fork and missed an important call to rd_kafka_poll_set_consumer: https://github.com/zendesk/confluent-kafka-go/commit/6e2d889...

Setup Kafka Producer using confluent-kakfka-go

I'd suggest https://github.com/confluentinc/confluent-kafka-go we switched from sarama-cluster with minimal work and it works fine. And we process approx 1.2M messages per hour.

In my company we use this https://github.com/confluentinc/confluent-kafka-go,