Rewriting the backend Bitwise Cloud, my semantic search for embedded systems docs Claude Code plugin from Python to Go.
The problem was the ML dependencies. The backend uses BGE-small-en-v1.5 for embeddings and FAISS for vector search. Both are C++/Python. Using them from Go means CGO, which means a C toolchain in your build, platform-specific binaries, and the end of go get && go build.
So I wrote both from scratch in pure Go.
goformer (https://www.mikeayles.com/blog/goformer/) loads HuggingFace safetensors directly and runs BERT inference. No ONNX export step, no Python in the build pipeline. It produces embeddings that match the Python reference to cosine similarity > 0.9999. It's 10-50x slower than ONNX Runtime, but for my workload (embed one short query at search time, batch ingest at deploy time) 154ms per embedding is noise.
goformersearch (https://www.mikeayles.com/blog/goformersearch/) is the vector index. Brute-force and HNSW, same interface, swap with one line. I couldn't justify pulling in FAISS for the index sizes I'm dealing with (10k-50k vectors), and the pure Go HNSW searches in under 0.5ms at 50k vectors. Had to settle for HNSW over FAISS's IVF-PQ, but at this scale the recall tradeoff is fine.
The interesting bit was finding the crossover point where HNSW beats brute-force. At 384 dimensions it's around 2,400 vectors. Below that, just scan everything, the graph overhead isn't worth it. I wrote it up with benchmarks against FAISS for reference.
Together they're a zero-dependency semantic search stack. go get both libraries, download a model from HuggingFace, and you have embedding generation + vector search in a single static binary. No Python, no Docker, no CGO.
Is it better than ONNX/FAISS? Heck no. I just did it because I wanted to try out Go.
Good spot, and gruez is right about the caption too (fixed both, thanks).
The car's L/hr figure was wrong. At 45 mpg (imperial) and 70 mph cruise, a car burns ~7 L/hr, not 3. That makes the flow rate ratio ~4x, which is consistent with 5x per mile and the truck travelling 20% slower.
The ~3 L/hr I originally had is what you'd see as an average over a mixed driving cycle — ~30 mph mean across urban, suburban, and motorway. I was carelessly mixing the cars combined-cycle flow rate with the truck's cruise-only figure in the same row.
The truck doesn't have this problem because a long-haul artic genuinely spends most of its operating hours in that narrow 50-60 mph cruise band. "Average fuel burn rate" and "fuel burn rate at cruise" are nearly the same number. For a car they're very different, transient acceleration, idling in traffic, and low-speed urban driving all drag the average flow rate down well below the motorway figure.
Probably the first thing to consider is the trucks have their speed calibrated periodically to ensure the accuracy of their tachographs (in the UK at least) so a truck doing 90kmph may show as 100kmph+ in a passenger car, I know my Volvo is 7% out, and my Seat is closer to 10% out.
That said, depending on the truck, there's fuses you can pull, ECU remaps and even for the older trucks with the magnetic sensor in the gearbox, the trick is/was to stick a magnet on the sensor (with a bit of string, so you can pull it off remotely if you get pulled over). All of these methods are becoming less feasible, as things like the aggregate wheel speed sensors used for ABS get used, you can't just fool one thing now.
As for the weight limit problem, that's a whole other rabbit hole!
Sorry, got mixed up there, will amend, the 60 is for +3.5t!
Edit: Nope, despite the vehicles only being able to propel themselves to 90kmph, the speed limit is indeed 60mph (in England and Wales, Scotland is a more sensible 56mph)
Short answer, it takes more energy to generate than the energy it produces.
You can do things like only producing electrical power from the alternator when decelerating, ensuring no load comes off the engine, but that would require accumulation as you're not actually burning fuel then either.
But running the numbers on the power requirements, I reviewed one commercially available system (at 12v 14A) and calculated that the HHO they are able to produce is 0.037% by energy going into the engine vs regular fuel.
When presented with 0.037% of the fuel substituted, their 10-15% claim on fuel savings becomes a bit of a red flag.
Surely that's a thermodynamic waste? Use the energy in the fuel to extract hydrogen from the fuel to them use the energy in the hydrogen to generate electricity to turn the wheels.
Is there a chemical process that achieves this with a better efficiency than just using the fuel to turn the wheels?
Fair point that a full TCO comparison would be more complete, and it's something I'm planning to cover in a later post. But the capital cost argument actually reinforces the conclusion rather than undermining it. Hydrogen fuel cell trucks are currently 2-3x the price of diesel equivalents, roughly comparable to battery electric. The infrastructure CAPEX is dramatically higher for hydrogen (£2-5M per station vs. transformer upgrades for depot charging). And the fuel cost gap means hydrogen has higher opex too. Diesel wins today on upfront cost, yes, but hydrogen doesn't beat BEV on capital or operating costs in any current scenario I've seen. Happy to be shown numbers that say otherwise.
The big thing I haven't covered yet is HVO, which provides the WTT CO₂ saving at a slight fuel cost surcharge, which matters if a fleet is mandated to reduce their CO₂. The TCO assuming a £100k diesel truck and £200k lifetime fuel cost, a 10% HVO surcharge brings the TCO to £320k, versus a £250-350k BEV truck that costs maybe £80k in electricity over the same life. That's £320k with an 80-90% CO₂ reduction from a drop in fuel you can put in your existing trucks tomorrow, versus £280k for battery electric with zero tailpipe. Both of those are available now, with existing infrastructure. Hydrogen is asking you to spend £300k+ on the truck, £150k+ on fuel, and hope someone builds a station within range of your routes.
It would be a stronger argument if you first tried looking at the cases where hydrogen has an advantage. The port example you brought up, where hydrogen is produced on site, is a good one to analyze. If you can look at cost projections of fuels cells and electrolyzers vs. batteries over the next 20 years and demonstrate that there’s no chance hydrogen will catch up, that would be a very strong argument, since it doesn’t rely on the hand-wavy “fueling infrastructure will never happen” argument.
Good catches, both of them. The hydrogen pathway should include grid transmission before the electrolyser, you're right. In practice it doesn't change the overall ratio much (multiplying by 0.95 on both sides) but the diagram should be consistent.
The BEV cost not adjusting with the electricity slider is a bug, not a choice. I'll fix both. Thanks.
Thanks. Both good questions, and they come up a lot.
To be clear, I'm fully behind decarbonising freight. It's one of the hardest sectors to clean up and it needs serious attention. But hydrogen for road transport requires jumping in with both feet (due to infrastructure requirements) when there are dozens of smaller, commercially proven steps that get you equivalent results. Better route planning, driver training, aerodynamic retrofits, hybrid and battery electric for shorter routes, even just reducing empty running.
These aren't exciting and they don't get press releases, but they compound. The industry could cut emissions meaningfully with changes that pay for themselves today, without waiting for a national hydrogen infrastructure that doesn't exist yet.
On surplus offshore wind: the economics only work if you assume the electricity is genuinely surplus, meaning there's literally no other use for it. In practice, the UK grid still runs gas plants for roughly 40% of generation. Every MWh of offshore wind that goes into an electrolyser instead of displacing gas is a missed decarbonisation opportunity. "Surplus" renewable electricity is a future state, not a current one, and even when we get there, interconnectors, grid storage, and demand response will compete for those MWh. The electrolyser only makes sense after all of those higher value uses are saturated.
On £1.50/kg: that would genuinely change the fuel cost picture, getting you to roughly 12-15p per mile which is competitive with diesel. But the distribution problem doesn't go away at any price point. You still need compression or liquefaction, transport, and a national network of dispensing stations. The UK has 11 public hydrogen stations. Even free hydrogen doesn't help if there's nowhere to fill up. The grid is already everywhere. Adding a charger to a depot is a transformer upgrade. Adding a hydrogen station is a £2-5M civil engineering project.
The place where cheap green hydrogen gets really exciting is exactly the applications where you can't just plug in: steel, ammonia, seasonal storage, maritime. Those don't need a distributed national refuelling network, they need point to point bulk delivery to industrial sites and ports, which is a much more tractable logistics problem.
I was reading the NASA truck aerodynamics thread earlier and realised that commercial freight is one of those fields that touches everyone's daily life (everything you own arrived on a truck) but sits in a complete knowledge blindspot for most people.
I work in fleet fuel efficiency and wrote up the foundational mental model, covering why trucks weigh what they weigh, why they're all doing exactly 56mph, why diesel is so hard to replace, and why 1% fuel savings matters when you're burning 43,000 litres a year.
This is the first in a series, there's already a 2-part deep dive on hydrogen up as well. Tried to keep it accessible without dumbing it down.
> Every driver in the UK has experienced this. Most assume the truck driver is being inconsiderate.
But then go on to explain how that is exactly true. The truck driver is taking time from *all* drivers on "roughly 4.5 miles of dual carriageway", just so that they can end the day 5 miles ahead.
> The five minutes of inconvenience to you saves them meaningful time and money over the course of a day.
It's five minutes of inconvenience to *everyone* on that 4.5 mile stretch of highway that nets the truck 5 minutes (5 miles ahead at ~60 mph). That's a very selfish and inconsiderate outcome.
A very well written article! I'd add a few things though.
> Every kilogram you add to the vehicle is a kilogram you can’t carry as freight.
That is only relevant when hauling bulk loads, think ore, soil and the likes, or you're carrying a trailer full of IBC liquid containers. I worked in stage lighting stuff, our trailers were at least 3/4 foam by volume, they didn't even come close to maxing out their weight.
> A battery pack storing equivalent energy would weigh on the order of 16 tonnes at current lithium-ion energy densities.
You don't need to haul a fully equivalent battery. Drivers have to have their mandatory rest breaks of 30+15 minutes here in Germany - that's enough to charge 300-400km of range. Additionally, they can be charged at loading docks, provided the freight base or the customer have chargers set up.
> For a driver paid by the mile, or on a delivery schedule measured in minutes, that overtake is rational.
Payment by mileage is illegal in Germany, as a trucker you need to be paid by the hour and you need to be paid under German minimum wage law as long as you're physically on German roads. Trucker companies from Eastern Europe are infamous for evading that, but as our customs enforcement (who also do the road inspections for rest breaks and minimum wage) ramps up, it's getting better.
The remaining problem are the dispatchers, quite a few of them hand out routes to their drivers that are barely achievable when operating legally (i.e. trucks with working speed governors, drivers taking their rest breaks). Competition is fierce, there used to be talks about passing laws to force dispatchers to not give barely-legal orders but I'm not sure where these went following our government's collapse last year.
> An electric drivetrain achieves around 90%, so you only need roughly 1,600 kWh of battery capacity for equivalent range.
Yup, and most importantly, you mentioned regenerative braking cutting down on brake wear - but it's not just cutting down there, the truck can actually save a fair amount of energy as well, at least outside of highways where the truck is mostly just coasting along.
Trucks, given the right infrastructure, are also viable for running them electrically in the mid-range nowadays as a result.
this is well written. thank you - you broke down the economics nicely.
I do think maybe with a hub & spoke model - big trucks move loads to hubs -- then smaller electrified trucks cover the less than 200 miles from hub to spoke. electrified smaller trucks and vans are already economical today.
you get to benefit from using diesel for long haul routes - while also - better economics on the electrified front i.e a hybrid model
And I'd rather have last-mile trucks with Direct Vision, no blindspots etc driving around city streets, backing into stores etc., than huge 44 tonne long haulers that can maul pedestrians in an instant.
The problem was the ML dependencies. The backend uses BGE-small-en-v1.5 for embeddings and FAISS for vector search. Both are C++/Python. Using them from Go means CGO, which means a C toolchain in your build, platform-specific binaries, and the end of go get && go build.
So I wrote both from scratch in pure Go.
goformer (https://www.mikeayles.com/blog/goformer/) loads HuggingFace safetensors directly and runs BERT inference. No ONNX export step, no Python in the build pipeline. It produces embeddings that match the Python reference to cosine similarity > 0.9999. It's 10-50x slower than ONNX Runtime, but for my workload (embed one short query at search time, batch ingest at deploy time) 154ms per embedding is noise.
goformersearch (https://www.mikeayles.com/blog/goformersearch/) is the vector index. Brute-force and HNSW, same interface, swap with one line. I couldn't justify pulling in FAISS for the index sizes I'm dealing with (10k-50k vectors), and the pure Go HNSW searches in under 0.5ms at 50k vectors. Had to settle for HNSW over FAISS's IVF-PQ, but at this scale the recall tradeoff is fine.
The interesting bit was finding the crossover point where HNSW beats brute-force. At 384 dimensions it's around 2,400 vectors. Below that, just scan everything, the graph overhead isn't worth it. I wrote it up with benchmarks against FAISS for reference.
Together they're a zero-dependency semantic search stack. go get both libraries, download a model from HuggingFace, and you have embedding generation + vector search in a single static binary. No Python, no Docker, no CGO.
Is it better than ONNX/FAISS? Heck no. I just did it because I wanted to try out Go.
goformer: https://github.com/MichaelAyles/goformer
goformersearch: https://github.com/MichaelAyles/goformersearch
reply