The only language I know of that ultimately meets that goal is assembly language, and we really don't want to relegate ourselves to that. I would say rather that we want the need to drop to assembly language to be drastically minimized.
For example, I really don't see a need for the programming language to have the "invalidate TLB" instruction as a primitive. That's the kind of thing for which inline or out-of-line assembly really is appropriate. C intrinsic functions can do it without dropping out of the language though the functions themselves are like asm but this only needs to be a single lib which has these types of functions. My definition of a *good* programming language is task-dependent, and is one which: a. ... allows us to express a specific program we wish to express b. ... enabling a chosen tradeoff between flexibility and safety c. ... enabling a chosen tradeoff between coding-efficiency and readability d. ... and which achieves our goals WRT SLA/latency and third-party interfacing For me, it is (3/d) which have thus-far made garbage collection unsuitable for systems programming. Typical garbage-collection compromises are fantastic for *certain* applications, but I do not consider them systems programming languages, because when (3/d) rears it's ugly-head our only choice is to jettison the entire runtime and switch to something which meets my definition of a systems programming language. I've been really excited since Azul C4 appeared to see a GUI system turn this all on it's head. Sadly AFAIK it's not possible to implement C4-techniques on windows, Android, or iOS... and the C4/JVM is unsuitable for systems programming for other reasons. I think C4 could be done on Android, which is basically built on a Linux kernel. It could be done on Windows if MSFT was sufficiently motivated. I agree that JVM is unsuited for systems programming, but I'm not sure C4 is unsuited for that. Re does the ARM MMU support all the things needed ? Not sure. Agree on windows. The other huge issue with GCs which relates to C4 is unless you run on a GC based OS (Which won't happen soon ) everything has to be pinned and or copied to and from GC managed space. That can be a major drag on IO which has led to quite a few APIs using C++ eg for reading tcp/ip packets and then passing an unmanaged pointer to the payload data for the app to read ( and note this has the additional advantage of those short packets not clogging up the GC) . This may not be visible to the user as its all nicely hidden under a stream but underneath there is still the need for an unsafe compile . I can't remember for certain but I think WCF and/ or the MSMQ API did something like that. Ben
<<attachment: winmail.dat>>
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
