Interesting that you disqualify Objective C? It use reference counting which should have a more predictable memory handling behaviour.
Or is the dynamic stuff too much overhead for you? To me, it looks cheap (but I'm a scripter since quite a few years).
(Not knowledgeable on this; I'm asking, not making an argument.)
http://www.mikeash.com/pyblog/performance-comparisons-of-com...
Read 16-byte file 100000 iterations 2.1s for 100k reads 21219.3ns per read
This appears to be testing... the filesystem cache? It's certainly not seeking on a rotational disk, "SSD" isn't on the page, so... not sure where he's getting 21 microsecond reads from.
Correct reference counting in multi-threaded code running on a multi-core machine adds significant cost to a simple pointer copy (aka "add reference").
Let me try to summarize:
There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave.
Period. No ifs-ands-or-buts about it.
This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays vs. linked-lists are the trivial but canonical example)
The moment the programming language, at any fundamental level, precludes me from defining how the machine should behave with respect to memory, semantics, or otherwise...it ceases to be a language that can be used for systems programming.
Disintermediating the meddling of C compilers is hard enough, languages like Go and Java are 'intractable' to say the least for actual systems programming.
Obj-C is only acceptable in the context of systems programming when you stop using everything that makes it Obj-C and just write C code.
I outlined additions/improvements that could be made to C and utilized in the context of systems (rather than applications) programming.
In a single sentence, it's about fundamentally about POWER and not "speed". That's why the desert-island language is C.
Actually it seems you don't understand that people mean different thing by "system's programming".
Not all system programming is about no-compromise, i.e as it would if it was only about driver or OS coding.
I'd trust Ken Thompson and Rob Pike to understand what system programming is better than some random dude on HN.
You'd be surprised, Pike has more or less retracted the "systems" moniker due to the reaction it got. He avoids the term now as a result.
I know this because I've been watching Go itself very closely.
But hey, it's just Rob Pike. Maybe ken still calls it a "systems" language. I'm still just a random dude on HN who thought plan9 was a fantastic idea and keeps track of Pike's work as a result :)
As for your 'what people mean by systems programming', how about you both stick to the definition/description used here:
http://en.wikipedia.org/wiki/System_programming
That would make it much easier to communicate. From the looks of it systems programming is all about no compromise, specifically for the reasons outlined by the GP. Now I wouldn't know him from Adam but even outside the realm of driver and OS programming there is plenty of room for software that is 100% deterministic in terms of time and space consumed.
Note that the 'alternate usage' term in the page linked above was specifically not what the GP was talking about if I understood it correctly.
Most code isn't inner loops in device drivers.
My point was that Obj C's behavior should be more or less deterministic, and method calling reasonably fast?
So "more or less" is just not good enough for you. [Edit: E.g. cache interaction is too hard to reason about when doing lookup for method dispatch, etc?]
Well, I'm too laid back to work on your problems. :-) I decided a long time ago that what I really liked most was to create lots of functionality in as short time as possible. But I admire people that care about things and learn about them relentlessly, so thanks for the information.
That's what I do now, but it's not what I've always done and I'm keenly aware of the limitations my peers are dealing with on a daily basis.
I hear what you're saying but you're overselling C here. Straight up ANSI C has a lot of limitations in telling the machine what to do. Even the various proprietary extensions have limitations right up until you stop writing anything that looks a little bit like C, e.g. you start using "asm" style intrinsics that let you do assembly inline.