> It’s not only new projects putting strain on the grid though. The report found that an estimated 13 percent of US cloud consumption, totaling more than 3 gigawatts, comes from so-called "zombie" workloads—abandoned test environments and unused applications that continue to draw power without doing any useful work.
Containerized sandbox environments for AI can be incredibly wasteful. If those sandboxes are kept available so the user gets sub-second access that is a continual user of RAM, and thus overall computing resources. We built the first version of https://www.aha.io/builder/overview using a typical containerized environment - just like you see with products like Replit - but were appalled at the inefficiency and waste. We rebuilt it from the ground-up to use shared architecture instead with Javascript-level isolation, and almost zero waste. Using shared computing instead of containers means instant startup time, and (almost) zero resource consumption when not active. You still consume disk to store the artifacts, but there is no ongoing RAM or CPU.
I think a reckoning is coming for container-based AI systems too. We are seeing tokens trend towards reflecting the actual cost, and I think the same will be true of containerized runtime environments too.
It makes me wonder if remote-first companies will have an advantage in an AI-first world because they must be more intentional about communication. By their very nature remote teams use more written communication and more intentional, and documented, processes. Perhaps the RTO mandates will turn out to be the biggest organizational mistake?
> Why are you asking the token predictor about the tokens it predicted?
I am surprised with this response because it implies this is not an extremely valuable technique. I ask LLMs all the time why they did or output something and they will usually provide extremely useful information. They will help me find where in the prompting I had conflicting or underspecified requirements. The more complex the agent scenario, the more valuable the agent becomes in debugging itself.
Perhaps in this case the problem with hooks is part of the deterministic Claude Code source code, and not under the control of the LLM anyway. So it may not have been able to help.
Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 700,000 users worldwide. We are looking for:
* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.
* Devops engineers with Ruby experience. We focus on the "dev" and all of our operations driven by code.
Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.
Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.
I am surprised at the amount of hate for Stack Overflow here. As a developer I can't think of a single website that has helped me as much over the last ten years.
It has had a huge benefit for the development community, and I for one will mourn its loss.
I do wonder where answers will come from in the future. As others have noted in this thread, documentation is often missing, or incorrect. SO collected the experiences of actual users solving real problems. Will AI share experiences in a similar way? In principle it could, and in practice I think it will need to. The shared knowledge of SO made all developers more productive. In an AI coded future there will need to be a way for new knowledge to be shared.
Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 700,000 users worldwide. We are looking for:
* Experienced Rails security engineer to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.
Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.
Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.
Typescript. I imagine most people writing Rails applications are also writing typescript for front-end code, so being able to use the same muscle memory for Ruby typing seems high desirable. That is the thing that stood out to me when I saw this site: it looks like they are taking the very positive lessons from Typescript and applying them to Ruby.
I agree with other posters here. I don't need everything typed - Ruby's duck typing is an awesome feature - but I do wish that some of the more important interfaces in our code were more strongly self-documenting and enforced.
Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 700,000 users worldwide. We are looking for:
* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.
* Devops engineers with Ruby experience. We focus on the "dev" and all of our operations driven by code.
Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.
Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.
Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 700,000 users worldwide. We are looking for:
* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.
* Devops engineers with Ruby experience. We focus on the "dev" and all of our operations driven by code.
Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.
Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.
Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than a million users worldwide. We are looking for:
* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.
Aha! is profitable, you can work from anywhere in North America, South America or New Zealand, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.
Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.
Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.
We are looking for:
* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.
* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.
Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.
Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.
You can view open engineering positions at https://www.aha.io/company/careers/current-openings, and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.
It is always interesting to read genesis stories. I was especially surprised as I was reading this story to discover that the first prototype was built using the Javelin Stamp which I created. It is particularly ironic given that the rise in popularity of the Arduino was probably a contributing factor to the waning of interest in the Javelin Stamp.
Not to belittle the contributions of Hernando, he did great work. But so often each incremental step in technology is made with the help and inspiration from those who came before. It is the very nature of open source that it will be embraced and expanded.
Anyway, I was gratified to see now, that something I worked on 18 years ago would intersect with a such an interesting story, even if only in a tangential way.
At the time I wrote this code there was a lot of talk about Java specific processors. Ultimately that was a mistake because Moore's law meant the x86 architecture (and JIT technology) got faster more quickly that anyone could get chips to market.
These days I am about as far from embedded systems as you can get. I write Ruby on Rails code for aha.io. There is a lot of satisfaction in seeing the perfect waveform on your oscilloscope when the assembly code finally works - but these days I think there is much more satisfaction in being able to crank out a complex algorithm with some elegant Ruby and have it being used by customers before going home for dinner.
Well, it was 16 years since I wrote most of this so my memory is a bit fuzzy...
The stack and heap are both stored in an external 32kB SRAM. The stack is accessed simply by pushing and popping using the JVMPush and JVMPop routines around line 4553. The CPU is 8-bit, bit the JVM is 16-bit, so everything takes two operations to write both bytes. You can see the stack frame format at line 48.
Java objects and arrays are allocated on another stack that acts as the heap. Objects are allocate only - they are never freed. This isn't as big a deal as you might think since in embedded applications the code tends to just repeat the same operations over and over so you write your code to reuse the same instances instead of allocating new objects (which is slow anyway).
_do_new on line 2044 allocates a new object. Arrays are allocated at line 1991 in _l_j_newarray.
The nice thing about the JVM (at least version 1 which this implements) is that there are not many variations on operations - and if you statically link you can reduce some of the variations to common cases too.
Reading back over the assembly code gives me fond memories - but I am glad I don't spend my nights debugging my code with an oscilloscope and flashing LEDs anymore. It is a bit more productive coding in Ruby!
The JVM had some limitations to fit into 4k: no floating point, 16-bit integers and no dynamic linking. There was a PC program that took the Java class files, statically linked them and translated the bytecode to a more compressed form for download to the chip.
The update that describes why 4KB of RAM was necessary was interesting to me. In 1998 I wrote a Java Virtual Machine in assembly language for a PIC-like microcontroller that only had 4k of ROM (actually it was 4k instructions, but they were 12-bit words giving 6kB). I managed to get all of the important features of the language to fit, including exception handling and an interactive debugger. However by the end, each time I wanted to add a new instruction to my code I had to find something else to optimize first so it would still fit in 4k.
By the end I convinced myself that 4k was the minimum possible code size for implementing a JVM.
As an aside, the SX microcontroller only had 256 bytes (yes bytes!) of RAM internally so I used an external 32kB SRAM for the Java heap and stack. The 256 bytes of internal RAM held the internal state of the interpreter and memory manager.
> It’s not only new projects putting strain on the grid though. The report found that an estimated 13 percent of US cloud consumption, totaling more than 3 gigawatts, comes from so-called "zombie" workloads—abandoned test environments and unused applications that continue to draw power without doing any useful work.
Containerized sandbox environments for AI can be incredibly wasteful. If those sandboxes are kept available so the user gets sub-second access that is a continual user of RAM, and thus overall computing resources. We built the first version of https://www.aha.io/builder/overview using a typical containerized environment - just like you see with products like Replit - but were appalled at the inefficiency and waste. We rebuilt it from the ground-up to use shared architecture instead with Javascript-level isolation, and almost zero waste. Using shared computing instead of containers means instant startup time, and (almost) zero resource consumption when not active. You still consume disk to store the artifacts, but there is no ongoing RAM or CPU.
I think a reckoning is coming for container-based AI systems too. We are seeing tokens trend towards reflecting the actual cost, and I think the same will be true of containerized runtime environments too.