ram_rar

Is it just me who is baffled, as to why is this surface level article getting soo much attention? a software company moved from one tool to another so what? There is no technical or non technical reasons mentioned in the article atleast. Why is this piquing interest in HN community. What am I missing here?

> “Zero hallucination.”

This is the part that bothers me the most. How is it 0 hallucination, if the correct answer is not even the part of the options. There is no way to mark absentia or a way to know I absolutely cannot choose any of the options.

I am wondering, if anyones tried dead simple combinations of embedding with logistic regression to solve classifications problems?

This advice only works at the team level. Beyond that, it’s borderline fantasy. At senior and leadership levels, promotions aren’t rewards for effort, they’re forward looking bets made by people above you, and those people have incentives, blind spots, and egos. Reporting to an insecure director or a clueless manager will quickly disabuse you of the “just do great work” myth.

Also, if the company isn’t growing, none of this matters. You can operate like a CTO all you want and all that happens is more work gets dumped on you for the same pay. Take on stretch work if you’re hungry for it and it’s explicitly acknowledged as next-level responsibility. Otherwise, you’re just volunteering to be exploited.

I’ve spent a decent chunk of my career wrestling with time sync — NTP/PTP, GPS, timezones, all that fun stuff. For real world network time infrastructure, where do we actually hit diminishing returns with clock precision? Like, at what point does making clocks more precise stop helping in practice?

Asking partly out of curiosity, I have been toying with a future pet project ideas around portable atomic clocks, just to skip some of the headaches of distributed time sync altogether. Curious how folks who’ve worked on GPS or timing networks think about this.

The article makes a fair case for sticking with OTel, but it also feels a bit like forcing a general purpose tool into a domain where richer semantics might genuinely help. “Just add attributes” sounds neat until you’re debugging a multi-agent system with dynamic tool calls. Maybe hybrid or bridging standards are inevitable?

Curious if others here have actually tried scaling LLM observability in production like where does it hold up, and where does it collapse? Do you also feel the “open standards” narrative sometimes carries a bit of vendor bias along with it?

I bought into the “leader vs. manager” Kool-Aid for years—until I actually had to manage. Spoiler: the dichotomy is a myth. Once you’re in the seat, it’s all gray area. You’re not just “inspiring people,” you’re stuck between upper leadership and your team, juggling chaos while trying to keep the ship afloat.

Any manager who’s been in the trenches knows the real game is shielding your team while still getting things done. Be as much of a “leader” as you want, but without authority and accountability, you’re just cosplaying. The rah-rah leadership Kool-Aid is mostly there to keep people inspired while the actual decisions happen in rooms you’ll never be invited to.

Out of curiosity, what's keeping you in slack ecosystem? Why not leverage Discord and run on your own server? Wouldn't that be a much economical alternative to begin with?

Is this deeply coupled with Chroma or something we can fork out for other applications? I would love to explore this for lightweight change data capture on S3.

I’m a bit underwhelmed by the quality of articles coming out of Netflix. 100 Million records / entity is nothing for Redis — even without RAW hollow-style compression techniques used (bit-packing, dedup, dict encoding is pretty standard stuff) [1].

Framing this as a hard-scaling problem (tudum seems mostly static, please cmiiw if thats not the case) feels like pure resume-driven engineering. Makes me wonder: what stage was this system at that they felt the need to build this?

[1] https://hollow.how/raw-hollow-sigmod.pdf

Unpopular opinion: in 2025, nobody should be reaching for an ORM first. They’re an anti-pattern at this point. The “abstraction” it promises rarely delivers—what you actually get is leaky, slow, and a nightmare to operate at scale.

The sane middle ground is libraries that give you nicer ergonomics around SQL without hiding it (like Golangs sqlx https://github.com/jmoiron/sqlx). Engineers should be writing SQL, period.

I have a ton of respect for José Valim and the Elixir core team, I have to say: Elixir just doesn’t mesh well with the kind of infrastructure tooling that’s become standard today. The ecosystem has been growing impressively and there’s a lot to admire, but its philosophy often feels at odds with containerized, Kubernetes-based deployments.

Elixir promotes a "do it all in one place" model—concurrency, distribution, fault tolerance—which can be powerful, but when you try to shoehorn that into a world built around ephemeral containers and orchestration, it starts to crack. The abstractions don’t always translate cleanly.

This opinion comes from experience: we’ve been migrating a fairly complex Elixir codebase to Go. It’s a language our team knows well and scales reliably in modern infra. At the end of the day, don’t get too attached to any language. Choose what aligns with your team’s strengths and your production reality.

As a non-native English speaker, I’ve often struggled to communicate nuance or subtlety in writing—especially when addressing non-technical audiences. LLMs have been a game-changer for me. They’ve significantly improved my writing and made it much easier to articulate my thoughts clearly.

Sure, it can be frustrating that they don’t adapt to a user’s personal style. But for those of us who haven’t fully developed that stylistic sense (which is common among non-native speakers), it’s still a huge leap forward.

Can someone help me understand how many companies are generally needed for healthy competition, as opposed to a market being considered fragmented or monopolistic? To the untrained eye, having 5 players might seem like a reasonable level of competition and suggest a functioning market. Personally, I’ve always seen food delivery as a premium service rather than an essential one — so it makes sense that there's a higher cost for the convenience of having a burrito delivered to your door in near real time.

I'm curious what led to the lack of demand for this—was it the friction involved in moving brokerage accounts, or do ETFs already meet the needs of most retail investors? A post-mortem on the limited traction would be quite insightful.

What uses cases would this be effective compared to using replacing merge tree (RMT) in clickhouse that eventually (usually in a short period of time) can handle dups itself? We had issues with dups that we solved using RMT and query time filtering.

Great to see Elixir gaining traction in mission-critical broadcast systems! I wonder, how much of Cyanview's reliability comes from Elixir specifically versus just good implementation of MQTT? and is there any specific Elixir features were essential that couldn't be replicated in other languages?

All jobs converge to sales at some point.

While dollar cost averaging and index investing are solid strategies, this article overlooks an important consideration: the Realistic Rate of Return (RoR) needed for retirement planning. Yes, US markets historically recover (lately that notion seems to be challenged more often than not), but timing matters significantly.

What happens if someone's retirement coincides with a market crash? Younger investors have time on their side for recovery, but as retirement approaches, blindly following market-based strategies without carefully considering your required rate of return could be problematic. Age-appropriate risk management becomes increasingly important as your investment horizon shortens.

Kudo to author and Cpython team to reckon this. Nevertheless, its still a very important improvement in +Ve direction. Thats all matters. This a great story as to why benchmarking are soo hard to get right. I always tell my team to benchmark your real world use case as closely as possible and not rely on external results.

Starting today in what scenario would RoR would be a better option than Next.js for building web app? Assuming one has to start from 0 -> 1 .

>The other reason is that you cannot split up a large established codebase without first understanding it. I have seen large codebases successfully split up, but I have never seen that done by a team that wasn’t already fluent at shipping features inside the large codebase

I cannot resonate with this. Having worked with multiple large code bases 5M+, splitting the codebase is usually a reflection of org structure and bifurcation of domain within eng orgs. While it may seem convoluted at first, its certainly doable and gets easier as you progress along. Also, code migrations of this magnitude is usually carried out by core platform oriented teams, that rarely ship customer-facing features.

As much as I love to use your product, the challenge from my perspective is why switch for 0.03% in fees? Especially when you compare it to likes of fidelity, vanguard , schwab. Those 3 are too big to fail. The point I am accentuating is, that just lowering the fees to 0 is not a compelling reason anymore, especially when the fees are soo low already, its race to the bottom.

While cell-based services make sense for critical applications, not all services require this approach from a Cost of Goods Sold (COGS) perspective. In practice, I've observed that companies often adopt an all-or-nothing approach to cell-based services, resulting in inflated COGS, increased operational overhead, and unnecessary complexity.

> The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.

Only If I had a dollar for everytime this happens. Choosing a language for the company is a business decision. we have a similar issue with Elixir and now the entire team is spending a quarter just to get rid of it. For anyone building startup on LLMs , this is one killer application I would pay for. The generated code doesn't event have to 100% correct, just right enough for devs to tweek would go a long way.

A limited job market, considerably smaller ecosystem (compared to java/python), and lack of support from major tech corporations (unlike Go or Rust) makes it challenging to adopt Elixir.

At my company , we inherited a legacy Elixir service, but we're actively moving away from it. We found it more practical to rewrite the service in Go (entire team is proficient in + LLMs make it easier to migrate) rather than invest time and resources into learning Elixir and its associated ecosystem. The return on investment for mastering Elixir didn't justify the effort required, given our specific circumstances and needs.

I do like to tinker with Elixir for hobby projects. But supporting a whole new language in a company is an uphill battle, that's incredibly hard to justify.

Kudos to htmx for their refreshingly honest blog post! I hope many other open-source tools especially Databases can do similar things.

>> while it’s important to consider lightweight alternatives, it’s equally crucial to choose technologies that can grow with your project and support your long-term vision

A key takeaway that resonates with me is the importance of choosing technologies with growth potential and a thriving ecosystem – essentially making a long-term bet on their success. Too many devs get entangled with adopting shiny new things, while losing focus on delivering real value to customers.

I appreciated the paper's effort to highlight data analysis techniques, but I was hoping for a more forward-thinking perspective.

The inclusion of pipe syntax or data processing using pipe-structured data flow syntax is not very novel at all. Splunk's SPL and similar languages have been a longstanding industry practice.

I wish the paper had provided more extensive references to the existing body of work in this domain, as it would have added depth and context to the discussion.

Articles like these need TL;DR Testing in prod is a tale as old as time.

It would have been more insightful to cover the underlying infra/tech that enables this seamlessly.

Can someone with a background in contract negotiation, vendor onboarding, and business continuity risk management share their expertise? We'd love to hear about typical vendor contract provisions that protect customers in situations like this.

If damages can be demonstrated, what are the chances of airlines successfully claiming compensation? Or, in practice, do such cases usually result in significant discounts during the next contract renewal rather than actual damages paid out?