Are there performance worries about passing around two pointers for anything that needs to allocate, as well as storing these pointers in a struct? AFAICT this basically means two registers are eaten, and a lot of types have effectively 16 bytes of overhead. It seems like this could quickly change the calculus on what fits within cache lines and what doesn't, which people often care about for very high performance code.
I wonder if it's possible to change the compiler to detect that, if what is being used in arguments is the global default allocator, the first argument can be stripped and all references inside the function can be replaced with the global pointer. Potentially the same concept could apply to allocators that use thread local storage. (perhaps these optimizations already exist?)
I’ve tried to make the kgo package easier to use, but I think some libraries suffer from over abstracting the underlying protocol, which ultimately locks them out of some higher efficiency code or some correctness. So, I’ve tried to make the library simple yet not hide all of the details. It’s seemed to have panned out successfully for at least some people. Happy to answer any questions about it, and thanks for taking a look!
I spent quite some time writing github.com/twmb/franz-go due to wanting more from both Sarama and from Segment’s library. Pure Go as well.
I’d recommend evaluating it as an alternative, even to confluent-kafka-go due to comprehensive feature support and (afaict) even higher performance than the aforementioned libraries.
It isn't yet integrated with the schema registry, but I think doing so would be a fairly straightforward task. My primary goal before this "Show HN" was 2.6.0 feature completeness.
I'll look into integrating with the schema registry within the next month. Thanks for the reminder!
edit: there's a few other minor kafkacat features that I'd like to implement as well, such as start and end times for consuming, and producing entire files. I think those two, in addition to avro schema registry, are the main features this is missing, but otherwise kcl is much more featureful.
Long term, I think it'd be great to add support for secrets in vault, but I'd like a bit more usage before considering integrating that.
The opinion article you linked is from a right-rated source [0]. The main suggestion in it,
> That would start with the federal government imposing a national, revenue neutral carbon tax of about $200 per tonne of emissions, immediately (not $50 in 2022 under Trudeau’s plan) and then returning all the money raised back to Canadians in dividend cheques.
has pretty wide support on the left. I'm not sure how that differs from being wealth redistribution, which is what the opinion piece is against. It also doesn't describe what the current scheme is nor how it is wealth redistribution.
As far as party support for nuclear, [1]. Democrats care more about wind/solar. Neither party has majority support for emphasizing nuclear. I don't think people that care about CO2 would rule nuclear out if it were the only option.
Jets vs. thermostat type problems are tragedy of the commons. I don't appreciate private jets ferrying around political leaders, but I doubt they'll be flying commercial. That doesn't seem practical from a security nor time perspective. But, millions of people adjust their thermostats. If everybody tolerated just a liiiiittle bit less than their ideal temperature, how much would that save? Consumption is a tragedy of the commons problem.
I'd like evidence that limousine liberals are the problems w.r.t. taxes. I agree that there is hypocrisy. I disagree about how it rings hollow compared to redistributing the means, especially since "redistributing the means" doesn't even really make sense in that block of text.
Lastly, studies aren't full of blatant inaccuracies nor FUD. The world isn't ending outright, but it's getting a lot worse in a lot of ways in a lot of areas. The Syrian civil war was partially exacerbated by the worst drought ever recorded [2]. The science is settled. Exxon Mobile predicted [3] exactly what would be happening today [4] back in 1982. The conclusion of their summary is that serious adverse problems are not likely to occur until the late century, and that the time should allow for coming up with solutions. That time is now, and globally, we are doing very little, because doing what needs to be done would be economically detrimental to established interests.
As a recent Brave convert, I was skeptical of Brave for the same reason.
I switched to it from Firefox (after switching months ago from Chrome) due to Firefox being slow, tabs repeatedly crashing, UX disharmony, and the recent cert addon debacle.
Brave's ad proposition makes sense: the internet is inundated with ads, which is unpleasant, but free websites do need to survive. So, make the ad landscape nicer on an opt in basis.
This is a decent reminder blog post about something that is obvious on the surface, but subtle when you forget to think about it and make a mistake.
I've found that thinking of a lock as something you don't want to hold goes a long way. The point of locks is to release them.
Jeff Preshing has a good series on locks and concurrency. This[0] post (potentially with an extra dozen I read in the same sitting) is the one that really changed how I thought about locks: before I read it, I was very into lock freedom at every opportunity.
I wonder if it's possible to change the compiler to detect that, if what is being used in arguments is the global default allocator, the first argument can be stripped and all references inside the function can be replaced with the global pointer. Potentially the same concept could apply to allocators that use thread local storage. (perhaps these optimizations already exist?)