> anyone can see what URLs you are visiting
this is not correct with HTTPS (query params are not part of the plain text)
Readit Newstbarbugli commented on An illustrated guide to OAuth ducktyped.org/p/an-illust... · Posted by u/egonschiele
So for <$1.7/day I can hire a programmer at a sort-of Claude Sonnet 4 level? I know it's got its quirks, limits, and needs supervision, but it's like 20x cheaper than an average programmer.
ofc it depends where you would hire, for me (NL) its above 100x more efficient
One should not use "drop-in" when they have their own query language and seemingly input shape for the /search endpoint (which is also different from Elastic, of course) https://manual.manticoresearch.com/Searching/Full_text_match...
It sounds like they're really targeting the logging search store part of ELK, which can be a perfectly fine objective, but no need to mislead audiences since they will find out and then you've made an enemy
I agree, only reason I read the project readme was to see the drop-in explainer.
Very misleading title
tbarbugli commented on Show HN: Comparing product rankings by OpenAI, Anthropic, and Perplexity productrank.ai/... · Posted by u/the1024
searching for running shoes returns a mix of brands and shoe models
tbarbugli commented on Doge Plans to Rebuild SSA Codebase in Months wired.com/story/doge-rebu... · Posted by u/danso
As someone who used to work for a Mainframe software vendor I'm tired of COBOL being considered "legacy" and bad. I didn't do much COBOL programming, but IBM is still releasing new compilers and new versions of z/OS for the Mainframe. Just because a language is old doesn't mean it's useless and worth rewriting. Instead of having COBOL be the boogeyman explain what the issues are. Is the system stuck on old COBOL versions do to lack of funding for upgrades, incompetence when it comes to long term maintenance plans, technical issues that make it impossible to move forward with new COBOL versions and would require a rewrite, etc. Are we going to see stories like this in 20 years about some company thinking they should rewrite the Linux Kernel in some new language and throw away all the C code that's been running for decades?
Plenty of engineers on the market can work professionally in C. Only a small amount of people can write Cobol (or is willing to given that is almost useless). That alone is a good reason to consider Cobol a legacy language and throw away a codebase written in Cobol.
tbarbugli commented on The hidden complexity of scaling WebSockets composehq.com/blog/scalin... · Posted by u/atul-jalan
> At Compose, every WebSocket message starts with a fixed 2-byte type prefix for categorizing messages.
some of the complexity is self-inflected by ignoring KISS principle
IMO the problem with gRPC isn't the protocol or the protobufs, but the terrible tooling - at least on the Java end. It generates shit code with awful developer ergonomics.
When you run the protobuf builder...
* The client stub is a concrete final class. It can't be mocked in tests.
* When implementing a server, you have to extend a concrete class (not an interface).
* The server method has an async method signature. Screws up AOP-oriented behavior like `@Transactional`
* No support for exceptions.
* Immutable value classes yes, but you have to construct them with builders.
The net result is that if you want to use gRPC in your SOA, you have to write a lot of plumbing to hide the gRPC noise and get clean, testable code.
There's no reason it has to be this way, but it is that way, and I don't want to write my own protobuf compiler.
Thrift's rpc compiler has many of the same problems, plus some others. Sigh.
In my experience, only Swift has a generator that produces good-quality code. Ironically, it’s developed by Apple.
tbarbugli commented on Kvrocks: Redis-compatible distributed key value NoSQL database kvrocks.apache.org/... · Posted by u/adulau
The list of supported commands looks quite impressive https://kvrocks.apache.org/docs/supported-commands#script-co...
tbarbugli commented on Distributed Transactions at Scale in Amazon DynamoDB (2023) muratbuffalo.blogspot.com... · Posted by u/lambrospetrou
Using DynamoDB in 2025 is such a weird proposition. Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.
Running workers ourselves was the last resort, we tried everything else but it was impossible to get fast (and consistent) build times otherwise.
In a way we are now going to get charged for Github's poor execution on Actions.