Hacker News new | past | comments | ask | show | jobs | submit
jcmoyer | on: The Goose Programming Language
The very first point under your tutorial is factually incorrect.

    var words: u8[][>..] = [];
    for i in 5 { words.push(str("word", i)); }
    
    In C++ that is a vector<string>: one heap allocation for the vector,
    one per string, a pointer and a capacity per element, and a walk over
    all of them when it goes out of scope.
The example you've provided uses strings that are eligible for small string optimization, which avoids per-string allocation. All mainstream STL implementations perform this optimization. You can read about several implementations here: https://devblogs.microsoft.com/oldnewthing/20230803-00/?p=10...
felixguendling | parent | next
in C++ this could be done with `cista::raw::vecvec<char>` where only string start positions are stored (end is not necessary because end = start of the next -> 4 byte per string) https://github.com/felixguendling/cista/blob/master/include/...
vanderZwan | parent | next
That removes the allocation but keeps the overhead of a pointer, a capacity and a fixed buffer.

And these strings in Goose are 6 bytes, while the ones in C++ are apparently 16 to 24 bytes each.

tialaramex | root | parent | next
But equally they could be a Rust cold_string::ColdString which is either 8 bytes or 4 bytes depending on your target. The 4 byte ColdString is just the bytes 0x77 0x6f 0x72 0x64 to spell "word" in ASCII / UTF-8 [for 8 bytes the current ColdString just stores 0xFF in the other four bytes to denote they are not used]

Rust has had more interesting SSO types than C++ perhaps explicitly because it doesn't come with SSO out of the box although maybe also because C++ still isn't sure whether text is UTF-8 encoded even though it is 2026 now.

mgaunard | parent | next
You can also just copy your strings into the same buffer in C++ if you want to.

The obvious downside is that resizing any string but the last requires moving everything down the stack.

With objects that never need resizing, you can of course have much simpler memory layouts.

ModernMech | parent
This is the danger of using AI to write your docs and why everyone is asking the author to update them.
Someone | root | parent
I think a human writer could easily have made that error, too.
phoghed | root | parent | next
I don’t think there’s ever been a single statement made about C++ code that didn’t have at least one person come by to explain why it’s incomplete or wrong, and then the same thing happening to that reply itself
loading story #50239894
tialaramex | root | parent
That's just Muphry's law (if you write a correction, it will have mistakes in it)
loading story #50232123
loading story #50232491
ModernMech | root | parent
The problem isn't that a mistake was made, the problem is the nature of the mistake. We can forgive a human author of Goose making a mistake about C++ in the docs.

But what mistakes did the AI make about Goose? If it can say something wrong about a language it has much training data on, what's it saying wrong about a language with no training data at all? How can we trust anything it says about Goose?

Moreover, AI could have caught this mistake so even in using AI, it's clear AI wasn't used proficiently; it should have at least been tasked to proofread stuff like this.

loading story #50234400