adev_ (u/adev_) - Readit News

adev_ commented on Why was Apache Kafka created? bigdata.2minutestreaming.... · Posted by u/enether

That's what happened where I worked. The people making the tech decisions were worried they weren't "keeping up" and committed us all-in on kafka. That decision cost the company millions.

adev_ · 19 hours ago

> That decision cost the company millions.

And 5 years later the responsible of the decision left the company with a giant pile of mess behind him/her.

But let's see things positively: he can now add "Kafka at scale" on the CV.

adev_ commented on Why was Apache Kafka created? bigdata.2minutestreaming.... · Posted by u/enether

cowanon2222 · a day ago

I use MQTT daily. I'm not sure why the commenter suggested it; it is orthogonal to queueing or log streams.

MQTT is a publish/subscribe protocol for large scale distributed messaging, often used in small embedded devices or factories. It is made for efficient transfer of small, often byte sized payloads of IoT device data. It does not replace Kafka or RabbitMQ - messages should be read off of the MQTT broker as quickly as possible. ( I know this from experience - MQTT brokers get bogged down rapidly if there are too many messages "in flight")

A very common pattern is to use MQTT for communications, and then Kafka or RabbitMq for large scale queuing of those messages for downstream applications.

adev_ · 20 hours ago

> it is orthogonal to queueing or log streams.

That is currently the problem.

A lot of usage of Kafka I have seen in the wild are not for log stream or queing but deployed as a simple pub/sub messaging service because "why not".

adev_ commented on Why was Apache Kafka created? bigdata.2minutestreaming.... · Posted by u/enether

mrweasel · 2 days ago

I previously helped clients setup and run Kafka clusters. Why they'd need Kafka was always our first question, never got a good answer from a single one of them. That's not to say that Kafka isn't useful, it is, in the right setting, but that settings is never "I need a queue". If you need a queue, great, go get RabbitMQ, ZMQ, Redis, SQS, named pipes, pretty anything but Kafka. It's not that Kafka can't do it, but you are making things harder than they needed to be.

adev_ · 2 days ago

> Why they'd need Kafka was always our first question, never got a good answer from a single one of them

"To follow the hype train, Bro" is often the real answer.

> If you need a queue, great, go get RabbitMQ, ZMQ, Redis, SQS, named pipes, pretty anything but Kafka.

Or just freaking MQTT.

MQTT has been battle-proven for 25 years, is simple and does perfectly the job if you do not ship GBs of blobs through your messaging system (which you should not do anyway).

adev_ commented on AI is predominantly replacing outsourced, offshore workers axios.com/2025/08/18/ai-j... · Posted by u/toomuchtodo

cantrevealname · 7 days ago

> AI and robotics nullify any comparative advantages low wage countries had

If we project long term, could this mean that countries with the most capital to invest in AI and robotics (like the U.S.) could take back manufacturing dominance from countries with low wages (like China)?

adev_ · 7 days ago

> could take back manufacturing dominance from countries with low wages (like China)?

The idea that China is a low wages country should just die. It was the case 10y ago, not anymore.

Some part of China have higher average salaries than some Eastern European countries.

The chance of a robotic industry in the US moving massively jobs from China only due to a pseudo A.I revolution replacing low paid wages (without other external factors, e.g tarifs or sanctions) is close to 0.

Now if we do speak about India and the low skill IT jobs there. The story is completely different.

adev_ commented on C++26 Reflections adventures and compile-time UML reachablecode.com/2025/07... · Posted by u/ibobev

dwroberts · 22 days ago

> It is rare to read something more moronic than that

It's not actually wrong though is it - real codebases have been implementing reflection and introspection through macro magic etc. for decades at this point.

I guess it's cool they want to fix it in the language, but as always, the approach is to make the language even more complex than it already is - e.g. two new operators (!) in the linked article

adev_ · 22 days ago

> been implementing reflection and introspection through macro magic etc. for decades at this point.

Having a flaky pile of junk as an alternative is never been an excuse to not fix the problem properly.

Every proper modern language (Rust, Kotlin, Zig, Swift, even freaking Golang) has a form of runtime reflection or static introspection.

Only C++ does not. It was done historically with a mess of macros or a pre-compiler (qt-moc) that all have an entire pile of issue.

> the approach is to make the language even more complex than it already is - e.g. two new operators

The problem of rampant complexity in C++ is not so much about the new features when they bring something and make sense.

It is about its inability to remove the old stuff even if it is consensual that it is garbage (e.g iostreams).

adev_ commented on C++26 Reflections adventures and compile-time UML reachablecode.com/2025/07... · Posted by u/ibobev

tw061023 · 23 days ago

It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping actual software.

No way anything std::meta gets into serious production; too flexible in some ways, too inflexible in others, too much unpredictability, too high impact on compilation times - just like always with newer additions to the C++ standard. It takes one look at coding standards of real-world projects to see how irrelevant this stuff is.

And like always, the problem std::meta is purported to solve has been solved for years.

adev_ · 22 days ago

> And like always, the problem std::meta is purported to solve has been solved for years.

It is rare to read something more moronic than that

The Rust equivalent of std::meta (procedural macros) are heavily used everywhere including in serialization framework, debugging and tracers.

And that's not surprising at all: Compile time introspection is much more powerful and lightweight than codegen for exactly the same usage.

adev_ commented on The .a file is a relic: Why static archives were a bad idea all along medium.com/@eyal.itkin/th... · Posted by u/eyalitki

high_na_euv · a month ago

>The fact you (probably) never had to manipulate it directly just mean your higher level work never brought you deep enough where it starts to be a problem.

Did you just agree with me that other prog. ecosystems solved the building system challenge?

adev_ · a month ago

> Did you just agree with me that other prog. ecosystems solved the building system challenge?

Putting the crap is a box with a user friendly handle on it to make it look 'friendlier' is never 'solving a problem'.

It is barely hiding the dust under the carpet.

adev_ commented on The .a file is a relic: Why static archives were a bad idea all along medium.com/@eyal.itkin/th... · Posted by u/eyalitki

high_na_euv · a month ago

.so .o .a .pc holy shit, what a mess

Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system

adev_ · a month ago

> Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system

This is such an ignorant comment.

Most other natively compiled languages have exactly the same concept behind: Object files, Shared Libraries, collection of object and some kind of configuration description of the compilation pipeline.

Even high level languages like Rust has that (to some extend).

The fact it is buried and hidden under 10 layers of abstraction and fancy tooling for your language does not mean it does not exist. Most languages currently do rely on the LLVM infrastructure (C++) for the linker and their object model anyway.

The fact you (probably) never had to manipulate it directly just mean your higher level superficial work never brought you deep enough where it starts to be a problem.

adev_ commented on Strategies for Fast Lexers xnacly.me/posts/2025/fast... · Posted by u/xnacly

viega · a month ago

The computational complexity for lexing C++ is linear, but for parsing C++ it's super-linear, as will be many analyses. In practice, the lexing is in the noise for almost all compliers.

adev_ · a month ago

Even the lexing is not strictly linear.

Good luck to naively differentiate if '>' is effectively a chevron operator or a shift operator '>>' in a random nested template expression like : 'set<vector<int>>'.

adev_ commented on Strategies for Fast Lexers xnacly.me/posts/2025/fast... · Posted by u/xnacly

SnowflakeOnIce · a month ago

A simple hello world in C++ can pull in dozens of megabytes of header files.

Years back I worked at a C++ shop with a big codebase (hundreds of millions of LOC when you included vendored dependencies). Compile times there were sometimes dominated by parsing speed! Now, I don't remember the exact breakdown of lexing vs parsing, but I did look at it under a profiler.

It's very easy in C++ projects to structure your code such that you inadvertently cause hundreds of megabytes of sources to be parsed by each single #include. In such a case, lexing and parsing costs can dominate build times. Precompiled headers help, but not enough...

adev_ · a month ago

> Now, I don't remember the exact breakdown of lexing vs parsing, but I did look at it under a profiler.

Lexing, parsing and even type checking are interleaved in most C++ compilers due to the ambiguous nature of many construct in the language.

It is very hard to profile only one of these in isolation. And even with compiler built-in instrumentation, the results are not very representative of the work done behind.

C++ compilers are amazing machines. They are blazing fast at parsing a language which is a nightmare of ambiguities. And they are like that mainly because how stupidly verbose and inefficient the C++ include system is.