An other option you might want to look into is Rust[0], especially since the language is still in its early days (0.1) and the developers are more than willing to fix things which don't work.
* It does not have bit fields or bounds-checked arrays (which it calls vectors) at this point I think
* A bit of GC: it has a reference-counted pointer type, which is task-local, which might be possible not to use at all (not sure) if you don't want it. It also has unique pointers (reclaimed when they vanish out of use) and stack allocation.
* HoF, unicode-native strings (although they're char vectors so maybe not ideal), pointers cleanups (and more than one pointer type which you may or may not agree with), "tasks" ("green processes"), absolutely trivial C interop (so you should be able to easily use pthreads I think), structurally typed records, tuple types, lots of pattern-matching love (for dispatching and unpacking), explicit mutability marker
(1) Regions, when you want safe, low-overhead allocation. The downside is a more complex type system. (Usually you don't see the complexity unless you're returning pointers that contain references to the stack, at which point you have to convince the typechecker that you aren't creating dangling pointers by doing so.)
(2) Safe, garbage collected heap allocation. This gives you maximum flexibility at the cost of runtime overhead.
(3) Unsafe pointers. This lets you manage your memory manually, like C++. Of course, this is unsafe.
Also, I suspect we're going to add fixed-length vectors; we've been discussing this quite a bit lately and I think there's general consensus that they should be present in the language in some form.
Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java.
I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for making it an excellent language for a database.
The non-optional runtime overhead that I have to imagine is endemic to the purported feature-set would seem to be a non-starter for systems (kernel, driver, embedded) programming.
Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.
I'd like to see a "runtime-less Rust" myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.
If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help.
Yeah that's about what I'd expect considering the language's goals.
> Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.
Rust has the `unsafe` escape hatch for this, unsafe blocks can do whatever the hell they want and are "unsafe function" and "unsafe pointer" types which are known to bypass Rust's safety mechanism and can only be used in unsafe blocks.
In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete.
If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established priorities of safety and concurrency.
I'm not saying Rust will "fail" like Go seems to be doing so far, I'm just saying I don't think they're going to prioritize making Rust useful for driver development[1].
[1] Which I think is brilliant anyway. It's solving a very hard problem that needs solved.
It's interesting to see that the domain of "systems" programming languages appears to be splitting into "kernel-level" domains and "perfomance-critical application-level" domains. In this light, it seems more like C++ is the one caught straddling the gap. Should be interesting to watch this space for the next decade or so.
I think it's way too early to tell if Go is failing or not; it was announced less than three years ago. How successful was, e.g. , Ruby in '98?
Clay seems to understand that you cannot compromise.
Perhaps I'm cynical, but having had no experience with Clay this statement fills me with dread. Care to elaborate?
Edit: ah, I see elsewhere you've defined what you mean by "no compromises." Still, I'd be interested in hearing what makes Clay the front-runner in this field if you care to tell. :)
Clay seems to have a lot of potential in the systems programming space. The language is still in a bit of flux, but it's the first C alternative that still has me excited after using it (which can't be said for C++, D, Go, or Rust).
The folks in #clay on freenode are very friendly and helpful. You can tell that they've been keeping up with advances in PLT but that they also understand the kinds of low-level things systems programmers need to do.
I leave it to your Google skills to get the cultural context for that. :)
[1]: https://en.wikipedia.org/wiki/Vala_%28programming_language%2... [2]: https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementati...
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.
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.
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.
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.
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.
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 :)
I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds optional compile and runtime semantics that can be very helpful and powerful.
Some ideas:
No GC. This is NOT negotiable. I'm tired of belabouring that point.
Give me something nicer than the current C bitfield syntax.
Bounds-checked arrays...optionally. Make the distinction very obvious in the code/type-signature.
Higher-order functions, optionally. I don't really want an object system, just the ability to utilize callbacks in perhaps a nicer way than how function pointers currently function. I'd actually be happy with a standardized syntax sugar for function pointers.
Compile-time (only!) duck-typing and polymorphism. This part I think Go got right, but its sins were too great and the problem it was solving too poorly defined to make up for this.
Unicode-native from the ground up.
Clean up the string/array/pointer conflation, adopt the semantics of the bstring library as the default string type for the language, but leave open the door for 'raw-er' string implementations.
Don't reify language types without enabling people to implement their own data structures at the nitty-gritty level.
Cross-OS green-threads might be nice. Let people define their own concurrency models and semantics on top of what the language provides by default though. Same problem as the language type reification, don't delude yourself into thinking you've solved the world's problems with your subset of solutions. Let people use things like ptrheads without punishing them for doing so.
But most profoundly of all:
Make a language that would make writing a library like libev or libevent less bug-ridden and a lot more fun.
P.S. I sincerely hope someone writes a "pragmatist's" systems language like this.