Understatement. Shocking. It does get tripped up with more recent changes...e.g. using the pre 0.15 non-intrusive linked list implementation, but it's minor, and a short "that's the old linked list api" message away from a fix.

There are PRs that touch on it, but seems like improvements will come from docs and attempts to fail early (not like my example, where some input is allowed to works).

I guess it's like bound checking - runtime checks in debug, else undefined. But, as we would have said in the 90s: to the extreme.

Behaves like any assignment in zig. If the value has a ptr, you'd get a copy of the ptr, so it could still be useful. Easy to say: for all but basic types, use getPtr. But it really depends. Can't program effectively in Zig without knowing whether get or getPtr is right for a given case.

I think Go, with its many many flaws, is the best 2nd choice.

I'd only consider Zig (a) for fun (b) couldn't afford the GC (c) needed c-interop (d) had a team of superstars. There are probably better choices, just none that I'd pick.

It would depend on a lot of factors. For myself? A large company? I think Elixir is #1. If you can model your problem within the constraints of the actor model, do it. Nothing helps more with managing complexity. Period.

But, if you can't afford those constraint (e.g. non-shared memory)...

My stream version _does_ not work reliably. The best option I've found is to use readVec:

var buf: [1024]u8 = undefined;
var iovec: [1][]u8 = [_][]u8{&buf};

while (true) {
const n = try tls_client.reader.readVec(&iovec);
std.debug.print("{d} - {s}\n", .{n, buf[0..n]});
}
}

Yes, it's possible a combination of `fill()` + `buffered()` would work, but that requires the reader to have a buffer? For socket programming, I suspect most people won't use the built-in buffering, and will instead use context-aware buffering in their app.

doc.rust-lang.org/std/io/trait...

pkg.go.dev/io#Reader

man7.org/linux/man-pa...

docs.oracle.com/javase/8/doc...

Nope. `readSliceAll` errors if the buffer can't be filled

That's not how stream programming works.

I was pointed to std.fmt.printInt, which wraps an Io.Writer's println. I don't understand why things couldn't be deprecated with a grace period. And, there _are_ some that seem to have no straightforward replacement.

std.fmt.formatIntBuf is gone. From what I can tell, now I need to create a Writer (via Writer.fixed) and use the printInt method.

Not clear why fmt.formatIntBuf couldn't stick around and do that for me. If nothing else, at least deprecated and removed later.

This repeated for many functions.

Rather than baking-in buffering, the issue of composition should be addressed. Seems like an language limitation at this point since, from the way buffering was implemented, it doesn't seem like there's a better option.