4 ms·

> Even if your claim is correct, the existence of some programs that cannot be expressed with memory-safe zero overhead abstractions still doesn't entail your o

> Even if your claim is correct, the existence of some programs that cannot be expressed with memory-safe zero overhead abstractions still doesn't entail your original claim. As you just said, you can use Rust's unsafe escape hatch to preserve your desired performance where it's critical and you haven't lost anything from C/C++, but you can still enjoy the safety benefits where unsafety is not needed. I'm not comparing to C/C++. I'm comparing to other memory-safe languages. The more general problem is that Rust cannot offer zero-cost abstractions for shared ownership as a result of how it is designed. This is the really killer issue. It's a problem for pretty much any persistent data structure, for example. > And BDDs expose a safe API behind which you can hide the unsafety, so only a fragment of your system would dependent on unsafe Rust. The unsafe approach would be to do use an array representation, use indices instead of pointers, and roll your own garbage collector. Or manually remove unnecessary reference count updates whenever you can prove that they are unnecessary. Both of which cannot be easily hidden behind a safe zero-cost API. > Pretty much only Ada and C++ can provide the zero cost abstractions, and they do so only with heavy syntactic and semantic costs (templates for C++, packages and wordy instantiation for Ada). The Rust language does this as part of polymorphica elaboration, which is a natural and compositional language feature, not some ad-hoc secondary language or restricted module system. The entire Wirth family of languages qualifies, too. Or Eiffel. Or Fortran. Or Modula-3. As do more recent languages such as Nim and D. Honestly, off the top of my head I can't think of an imperative language with native compilation that doesn't and isn't totally obscure, other than Swift and Go (and even they only some of the time). Note that zero-cost abstractions need to only exist, not that they have to be the only option. Languages can and do provide both expressive constructs that come with overhead and less expressive constructs that are overhead-free. 90:10 rule, premature optimization, and all that. In addition, parametric polymorphism cannot ever have a zero-cost abstraction (or rather, the term has no meaningful definition in this context), because you pay for it either in runtime overhead (shared generics) or code size (specialization). I also wouldn't bring up syntactic and semantic costs; that's throwing stones while sitting inside a glass house. Rust is probably one of the worst offenders in this regard.

naasking 9y ago
> The unsafe approach would be to do use an array representation, use indices instead of pointers, and roll your own garbage collector. Or manually remove unnecessary reference count updates whenever you can prove that they are unnecessary. Both of which cannot be easily hidden behind a safe zero-cost API. There are potentially many unsafe approaches, and possibly even some safe ones. > The entire Wirth family of languages qualifies, too. Or Eiffel [1]. Or Fortran [2]. Or Modula-3 [3]. As do more recent languages such as Nim [4] and D [5]. [1] Doesn't support expressing stack allocation patterns, which are essentially to achieving true zero-cost abstractions. [2] Oh yeah, that'll be easy and maintainable to program. [3] Doesn't support 64-bit Windows. Verbose like Ada. Abstraction is weak compared to Rust. Also doesn't support expressing stack allocation. [4] Nim requires a GC, so not zero cost. It also has surprising runtime semantics. For instance, fields that are are guarded by a clause raise runtime exceptions. These would require different cases which are checked for exhaustiveness statically in Rust. [5] D is not memory safe for non-trivial programs if you're not using the GC. Clearly you and I have a different understanding of zero-cost abstraction. > In addition, parametric polymorphism cannot ever have a zero-cost abstraction (or rather, the term has no meaningful definition in this context), because you pay for it either in runtime overhead (shared generics) or code size (specialization). Code size is not a problem when discussing zero-cost abstractions. Honestly, it just seems like you're grasping for something to nitpick on. > I also wouldn't bring up syntactic and semantic costs; that's throwing stones while sitting inside a glass house. Rust is probably one of the worst offenders in this regard. I have no idea what you're talking about. Once they removed all the special syntax for pointer types years back, Rust is very readable to anyone from a brace-based language tradition.
- pjmlp 9y ago
  > Doesn't support expressing stack allocation patterns, which are essentially to achieving true zero-cost abstractions. Says someone that never wrote a single line of Eiffel. That is what local variables defined as expanded classes are for. local array: expanded ARRAY[INTEGER]; do array := <<1,3,2>> sorter.sort(array) .... end > Doesn't support 64-bit Windows. Verbose like Ada. Abstraction is weak compared to Rust. Also doesn't support expressing stack allocation. Says someone that never wrote a single line of Modula-3. TYPE Time = RECORD seconds: INTEGER; milliseconds: [0..999] END; PROCEDURE MyProc = VAR t: Time; (* Stack Allocated *) BEGIN t.seconds := 0; t.milliseconds := 0 END MyProc; Being verbose is a virtue in large scale software development.

naasking 9y ago

> The unsafe approach would be to do use an array representation, use indices instead of pointers, and roll your own garbage collector. Or manually remove unnecessary reference count updates whenever you can prove that they are unnecessary. Both of which cannot be easily hidden behind a safe zero-cost API. There are potentially many unsafe approaches, and possibly even some safe ones. > The entire Wirth family of languages qualifies, too. Or Eiffel [1]. Or Fortran [2]. Or Modula-3 [3]. As do more recent languages such as Nim [4] and D [5]. [1] Doesn't support expressing stack allocation patterns, which are essentially to achieving true zero-cost abstractions. [2] Oh yeah, that'll be easy and maintainable to program. [3] Doesn't support 64-bit Windows. Verbose like Ada. Abstraction is weak compared to Rust. Also doesn't support expressing stack allocation. [4] Nim requires a GC, so not zero cost. It also has surprising runtime semantics. For instance, fields that are are guarded by a clause raise runtime exceptions. These would require different cases which are checked for exhaustiveness statically in Rust. [5] D is not memory safe for non-trivial programs if you're not using the GC. Clearly you and I have a different understanding of zero-cost abstraction. > In addition, parametric polymorphism cannot ever have a zero-cost abstraction (or rather, the term has no meaningful definition in this context), because you pay for it either in runtime overhead (shared generics) or code size (specialization). Code size is not a problem when discussing zero-cost abstractions. Honestly, it just seems like you're grasping for something to nitpick on. > I also wouldn't bring up syntactic and semantic costs; that's throwing stones while sitting inside a glass house. Rust is probably one of the worst offenders in this regard. I have no idea what you're talking about. Once they removed all the special syntax for pointer types years back, Rust is very readable to anyone from a brace-based language tradition.

pjmlp 9y ago
> Doesn't support expressing stack allocation patterns, which are essentially to achieving true zero-cost abstractions. Says someone that never wrote a single line of Eiffel. That is what local variables defined as expanded classes are for. local array: expanded ARRAY[INTEGER]; do array := <<1,3,2>> sorter.sort(array) .... end > Doesn't support 64-bit Windows. Verbose like Ada. Abstraction is weak compared to Rust. Also doesn't support expressing stack allocation. Says someone that never wrote a single line of Modula-3. TYPE Time = RECORD seconds: INTEGER; milliseconds: [0..999] END; PROCEDURE MyProc = VAR t: Time; (* Stack Allocated *) BEGIN t.seconds := 0; t.milliseconds := 0 END MyProc; Being verbose is a virtue in large scale software development.