ram_rar
Joined 10 years ago
Joined 10 years ago
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?
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.
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.
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?
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.
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?
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.
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.
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.