10 ms·

I concur with the concurrer and the author with my own more 'positive' addendum: I just want a cleaned/tarted up C. Something that doesn't make the critical mi

I concur with the concurrer and the author with my own more 'positive' addendum: 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.

berntb 15y ago
>>No GC. 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.)
- heretohelp 15y ago
  It seems most people don't really understand the core of systems programming. 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.
  - batista 15y ago
    It seems most people don't really understand the core of systems programming. 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. 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.
    - heretohelp 15y ago
      >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 :)
masklinn 15y ago
Wasn't bitc trying to do some of that stuff? 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 [0] http://www.rust-lang.org/ http://www.rust-lang.org/
- heretohelp 15y ago
  Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust: 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.
  - masklinn 15y ago
    > 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. 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.
groovy2shoes 15y ago
Have you had a look at Clay? http://claylabs.com/clay/ http://claylabs.com/clay/
- heretohelp 15y ago
  It's the most promising out of the current cohort that includes Rust, I'll say that much. Clay seems to understand that you cannot compromise.
  - kibwen 15y ago
    "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. :)
    - heretohelp 15y ago
      The funniest and most succinct reply I can muster for you is that Clay is the programming language least designed for quiche-eaters. I leave it to your Google skills to get the cultural context for that. :)
    - groovy2shoes 15y ago
      From a language level, Clay offers a lot of features over plain old C: strong typing, type parameters, polymorphism, etc. All of the additional features map onto the machine in a very specific way, giving you the same kind of control that structs, arrays, etc. do in C. It doesn't force garbage collection on you. You can even call external C functions by simply declaring them, similar to how you would do it in C itself. 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.
msutherl 15y ago
I'm curious if anybody has written something equivalent to CoffeeScript for C...
- andolanra 15y ago
  Something that provides syntactic sugar that compiles down to C? You'd be looking for Vala[1]. I haven't used it so I can't vouch for it in practice, but I know it compiles to C and uses the GObject system for object-oriented programming. It's not as much of a syntax change for C, but it apparently adds quite a bit semantically. There's also a Scheme implementation called Chicken[2] that compiles to C source, and I know there are others that I'm not recalling off the top of my head. [1]: https://en.wikipedia.org/wiki/Vala_%28programming_language%29 https://en.wikipedia.org/wiki/Vala_%28programming_language%2... [2]: https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementation%29 https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementati...
- losvedir 15y ago
  As I understand it, this fellow named Bjarne Stroustrup did once. Of course, the project eventually grew beyond its humble beginnings...

berntb 15y ago

>>No GC. 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.)

heretohelp 15y ago
It seems most people don't really understand the core of systems programming. 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.
- batista 15y ago
  It seems most people don't really understand the core of systems programming. 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. 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.
  - heretohelp 15y ago
    >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 :)

masklinn 15y ago

Wasn't bitc trying to do some of that stuff? 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 [0] http://www.rust-lang.org/ http://www.rust-lang.org/

heretohelp 15y ago
Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust: 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.
- masklinn 15y ago
  > 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. 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.

groovy2shoes 15y ago

Have you had a look at Clay? http://claylabs.com/clay/ http://claylabs.com/clay/

heretohelp 15y ago
It's the most promising out of the current cohort that includes Rust, I'll say that much. Clay seems to understand that you cannot compromise.
- kibwen 15y ago
  "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. :)
  - heretohelp 15y ago
    The funniest and most succinct reply I can muster for you is that Clay is the programming language least designed for quiche-eaters. I leave it to your Google skills to get the cultural context for that. :)
  - groovy2shoes 15y ago
    From a language level, Clay offers a lot of features over plain old C: strong typing, type parameters, polymorphism, etc. All of the additional features map onto the machine in a very specific way, giving you the same kind of control that structs, arrays, etc. do in C. It doesn't force garbage collection on you. You can even call external C functions by simply declaring them, similar to how you would do it in C itself. 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.

msutherl 15y ago

I'm curious if anybody has written something equivalent to CoffeeScript for C...

andolanra 15y ago
Something that provides syntactic sugar that compiles down to C? You'd be looking for Vala[1]. I haven't used it so I can't vouch for it in practice, but I know it compiles to C and uses the GObject system for object-oriented programming. It's not as much of a syntax change for C, but it apparently adds quite a bit semantically. There's also a Scheme implementation called Chicken[2] that compiles to C source, and I know there are others that I'm not recalling off the top of my head. [1]: https://en.wikipedia.org/wiki/Vala_%28programming_language%29 https://en.wikipedia.org/wiki/Vala_%28programming_language%2... [2]: https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementation%29 https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementati...
losvedir 15y ago
As I understand it, this fellow named Bjarne Stroustrup did once. Of course, the project eventually grew beyond its humble beginnings...