I agree with what I think you meant: it is not a bug in Claude. However "javascript on the backend" is exactly what Claude Code is! It's a node.js implementation of automation components that feed and pull from the Claude model.
I have a VERY hard time believing that they only use JSON serialization between the model and the TUI. If they're seriealizing JSON between agents, tools, or other components, then this problem is going to continue to persist for a very long time.
This symptom was affecting display of numbers in the TUI, but the real bug/design flaw is using jq or JSON as a transport mechanism between components or between tools. JSON's number range is famously poor and it even architecture-dependent. So if you use jq or JSON to connect components or tools, you will have this same problem silently occurring elsewhere without visibility in the UI.
This is a bigger deal than it seems like! A confidence-inducing fix would include a blog post describing a top-to-bottom audit of jq/JSON used as a transport layer between tools and components. Not just a patch to the most visible problem.
It made it to the front page at about #11. Then apparently the editors renamed it to the (less interesting/more convoluted) title of the page it linked to. I didn't cause or approve that change. Why does HN rewrite my post? Is it because it was negative to Claude Code?
This question sounds like it was asked by a private equity investor looking to sample the tech zeitgeist before buying up and destroying some beloved tool.
That book has a few sections describing policy arguments on the floor of the New York Senate which are so well written that they are absolutely riveting! It sounds ridiculous to say that political arguments (from 100+ years ago) could keep you on the edge of your seat, but they do. It’s why this book the Pulitzer Prize.
UI/UX engineers or full-stack engineers with experience designing and building front-end software in React and Typescript.
-or-
Scala engineers with experience designing, building, and optimizing compilers: Mid- and Senior- Levels
thatDot has created the world's first Streaming Graph, called "Quine" to make interpreting high-volume data streams dramatically faster and easier [1]. After 7 years of DARPA-funded research and development with a fantastic team of engineers, it's a game-changing core infrastructure technology. Our products are used by major security companies to do real-time behavioral analysis, monitor and triage their alarms, and automate remediation of security threats.
We're an early-stage venture backed company, and now is a great time to join! We believe strongly that each person should get more from their job than just a paycheck! It should be interesting, provide a chance to learn new things, help advance your career, work with amazing and kind people, and be fun! A person ≠ their opinions. We value individual people who know how to disagree productively with each other so we can all learn. We deliberately cultivate a space where learning new things is the goal.
More than a year after my father died, my 6 year old son was inconsolably crying one night as my wife put him to bed. He hadn’t said anything about my father’s death until this night when he realized that it meant some day I would die. He was so sad at the thought and assumed I must be so sad about my father dying, that he was sad for me. I laid in bed with him talking about death and telling him how my father died—of COVID-19. It made my son think of vaccines. We spoke for an hour about how confronting death a little bit at a time throughout life—in stories or our own thoughts—is like a vaccine that helps us with the pain of losing our loved ones and eventually our own death. And for me, laying in bed crying with my six year old son about the death of his grandfather has been one of the best moments of my own life.
How is it that no one has yet suggested Randy Pausch’s famous “Last Lecture”? (Carnegie Mellon University) It is not a series, but it’s the culmination of a life’s work by an incredible person lost too early.
That’s not an optimized benchmark, just a demonstration using a real customer workload. Throughput depends on the workload but goes up to about 20,000 events per second per machine. All this is while simultaneously querying the graph and streaming out 20,000+ events per second. All that includes durable storage.
Price it out against Neptune instead and Quine is much less than 1% of the cost.
Quine started as a personal project on the side while taking time off before a new job. It was 2014. My first child was 8 months old and finally sleeping through the night. Time to start a new code repo. Quine was born as the union of graph databases + stream processing systems, eventually became the centerpiece of a major DARPA-funded research project, and is now an open source project with a commercial company supporting it.
I’d been bouncing back and forth between software engineer and manager at a few mature enterprise software startups, and so I had first-hand experience of how customer configuration had spiraled out of control. It took an army to deploy the product after closing each sale. Complicated configuration for many product components led to a graph data model. Configuration changes occurred slowly enough that it was feasible to put in a graph database. That was a cool project.
Moving to real-time event streams at another company focused on mobile push notifications, there were challenges similar in complexity, except they occurred at much higher volumes. Graph databases were definitely too slow! —but the problem was still graph shaped. So I worked alongside other engineers trying to "turn the database inside out." We created complicated microservices which ended up covering the same challenges as a database. What if all the parts could be configured together automatically?
Quine was created as an experiment to try to unify a graph data model with a streaming-focused graph computational model. The Actor Model is an old idea (Carl Hewitt, 1973) but a powerful and fundamental abstraction which appears in many surprising ways. It is perfect for this problem.
Every day, all of my spare time was working on Quine. We had a second child and there was even less time, so I'd stay up late coding until I couldn't keep my eyes open. I'd take Saturday daytime to be with my family, and then sneak away in the evening and again all Sunday to keep working. During the sleep-deprived and crying-baby-interruption years, when felt like I wasn't making enough progress, I would get up early to spend 2 hours at a coffee shop before work in order to get some focused time for coding.
By this point, my day job was leading DARPA research programs. One of these was Transparent Computing [1], a program focused on finding Advanced Persistent Threats ("APTs") in enterprise networks. The problem required assembling instrumentation data into a graph, analyzing it on the fly, and finding unusual patterns indicating the attacker's activity. Trying to be good stewards of our research funds, we started with existing graph databases. The program goals quickly exceeded the capabilities of every graph database out there, and I trudged through all the legal paperwork to properly allow the use of my side project on this research program.
Quine was the only way to store and analyze a graph that could keep up with the high volume of data on this project; we had tried everything else. So our team focused on developing Quine in the direction needed by the research. By the end of the project, it was exceeding the research goals (40,000 events per second, ingest+analysis) and it was clear that we had a tiger by the tail.
After the research program concluded, I raised early seed funding and hired a team to help bring Quine to market. In 2022, we realized that goal and Quine was released as open source software. Our team is now fully focused on developing the open source community for Quine and supporting the enterprise version. Our team recently showed linear scaling and tested it well-past 1,000,000 events per second (ingest+analysis). We’re excited about where this headed next! The future of Quine is rooted in the open source project and with many of the most interesting applications coming from the high-volume users we're engaged with now.
I have a VERY hard time believing that they only use JSON serialization between the model and the TUI. If they're seriealizing JSON between agents, tools, or other components, then this problem is going to continue to persist for a very long time.