obm_confluent_blog VS rustfmt

So what is actually the Schema Registry? And how does it help to make sense of binary data? In essence Schema Registry is an application with some Rest endpoints, from which schema's can be registered and retrieved. It used to only support Apache Avro. Later support for Protobuf and JSON Schema was added. Part of the same Github project, and what makes Schema Registry easy to use, is a Collection of Java classes that are used to go from bytes to typed objects and vice versa. There are several classes that support Kafka Streams and ksqlDB next to the more low level Kafka [Producer(https://kafka.apache.org/documentation/#producerapi) and Consumer clients. There are more advanced use cases, but basically you supply the url for the Schema Registry, and the library will handle the rest. For producing data this will mean optionally register a new schema too get the correct id. The consumer will use the encoded id to fetch the schema used to produce the data. It can also be used with other frameworks like Spring Cloud Stream. For example in the Kotlin Command Handler by using the SpecificAvroSerde class. You might need to set additional properties to get this working.

The author provides very surface-level criticism of two Rust tools, but they don't look into why those choices were made.

With about five minutes of my time, I found out:

wrap_comments was introduced in 2019 [0]. There are bugs in the implementation (it breaks Markdown tables), so the option hasn't been marked as stable. Progress on the issue has been spotty.

--no-merge-sources is not trivial to re-implement [1]. The author has already explained why the flag no longer works -- Cargo integrated the command, but not all of the flags. This commit [2] explains why this functionality was removed in the first place.

Rust is open source, so the author of this blog post could improve the state of the software they care about by championing these issues. The --no-merge-sources error message even encourages you to open an issue, presumably so that the authors of Cargo can gauge the importance of certain flags/features.

You could even do something much simpler, like adding a comment to the related issues mentioning that you ran into these rough edges and that it made your life a little worse, or with a workaround that you found.

Alternatively, you can continue to write about how much free software sucks.

[0]: https://github.com/rust-lang/rustfmt/issues/3347

[1]: https://github.com/rust-lang/cargo/pull/10344

[2]: https://github.com/rust-lang/cargo/commit/3842d8e6f20067f716...

The new style still supports single line let-else, and there is a configuration parameter to make it be on one line also for longer lines.

It seems there is an issue about this dating all the way back from 2018 but yet it still hasn't been fixed.

However since 4179 recent versions should merge configuration files. Not sure what the details / specifics are but if just ignoring the file entirely is not good enough you might give it its own directory and rustfmt.toml file and see if that works.

Could this be be #3863 - Gives up on chains if any line is too long? It might not be, because I can't see a specific "line" that's too long to format, but there's more detail about the exact problem in the issue.

Rustfmt is a tool that formats Rust code in compliance with style guidelines. Its name precisely reflects its purpose. To install rustfmt, you can run rustup component add rustfmt. Once installed, you can execute cargo fmt to format Rust code in your workspace. If you require further information, you can visit rustfmt’s GitHub repository.

code must be formatted with rustfmt.

Yes, some cases are not yet supported (https://github.com/rust-lang/rustfmt/issues/4914).

Just FYI, the let-else suggestions will only work until rustfmt settles on a format for it. So you may be surprised when this happens and it suddenly changes.