On Sun, Jul 14, 2013 at 12:20 AM, David Jeske <[email protected]> wrote:
> I can see why Bennie thinks an experimental rust fork might be a good > starting point. It seems to be spiritually solving many of the same > problems bitc set out to solve.. though their constructs and ahead-of-time > compilation seem to be leading down a C++/ML like > whole-program-compilation-forever path. I seem to remember some of the bitc > end-of-life involving the mutual exclusivity of modular subtyping plus > parametric-instantiation and ahead-of-time compilation. > OK. I've dug into Rust as far as I have time to do. I'm happy to look at specific things people may want to point me at, but given that they don't have a proper language specification (stale or otherwise), I'm not sure how to get a usefully detailed handle on it. >From what I *can* see, the only substantive difference between Rust and BitC is the introduction of a 'self' type on trait implementations. From a safety perspective, this isn't a trivial thing to introduce, and the complete absence of any formal articulation of the type system is cause for suspicion. It's fairly conspicuous that Traits are not considered in the discussion of the type system, and that questions of type inference (if any) don't seem to be discussed. Traits, for example, seem to be the method of operator overloading, but no discussion of resolution exists. I'm aware of their macro system, and I'm not disrespecting it by omission. It's just that macros aren't part of the core language (by definition). Then there is the concurrency model. Which seems fine, but as I've said before, the problem with taking a position on concurrency models is that we don't know a model that's good in all cases. Taken overall, my main problem with rust is that the specification doesn't tell me enough to understand what it does, but it *does* tell me enough to see that there are important questions that need answers. I can see why people see a resemblance. From my perspective, I'm a bit disappointed that Rust has proceeded into many of the traps that BitC did. The more so because I called some of them to Brendan's attention and offered to join forces at one point. It's not too late. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
