Conversation

a friend (, i think?) once told me that the absence of manual memory management is basically a prerequisite for composeable code precisely because it requires everyone to agree on memory. this is why package management in C/C++ will always be a nightmare.
2
15
Yeah. It's valuable not just for memory management, but because it's a mechanism that everybody agrees is allowed to have visibility across abstraction boundaries. Otherwise, every module needs to coordinate resource hand-off, complicating interfaces.
1
5
What benefits could come from agreeing on other cross-cutting mechanisms (that aren't necessarily about memory)? Erlang gets tremendous value out of agreeing on a concurrency & error-handling approach, for example.
1
4
thats the conceit of a VM like the CLR. you have an agreed upon GC, type system, error handling, (large) standard library, C-interop, etc. it's great! but its a VM. Rust is the only VM-less platform of standardized cross-cutting mechanisms i can think of.
1
3
Yeah, this is what's finally bringing me over to Rust. I don't want to write code by Rust's constraints, but maybe I can think of it like Rust's memory constraints being "these are the module boundary constraints" and use cheatz to violate the constraints in-module.
1
9
Incidentally, I am still waiting for a language that has a way of agreeing how exceptional conditions are handled across module boundaries. I don't believe exception handling is good enough
2
3
What I want is a standard idiom where actual errors like "invalid parameters" and exceptional-but-expected conditions like "file not found" are handled within the same mechanism, yet the mechanism understands one is lighter-weight and must be easier to do casually than the other.
1
3
Perhaps if the only way of handling errors was conditions then folks would have learned it properly and liked them, but at the time they were always this 'annoying backwater that you had to deal with when doing IO'.
1
Show replies