[bitc-dev] Retrospective Thoughts on BitC
Jonathan S. Shapiro
shap at eros-os.org
Mon Apr 16 10:52:50 PDT 2012
On Mon, Apr 16, 2012 at 4:33 AM, David Jeske <davidj at gmail.com> wrote:
> Of course we can't speak for Shap...
Why not? You are entirely welcome to take my name in vain, just so long as
you shall have no other gods before me. :-)
Okay. I admit it. I'm punchy this morning. No idea why.
> On Sun, Apr 15, 2012 at 10:56 PM, Matt Oliveri <atmacen at gmail.com> wrote:
>> If you want a typesafe runtime to replace C, then you are essentially
>> saying we should write all programs on top of some fixed runtime.
> Yes. That runtime would evolve over time, but yes.
I more or less agree. One thing I would like to see is a successor to CIL
that provides for regions and parametric types, and maybe for "shape types"
(which I need to explain).
> In other words, as I see it, you are asking for compromise.
>> But you have argued yourself that essentially people turn to C (live
>> dangerously) when they find the compromise option to be unacceptable,
>> currently because of GC pauses.
> I object to this. I do not believe people turn to C to avoid compromise.
> If so they would always turn to assembler. I believe they turn to C because
> it offers an improvement in programmer productivity in exchange for a
> linear-performance degregation.
But you yourself note that C is essentially asm with human syntax.
I think there are a bunch of reasons people turn to C:
- Maybe I'm writing something that is dependent on an existing library
in C (e.g. OpenSSL)
- Maybe I need decent I/O performance, and safety is pushing me into
data copies that I can't afford to do. Biagioni's work on TCP in ML is
instructive here. Foxnet is painted as a success, but actually it's pretty
- Maybe my app warm-up time matters (so JIT gets in the way). This was
the main issue for in-transaction database servlets
- Maybe pause times worry me
- Maybe the problem of debugging inadvertently retained storage was too
- Maybe I just don't know any better
- Maybe I care about performance, therefore about memory placement, and
therefore need a rich system for unboxed types
- Maybe Brian, Dennis, and Bjarne are/were my colleagues (okay, that one
applies to fewer and fewer of us, but still)
- Maybe I'm a tea drinker
- Maybe the *physical* heap footprint of my app matters. Either I can't
afford 10x the memory initially, or I'm operating at a scale where I can't
afford to *cool* 10x the memory. That's why Google can't use some of
- Maybe I care about security and modularity, and I've worked out that
taming the Java standard library is utterly hopeless.
All I'm saying here is that GC is just one of *several* issues that are
getting in the way of safety adoption
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev