r/compsci

Heyyy r/golang I have always felt that Go doesnt have some good matrix packages, so I decided to make one, been working on this for almost 4 months now, was slacking a bit due to college exam but finally I completed it, would love some feedback on this!!
Repo link:- https://github.com/Arceus-7/matrix
Go package page:- https://pkg.go.dev/github.com/Arceus-7/matrix
I hope this will be useful for many people <3

So I've been experimenting with Comet, an LLM-based AI agent by Perplexity, and decided to throw it into one of the most chaotic casual games I could think of — Skribbl.io. No scripted help, no API access to the game. Just the AI reading screenshots, parsing the DOM, and acting like a player.

Here's what happened:

• It competed against 5 real human players across 3 full rounds
• It finished 1st place with 2,165 points
• It achieved a 67% word-guessing accuracy
• It actually attempted to draw — with mixed results (turns out controlling a mouse pixel by pixel is hard)

What blew me away wasn't just that it won — it's how it reasoned. It used letter constraints to narrow down words, ranked vocabulary by frequency, and adapted its strategy round by round. It also ran into genuinely funny failure modes, like accidentally drawing with the eraser the whole time.

I ended up writing a full research paper analyzing the whole session — the methodology, results, failure modes, and what this might mean for using games like Skribbl.io as AI benchmarks going forward. It's been submitted to SSRN and published on Academia.edu.

Full paper here: https://docs.google.com/document/d/e/2PACX-1vQMPjRYBeFTF0376cjADgkiKOwlKQK9YPXnhimGlq5eKAdK0nv0hBjS-W3OOY_uIhjHvsP56hzMruJ0/pub

Vercel Labs just dropped Zero (.0 file extension), an experimental systems programming language explicitly designed for agents - meaning AI coding agents that generate, repair, and iterate on code. It's from Chris Tate and the team, announced yesterday.

Core Pitch:

Existing languages were built for humans. Zero aims for faster, smaller, and easier for agents to use and repair right from "day zero".

Key agent-friendly features:

• Explicit capabilities/effects: Function signatures declare what they touch (e.g., I/O). No hidden globals, implicit async, or mandatory GC.
• JSON-native diagnostics & typed safe fixes: Compiler outputs structured JSON with stable error codes, repair metadata (e.g., "declare-missing-symbol"), graphs, size reports, etc. Humans read the messages; agents parse and act on the JSON.
• Predictable memory & small native tools: Static dispatch, explicit allocation, no runtime tax. Designed for tiny executables and local reasoning.
• Structured toolchain: Commands like zero graph --json, zero size --json, zero routes --json, zero check --json.

Syntax vibe: Mix of Rust, Zig, and TypeScript.

Example Hello World:

pub fun main(world: World) -> Void raises {
  check world.out.write("hello from zero")
}

Build output: .zero/out/hello (16.2 KiB, 1 ms).

Another snippet from the site:

fun answer() -> i32 {
   40 + 2
}

pub fun main(world: World) -> Void raises {
  if answer() == 42 {
    check world.out.write("math works\n")
  }
}

Status & Tech:

• Very early/experimental (v0.1.1 as of May 16, 2026). Not stable; language and compiler are changing. Good for feedback and trying examples.
• Native compiler (mostly C, with some Zero self-hosting parts).
• Install: curl -fsSL https://zerolang.ai/install.sh | bash
• GitHub: vercel-labs/zero (700 stars in a few hours).
• Docs: zerolang.ai, with learn-zero.md, language reference, examples, etc.
• VS Code extension for syntax highlighting.
• Supports C ABI interop and cross-target checks.

Note on benchmarks/performance claims: The Hello World is tiny and fast to compile, but broader claims (faster/smaller than established langs) are unproven at this stage. Skeptics in the X thread point out limited training data for agents compared to Rust/Python/C++. It's designed around explicitness to reduce hallucinations/fix loops.

Potential Use Cases:

1. AI Agent Tooling: Agents generating small native CLI tools, scripts, or embedded components. JSON diagnostics + typed repairs could enable tighter agent-compiler feedback loops (generate → check → auto-fix → iterate).
2. Tiny Native Utilities: Resource-constrained environments where you want predictable binaries without GC/runtime overhead (e.g., CLI tools, plugins, edge functions).
3. Capability-Safe Systems Code: Explicit effects for better security/auditing in low-level code (similar to capability-based security ideas).
4. Agent-Human Collaboration: Structured outputs make it easier for tools like Claude/Cursor/etc. to propose fixes that compile cleanly.
5. Learning/Prototyping Systems Concepts: Explicit memory & effects could help teach or experiment with systems programming without C/Rust complexity.

It's not positioned to replace Rust/Zig/Go anytime soon - more like an experiment in "agent-native" language design. There's even an AGENTS.md in the repo.

What do you think? Worth the hype for the agent era, or just another wheel?

Links:

• GitHub: https://github.com/vercel-labs/zero
• Site: https://zerolang.ai

Title

After watching a Numberphile video on "awkward primes" I fell down a rabbit hole that turned into a month of obsessive C++ optimisation.

The problem: Plot the first N primes as points on a graph — the 1st prime (2) at position 1, the 2nd prime (3) at position 2, and so on. What is the minimum number of straight lines needed to pass through every point? Proving you've truly found the minimum is the hard part — it's an NP-complete set cover problem, and it gets exponentially harder as N grows.

The previous record stood at N=861, certified by Max Alekseyev (GWU) using an industrial MIP solver in 282 hours.

The solver replaces the MIP approach with an arithmetic-aware incremental architecture:

• 12,162 "heavy lines" (through 3+ primes) stored as 1024-bit bitmasks, keeping the full working set L2-resident
• 60% of steps certified instantly via witness propagation with no search at all
• Lagrangian relaxation with projected subgradient descent for tight lower bounds
• Parallel branch-and-bound with an Exclusive Dependency Rule that provably forces required lines without branching

The results: N=861 reached in 22 minutes. Full sweep to N=1024 completed in under 40 hours, certifying f(1024)=143 and finding 20 new awkward primes.

Full paper, MIT-licensed C++ source, and a live browser demo that runs the actual algorithm in real time are all at the link above. For the OEIS people: https://oeis.org/A373813

I am a hobbyist in prime numbers. I would love to hear from people with expertise in this field if below will hold value for the businesses? I can share more details if anyone has any questions.
\>>
As cryptographic standards demand increasingly large key sizes (e.g., RSA-4096), traditional prime generation architectures have become heavily bottlenecked by main-system memory constraints. Standard libraries dynamically allocate massive heap-memory blocks to perform brute-force modular division, resulting in high latency and power consumption in that makes them unsuitable for constrained IoT devices or high-frequency edge servers.
This paper outlines a novel prime-generation engine—the **Helix Architecture**—that completely bypasses traditional heap-memory division. By utilizing a proprietary Modulo-30 pointer-addition algorithm strictly bounded to a 64KB data track, the engine executes prime sieving entirely within the CPU's ultra-fast Level 1 (L1) Cache.
The result is FIPS 186-4 compliant RSA-4096 key generation in approximately **66 milliseconds** with a **0.0% main-memory cache miss rate**.
A live, interactive demonstration of this engine generating RSA-4096 keys can be tested via our API dashboard at: [https://api.helixapi.io/docs\](https://api.helixapi.io/docs)

I have this theory that Caine is actually a Kernel AI, like the core of an operating system, and that’s why everything is so glitchy. If you look at the FCC labels on the computers (it’s probably on there due to laws) it says the device has to accept every instruction it gets even if it’s unnecessary, which basically means Caine is forced to process everything the humans do without a filter.

The problem is he doesn't seem to have a page file for backup memory, so he's just stuffing all that data into his active buffer. Once he finally gets "completed" and hits his limit, it's going to cause a massive buffer overload. It'll basically be a kernel panic where the whole system just hits a wall and everything gets corrupted. That’s probably why characters abstract and the void exists; it’s just total data corruption because the system is out of memory. Which makes sense because the system kernel deletes some of the processing to free up system memory so they don’t crash. well at least that’s my theory.

1.0 SUBSTRATE

Parameter	Specification
Material	Schott Borofloat 33 borosilicate glass
Dimensions	25.00 mm × 25.00 mm × 6.000 mm ±0.025 mm
Flatness	<2 μm across full surface
Surface finish	<5 nm Ra, both faces
Edge chamfer	0.20 mm × 45°, no chips >50 μm
Quantity	3 identical substrates

2.0 GRID LAYOUT

Parameter	Specification
Grid type	4×4 Cartesian
Pitch	5.000 mm ±0.010 mm center-to-center
Origin (0,0)	Bottom-left corner of substrate
Grid offset X	5.000 mm from left edge
Grid offset Y	5.000 mm from bottom edge
Cavity positions (X,Y) mm	(0,0), (5,0), (10,0), (15,0) / (0,5), (5,5), (10,5), (15,5) / (0,10), (5,10), (10,10), (15,10) / (0,15), (5,15), (10,15), (15,15)

3.0 CAVITY ARCHETYPES

Parameter	TYPE S (△)	TYPE M (◼︎)	TYPE L (▲)
Symbol	△	◼︎	▲
Diameter	3.000 mm ±0.005 mm	2.000 mm ±0.005 mm	1.500 mm ±0.003 mm
Depth	5.000 mm ±0.010 mm	10.000 mm ±0.010 mm	20.000 mm ±0.010 mm
Aspect ratio	1.67:1	5:1	13.33:1
Volume	35.34 mm³	31.42 mm³	35.34 mm³
Time constant (τ)	0.50 s ±0.02 s	1.00 s ±0.03 s	2.30 s ±0.05 s
Wall angle	90° ±0.3°	90° ±0.3°	90° ±0.3°
Wall finish	<0.1 μm Ra	<0.1 μm Ra	<0.1 μm Ra
Bottom finish	<0.2 μm Ra	<0.2 μm Ra	<0.2 μm Ra
Corner radius	<50 μm	<50 μm	<50 μm

4.0 CAVITY ASSIGNMENTS, CORE FFT (SPATIAL FREQUENCY DECOMPOSITION)

X (mm)	Y (mm)	Type	τ (s)
0	15	L	2.30
5	15	M	1.00
10	15	S	0.50
15	15	S	0.50
0	10	M	1.00
5	10	L	2.30
10	10	M	1.00
15	10	S	0.50
0	5	S	0.50
5	5	M	1.00
10	5	L	2.30
15	5	M	1.00
0	0	S	0.50
5	0	S	0.50
10	0	M	1.00
15	0	L	2.30

Kernal type, Symmetric Hankel. Anti-diagonals constant. Sensitive to spatial frequencies. No directional preference..

5.0 CAVITY ASSIGNMENTS, CORE GX (X-AXIS GRADIENT)

X (mm)	Y (mm)	Type	τ (s)
0	15	S	0.50
5	15	S	0.50
10	15	M	1.00
15	15	L	2.30
0	10	S	0.50
5	10	S	0.50
10	10	M	1.00
15	10	L	2.30
0	5	S	0.50
5	5	M	1.00
10	5	L	2.30
15	5	L	2.30
0	0	S	0.50
5	0	M	1.00
10	0	L	2.30
15	0	L	2.30

Gradient principle, Left columns (X=0,5) fast S-dominant, Right columns (X=10,15) slow L-dominant. Center transition M. Left heating → early output peak. Right heating → late output peak. Skewness proportional to ∂T/∂x,

6.0 CAVITY ASSIGNMENTS, CORE GY (Y-AXIS GRADIENT)

X (mm)	Y (mm)	Type	τ (s)
0	15	L	2.30
5	15	L	2.30
10	15	M	1.00
15	15	S	0.50
0	10	L	2.30
5	10	L	2.30
10	10	M	1.00
15	10	S	0.50
0	5	L	2.30
5	5	M	1.00
10	5	S	0.50
15	5	S	0.50
0	0	M	1.00
5	0	M	1.00
10	0	S	0.50
15	0	S	0.50

Gradient principle, Top rows (Y=10,15) slow L-dominant. Bottom rows (Y=0,5) fast S-dominant. Middle transition M. Bottom heating → early output peak. Top heating → late output peak, Skewness proportional to ∂T/∂y..

7.0 UWA-1

Component	Specification
Base	Pharmaceutical-grade paraffin wax, Tm = 60.0°C ±0.1°C
Latent heat	185 J/g ±5 J/g
Dopant 1	Pristine MWCNTs, Ø10-30 nm, L:1-10 μm, unfunctionalized, >95% purity
Loading 1	2.00 wt% ±0.05 wt%
Dopant 2	n-Tetracontane (C₄₀H₈₂), >99% purity, Tm = 81.0°C ±0.5°C
Loading 2	0.50 wt% ±0.02 wt%
Thermal conductivity (solid)	0.45 W/m·K
Thermal conductivity (liquid)	0.38 W/m·K

7.1 Composite Preparation

Step	Action	Parameters
1	Melt paraffin	82°C ±2°C, argon atmosphere
2	Add MWCNTs	High-shear 10,000 RPM, 30 min, 80-85°C
3	Add tetracontane	5,000 RPM, 15 min, 80°C
4	Ultrasonic probe	20 kHz, 100 W, pulse 5s/2s, 60 min, 78-82°C
5	Degas	<1×10⁻² mbar, 80°C, 60 min, until bubble-free
6	Store	Sealed, argon-filled, 6-month shelf life

8.0 INFUSION PROTOCOL

Step	Action	Parameters
1	Clean substrates	IPA ultrasonic, 40°C, 15 min → DI water rinse → N₂ dry → vacuum oven 120°C, 2 hr
2	Preheat	Substrate to 75°C ±1°C on vacuum hotplate
3	Evacuate	<1×10⁻³ mbar, hold 2 hr at 75°C
4	Introduce UWA-1	Via heated manifold, 75°C, sufficient to cover all cavities + 2 mm
5	Backfill	Argon to 2.0 bar absolute
6	Pressure hold	30 min at 2.0 bar, 75°C
7	Directional solidification	Gradient 5°C/mm across substrate thickness. Cool 0.20°C/min ±0.02°C/min from 75°C to 25°C under 0.5 L/min argon flow
8	Inspect	X-ray micro-CT, voxel <5 μm. Zero voids >0.01 mm³ in any cavity. Reject and rework if voids detected.

9.0 THERMAL BUSES

Parameter	Specification
Material	CVD single-crystal diamond
Dimensions	25.00 mm × 25.00 mm × 0.100 mm ±0.005 mm
Thermal conductivity	>1800 W/m·K
Electrical resistivity	>10¹² Ω·cm
Surface finish	<1 nm Ra, both faces
Quantity per core	2 (top incident face, bottom observer face)

9.1 Bonding

Parameter	Specification
Adhesive	BNNT-filled epoxy, 5 wt% loading
Bond line thickness	<5 μm
Thermal resistance	<0.1°C/W
Cure	25°C, 24 hr, vacuum compression 0.5 MPa
Post-cure	60°C, 4 hr, no pressure

10.0 PYROELECTRIC OBSERVER

Parameter	Specification
Material	z-cut LiTaO₃, single crystal
Dimensions	25.00 mm × 25.00 mm × 0.100 mm ±0.005 mm
Pyroelectric coefficient	>2.0 × 10⁻⁴ C/m²·K
Relative permittivity	46 at 1 kHz
Surface finish	<1 nm Ra

10.1 Electrodes

Parameter	Specification
Adhesion layer	Cr, 5 nm ±1 nm
Conductor	Au, 100 nm ±10 nm
Bottom electrode	Full-area ground plane, Z- face
Top electrodes	16 individual, aligned to cavities
Electrode sizes	S: 3.2×3.2 mm, M: 2.2×2.2 mm, L: 1.7×1.7 mm
Alignment tolerance	±10 μm to cavity centerlines
Patterning	Photolithography, lift-off
Edge pads	16 signal + 2 ground, 0.5×0.5 mm, 0.8 mm pitch

10.2 Poling

Step	Parameters
Temperature	85°C ±1°C
Voltage	100 V DC (Z+ positive), field = 1 MV/m
Hold	30 min at 85°C
Cool	1°C/min to 25°C under field
Remove field	At 25°C
Verify	Pyroelectric coefficient >2.0 × 10⁻⁴ C/m²·K

11.0 ENCAPSULATION

Parameter	Specification
Lid	CVD diamond, 25×25×0.100 mm
Seal adhesive	BNNT-filled epoxy, <10 μm bond line
Internal atmosphere	argon, 6N purity, 1.10 bar absolute at 25°C
Getter	Barium flash, 5×5 mm, activated post-seal
Leak rate	<1×10⁻⁸ atm·cc/s helium

12.0 CALIBRATION/ TFP...

Step	Action	Parameters
1	Uniform step	25°C → 30°C in <0.1 s. Record 16 ch at 200 Hz for 10 s. Extract τ per cavity. Verify within ±15% of nominal. Extract sensitivity (mV/°C).
2	Gradient GX	Left 30°C / Right 25°C. Record skewness. Calibration point +0.33°C/mm. Reverse for −0.33°C/mm. Fit linear model: ∂T/∂x = a·skewness + b.
3	Gradient GY	Top 30°C / Bottom 25°C. Record skewness. Calibration point −0.33°C/mm. Reverse for +0.33°C/mm. Fit linear model: ∂T/∂y = a·skewness + b.
4	Frequency sweep FFT	0.1, 0.2, 0.5, 1.0, 2.0, 5.0 Hz sinusoidal modulation. Record 16×16 coupling matrix.

12.1 Personality Map

• Core serial number and calibration date
• τ per cavity (16 values)
• Sensitivity per cavity (16 values)
• GX skewness coefficients (a, b)
• GY skewness coefficients (a, b)
• FFT coupling matrix (16×16)
• Thermal offset calibration

13.0 SYSTEM INTEGRATION

Parameter	Specification
Configuration	3 cores (FFT, GX, GY) on common thermal stage
Stage	Copper, Peltier-controlled, 25.0°C ±0.01°C
Spacing	10 mm between cores
Optics (optional)	Ge lens, f/2, 50 mm FL, AR 8-14 μm, FOV 30°×30°
Flex circuit	Polyimide, 18 μm Cu traces, 20-pin ZIF, 100 mm length, shielded
Readout	16-ch charge amplifier, 0.1-100 Hz BW, 200 Hz sample rate, 16-bit ADC

13.1 Output Vector

Quantity	Source	Units
Spatial frequency spectrum	FFT Core (16 components)	Normalized amplitude
∂T/∂x	GX Core	°C/mm
∂T/∂y	GY Core	°C/mm
	∇T
θ (gradient direction)	atan2(GY,GX)	radians

I'd like to create a portable sensor suite with a very lightweight minimal GUI, likely a selection of real-time graphs of various types, as well as file creation, editing, and saving. As far as the sensors, I still haven't decided on what all I plan to add, but I'd like to have a pretty decent range, from the basics like gyroscope, accelerometer, thermometer, barometer, etc. to potentially more complex like an IR camera (complicates the simple GUI a bit,) visual range spectrometer (and beyond?) and a range of RF receivers. The only hardware I have at the moment is a Raspberry Pi 4, but I'm aware it's a more general purpose board, and there could potentially be hardware better suited to a sensor suite. I'm also not sure if an RTOS would work better or if I should stick with a simple GPOS. The simple GUI is something I'd like to make myself, if reasonably possible. If anyone's done or seen another project similar, I'd be interested to see it as well.

This one took a while, it's probably the longest thing I've written on this blog. I wanted to do a proper end-to-end walkthrough of cmd/compile: real package names, real data structures, diagrams for the AST and SSA CFG, and the flags you actually need (-m, -m=2, GOSSAFUNC, -S) to observe each phase yourself rather than just take my word for it.

Covers the full pipeline: lexer → parser → type checker → IR lowering → SSA construction → optimization passes (inlining, escape analysis, BCE, nil check elimination, register allocation) → architecture-specific code emission.

Hope it's useful — happy to answer questions or push back on anything that looks wrong.