Conversation

I feel like we don't talk enough about about the knock-on costs of manual memory management. Garbage collection may not be a perfect way of managing memory, but it at least is *a* standardized way of managing memory which is consistent all the way through the language stack.
4
67
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
Show replies
I can answer this the short way and the long way. Short: yes, Rust had a condition system (at one point language-supported, at a later point library-only) and we took it out due to underuse. Longer: I'm a fair bit more skeptical of conditions now than I was a decade ago ...
1
4
Aside from subsuming panic-like unwinding, they provide fluid-bound ignore-error / substitute-value strategies, which are both good sometimes, but also easy to mimic through dedicated error-handling arguments to possibly-signalling functions.
1
1
Show replies