George

Github if IBM designed it in the 60s

I would guess that most junior developers don't know the difference between processor registers, static ram and DRAM, and don't know anything about CPU cache hierarchies. They are used to having huge amounts of compute power to hide their incompetence and lack of education.

20 GB of garbage from constant crashing in the span of hours... but it's got agents tho! Guess this is side project no. 53

> clangd constantly crashing > no feedback in zed whether it's actually working or not, endless spinning wheel > makes vscode blush > filling up /tmp with gigabytes in the span of an afternoon > bug open since 2019 Atrocious env for non-trivial projects

Just avin a giggle at this point

me trying for kid no. 3:

Hidden heap allocations are Language-dependent and often flat-out false though, string literals live in the binary's read-only data section, not the heap. C++ has SSO (short string optimization) keeping strings under ~15–23 chars inline on the stack. AND Rust &str is a pointer+length with zero allocation. Go strings are (ptr, len) headers and can be stack-allocated via escape analysis, plus it's not really "hidden", any profiler or allocation tracker surfaces string allocs immediately. as for Copy-on-write behavior, a relic of the past, C++11 explicitly banned CoW for std::string because of threading issues. Rust doesn't use CoW by default. Go strings are immutable and shared via pointer+length. and as far as i remember, Swift uses CoW and it's considered a feature, not a cost. the entire point of CoW is that you "don't copy until you mutate". your point of "CoW makes CPU work 2x" is the opposite of what CoW does.... O(n²) concatenation is a Programmer error, not a string problem, i can't see how it is. s = s + x in a loop is quadratic in every language i can think of, which is why every language ships StringBuilder / strings.Builder / String::push_str / bytes.Buffer. Cache-unfriendly memory access seems backwards to me, a string is a contiguous byte array; it's pretty much verified cache-friendly access: sequential, prefetchable, SIMD-able. What's truly cache-unfriendly is shit like linked lists of chars or ropes. std::string, Go string, Rust String, and Java String (with compact strings) are all contiguous. Encoding overhead (UTF-8/16): well, If you need to represent text, you need an encoding, using bytes doesn't exactly fix that, you will just be re-inventing the wheel (reimplement indexing and validation). UTF-8 ASCII is 1 byte/char, identical to ASCII, The only "overhead" i can see appears for non-ASCII, and refusing to handle non-ASCII isn't a performance, it's just wrong. O(n) compare & hash is Information-theoretic lower bound at best not an implementation flaw, You cannot, in general, determine equality of n bytes in fewer than O(n) operations... Can't hash n bytes in less than O(n). "Primitive byte arrays" have the identical bound, they're the same bytes. Real string implementations also layer optimizations on top: length check first ((O(1) rejection), SIMD comparison, etc...) GC/allocator churn is again, a mem-man issue, not a string one, if you have an actual bottleneck, the fix is interning, arena/pool allocators, or buffer reuse, not "stop using strings", that is silly, and Several of those techniques are already built into string runtimes: Java's string pool, Go's constant folding, Python's short-string interning, etc... and FINALLY, "use primitive buffers, bytes & arrays." Go's string is literally struct { ptr *byte; len int }. Rust's String is Vec plus a UTF-8 invariant. Java 9+ stores strings as byte[]. You're already using byte arrays... Now i dunno what lang you targeted this at, but it seems misinformation at best. did i just get rage-baited?