6 ms·
I agree that automatic, deterministic resource management (as opposed to GC plus a dispose pattern of some kind) is highly desirable. But I think for the vast m
by mwcampbell 12y ago
I agree that automatic, deterministic resource management (as opposed to GC plus a dispose pattern of some kind) is highly desirable. But I think for the vast majority of projects, I would prefer automatic reference counting with the occasional weak reference to break cycles, particularly if that were the default for the language. I can appreciate that being explicit about resource ownership is an advantage in situations where one needs to absolutely minimize performance overhead. But for most applications, I think a system of ownership and borrowing like Rust's would just add extra cognitive load for the programmer for no appreciable gain. Of course, Rust isn't a language for most applications AFAIK; it's a systems language for performance-critical infrastructure like Servo. And Rust is probably not a language for blub programmers. But I think this blog post is absolutely right about the problems with GC plus a system for disposing of resources. It sucks that mainstream, blub-friendly language have mostly chosen GC over reference counting; I think automatic reference counting provides the right set of trade-offs for most applications.
- steveklabnik 12y agoYou can do that if you want, just use the Rc<T>/Arc<T>/Weak<T> types. That said, you're right: if you don't need Rust's strengths, the tradeoff may not be worth it.
- mwcampbell 12y agoI know Rust has RC pointers. But I'm guessing a Rust programmer would still have to understand ownership and borrowing, since the standard library and third-party libraries use those concepts. I think what I'd really like is something like C# and the .NET base class library, but AOT compiled to native code and using automatic reference counting, with some way to indicate weak references. I know that neither GC nor reference counting quite reaches the level of "don't make me think" when it comes to resource management, but given a choice between explicit resource disposal and the occasional weak reference annotation, I think I'd choose the latter. Anyway, enough ranting from me for now.
- steveklabnik 12y agoThat's true, you can't totally avoid knowing about these things. But if you don't want to think about them in your code, and are okay with the price, you can. It sounds like Swift may be close to what you want, yeah?
- doublextremevil 12y agoUnfortunately Swift is not open source or cross platform
- steveklabnik 12y agoRight, I meant solely on paradigm.
- mseri 12y agoOk, let's assume that they open it. First there will be need of a standard library. For the moment to do anything sensible you are importing Apple's Foundation Library (probably in one year time it will be better). Then I see no problem to have it server-side (both as a scripting or compiled language).
- bsaul 12y agoIt looks to me that swift is the only language that can compete with rust if it were open sourced, or at least available for general purpose usage. Anyone familiar to swift internals here to say whether server-side swift is at least theorically feasible ?
- pjmlp 12y ago> C# and the .NET base class library, but AOT compiled to native code Mono -aot and .NET Native. Just not with RC, though. Or D, if you with to have both GC and RC.
- samth 12y agoI think the language you want is Ocaml.
- kibwen 12y agoI agree that Rust isn't the be-all, end-all language. But I think this line is mistaken: > I think a system of ownership and borrowing like Rust's > would just add extra cognitive load for the programmer > for no appreciable gain. In my experience, the fact that the compiler can check this stuff ends up subtracting cognitive load. Of any language I've used, Rust code is the code that I worry least about. Is there syntactic overhead? Yep. Does it impose constraints on design? Yep. But when it comes to resource management, everything that Rust does is just something that you'd need to use a pen and paper to keep track of in other languages (including pervasively reference-counted languages, since AFAIK there's no way to automatically enforce the proper use of weak pointers).
- Dewie 12y ago> In my experience, the fact that the compiler can check this stuff ends up subtracting cognitive load. Of any language I've used, Rust code is the code that I worry least about. That's interesting. So this holds for languages and applications where you could get away with not knowing the automatic memory management implementation and adjusting your design based on that? For example, that you don't have to worry yourself with making sure to not allocate too many values on the heap, at least in most of the code? Would you prefer using Rust for problems and domains where you strictly don't need the efficiency and determinism (like memory usage) you get from using Rust?
- kibwen 12y ago> Would you prefer using Rust for problems and domains > where you strictly don't need the efficiency and > determinism (like memory usage) you get from using Rust? It would highly depend on circumstance. How often is my code going to be run? How long will it be maintained for, and how often will it be updated, and by whom? I think we all have a hierarchy of sorts: bash or Perl for one-off, disposable scripting tasks; Python or some other light dynamic language for when things start getting more serious, but are still personal projects; C# or some other relatively heavyweight hammer for when we're writing code that will live beyond our control, maintained by others and run for years and years. I don't write production code in Rust yet (heavens no, not until 1.0 at least... godspeed to wycats :P ) but right now it's in that third category of languages where I trust that it can be maintained by a team and trusted to exist for years. However, I would consider Rust for that second category of somewhat-serious personal projects, because I know too well how such "personal projects" can vault unexpectedly into that third category of "mission-critical team projects". But before that, I'd need to wait for the library ecosystem to mature. EDIT: I should clarify too that resource management is only part of the reason why I don't worry about Rust code. There's also stuff like the ability to know that a given global variable is immutable, and can't be changed out from under me. Or knowing that an innocent-looking block of code can't unexpectedly kill the process (divide-by-zero notwithstanding).