This would be amazing to see upstreamed! I did some similar work for optimizing batch calls for the Quartz Scheduler. I left before it got merged, but was able to follow up and get it in as it was already PR'd.
Yeah, as I said I wouldn't mind reimplementing it anyway. I still more or less remember what I did so I don't think it would be too hard for me to reimplement if I get enough free time.
Kafka Streams is one of those things that I think is like 95% cool, but there are some design decisions I have mixed feelings on. One big thing is that while it does give an API for making new state stores out of the box and it's not too hard to write that, it is all dependent on blocking IO. This isn't that big of a deal with the built in RocksDB store because the latency isn't that high for it, so you can get away with everything being blocking, but if you want to substitute another store (e.g. Redis or even something like PostgreSQL), the naive version has you dealing with round trip latency for every item for a join, which can two or three orders of magnitude more expensive.
Less naively you can implement batching and the like in your driver, which is what my first version did, but you do eventually have to add blocking, and the Kafka Streams library doesn't really utilize virtual threads so you're paying the full cost of it at the end. Eventually I just found it more elegant to make Kafka Streams non-blocking-aware and adding built-in semantics for batching to automatically amortize the cost of these things.
Anyway, sorry, just kind of miss working on that project. I really should redo it.
Not sure if it's still the case, but C library interop in C# is the main reason I chose to start with the alpha/beta versions of C# over Java around 2000-2001.
I think devx is being misused in this article a bit. Obviously the tooling for java is second to none, aside from maybe the travesty that is gradle.
What they apparently mean is how "ergonomic"/"expressive" the actual syntax and type systems of those languages are. In that case c# is ahead of java by a decent margin. Luckily java is still evolving, usually by stealing many of the good ideas from other languages like kotlin. But overall those are less language and more runtime features like project looms green threads etc.
Java has first class sum types, pattern matching, and compiler exhaustion on types. It's probably far more expressive than C# currently until they get union types.
Well, C# has more powerful pattern matching, only compiler exhaustiveness on types is missing today. In Java, sum types (sealed interfaces/classes) require all members to have the same parent, so they can be used only in very narrow cases.
Their sum types aren't particularly useful since they can never be used to implement union types which I believe c# has plans for following their sum types already in preview. So I guess similarly neck and neck.
Pleasant surprise to hear about this. I've had a fascination with BeOS & Haiku for decades. I am now actually developing a custom website layout themed after BeOS (good excuse to learn Figma!)
I spent a summer working on XAML UI's for an internship, and recently dove back in as a side project to update some Windows specific apps that rely on WinForms(https://github.com/hass-agent/hass.agent). XML UI's are fairly underrated imo.
Still use my L702x daily. It's heavy but I love the display and the speakers. It had Nvidia 3d vision with shutter glasses at one point, obviously not useful now. Windows 7 still on it. With an SSD it's still speedy and does a good job. I hope this 14 year old laptop will get me through another 6 years at least.
Thanks for the clarifications! I've been spending the last 3 weeks deep in the weeds of TF/IDF scoring and was about to give up on Elastic Search when this got posted. The article has been eye opening!!!
reply