4 ms·

"You could also program the -10 in a beautiful, roughly-C-level language from CMU, called Bliss. I see C and I remember Bliss, and I could weep." I see C and I

"You could also program the -10 in a beautiful, roughly-C-level language from CMU, called Bliss. I see C and I remember Bliss, and I could weep." I see C and I wonder if that's the best we can do for a systems programming language. Maybe C is just a local optimum that we have just invested too much manpower into to switch to anything else?

Todd 13y ago
I wasn't aware of BLISS: http://en.wikipedia.org/wiki/BLISS http://en.wikipedia.org/wiki/BLISS It does seem to have some interesting features for a systems level language--for example, expressions over statements and references over pointers.
- nostrademons 13y ago
  "Worse is Better" has a plausible explanation why C won out: http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html Curiously, both Google and Apple follow the "MIT/Stanford" school of design (though Google has lately been trending toward the "New Jersey" school). And it's generally been working out for them. Microsoft was always the New Jersey school, and it isn't exactly working for them now, although it did for many years.
  - acchow 13y ago
    Things not working out for MS has little to do with engineering and a lot to do with direction and product.
    - nostrademons 13y ago
      These are also product philosophies, relating to how much you are willing to make life difficult for yourself to keep the interface to your product simple. One thing my VP (at Google) said has stuck with me: "It's okay if the code is gross as long as it's hidden behind an API. If the problem's complex, that complexity should be captured in the code rather than forcing the user to deal with it."
  - fohstick 13y ago
    Its not related to the discussion, but where can I get the rest of those articles? The links to next/previous appear to be broken.
    - nostrademons 13y ago
      JWZ reposted it off Dreamsongs.net, Richard Gabriel's personal site. I think these may be what you want: http://dreamsongs.net/Essays.html http://dreamsongs.net/Essays.html
  - spot 13y ago
    no, it just happened to be in the right place at the right time. like JS.
pcwalton 13y ago
> I see C and I wonder if that's the best we can do for a systems programming language. Maybe C is just a local optimum that we have just invested too much manpower into to switch to anything else? At this point the ecosystem around C is too big to justify the cost of switching for the domains it's used in. Any new contender is going to have to offer something new, without giving up any cost in performance or control over the machine. With Rust (disclaimer: I work on Rust) we're shooting for safety to give us that edge—having the compiler reliably prevent use-after-frees and buffer overflows instead of discovering them through 0-days, without the traditional approaches that sacrifice performance and control over the machine (GC), seems pretty compelling to me. Even if we do succeed in getting enough new projects to use a safe language to make a difference, though, C will still be immortal; once a language has that much staying power it'll be around forever.
- jes5199 13y ago
  the "who's memory is this anyway" type checking thing in Rust is one of the most interesting advancements of the state of the art of low-level programming that I'm aware of in my lifetime. ... I sort of think we should just port it to C.
  - pcwalton 13y ago
    > ... I sort of think we should just port it to C. It's been done, at least in academia: http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/ We owe a huge debt to Cyclone :)
- pron 13y ago
  Let me first say the I applaud Rust and the effort you're making in developing a new, safe systems-programming language. But I do have one concern. I like this quote by an Intel engineer, which appears on the back of Java Concurrency in Practice: "For the past 30 years, computer performance has been driven by Moore's Law; from now on, it will be driven by Amdahl's Law." I think that this is the biggest challenge facing software development in this age. Now, I know concurrency is core to Rust, and I know that Rust adopts message passing as the principal concurrency construct. Message passing is terrific, extremely useful, and as close as we've got to a model of programming multi-core that's simple and easy to grasp. But at the end of the day, we do need a way to develop efficient mutable, concurrent data structures. Languages that rely on message passing, like Erlang, usually pass this problem down to a database, but the problem still has to be solved. You say that languages resorting to GC "sacrifice performance and control over the machine". But GC already provides better throughput than manual memory allocation in practically all circumstances, and suffers mostly from latency issues (pauses), but even those are being worked on with some good progress (like the work done by Azul on their JVM). The only major true sacrifice GC requires is extra RAM, which is becoming ever cheaper. GC is currently the best way to develop efficient concurrent (shared) data structures. There are ways of writing those without a general-purpose GC (RCU and hazard pointers), but those wither require kernel cooperation, and/or suffer from worse worst-case performance, and/or quickly transform into GC when generalized. I know the plan is for Rust to have a GC as part of the libraries, but this problem (of developing efficient concurrent data structures) must be addressed. It's possible that hardware has become too complicated for us not to give up some control over to some runtime. Maybe we're at a stage where low-level full-control programming is incompatible with fully utilizing the hardware for best performance. It is possible that low-level systems programming languages will excel in resource constrained environments and have several other advantages, but sheer performance/scalability won't be one of them (at least on server-class hardware).

Todd 13y ago

I wasn't aware of BLISS: http://en.wikipedia.org/wiki/BLISS http://en.wikipedia.org/wiki/BLISS It does seem to have some interesting features for a systems level language--for example, expressions over statements and references over pointers.

nostrademons 13y ago
"Worse is Better" has a plausible explanation why C won out: http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html Curiously, both Google and Apple follow the "MIT/Stanford" school of design (though Google has lately been trending toward the "New Jersey" school). And it's generally been working out for them. Microsoft was always the New Jersey school, and it isn't exactly working for them now, although it did for many years.
- acchow 13y ago
  Things not working out for MS has little to do with engineering and a lot to do with direction and product.
  - nostrademons 13y ago
    These are also product philosophies, relating to how much you are willing to make life difficult for yourself to keep the interface to your product simple. One thing my VP (at Google) said has stuck with me: "It's okay if the code is gross as long as it's hidden behind an API. If the problem's complex, that complexity should be captured in the code rather than forcing the user to deal with it."
- fohstick 13y ago
  Its not related to the discussion, but where can I get the rest of those articles? The links to next/previous appear to be broken.
  - nostrademons 13y ago
    JWZ reposted it off Dreamsongs.net, Richard Gabriel's personal site. I think these may be what you want: http://dreamsongs.net/Essays.html http://dreamsongs.net/Essays.html
- spot 13y ago
  no, it just happened to be in the right place at the right time. like JS.

pcwalton 13y ago

> I see C and I wonder if that's the best we can do for a systems programming language. Maybe C is just a local optimum that we have just invested too much manpower into to switch to anything else? At this point the ecosystem around C is too big to justify the cost of switching for the domains it's used in. Any new contender is going to have to offer something new, without giving up any cost in performance or control over the machine. With Rust (disclaimer: I work on Rust) we're shooting for safety to give us that edge—having the compiler reliably prevent use-after-frees and buffer overflows instead of discovering them through 0-days, without the traditional approaches that sacrifice performance and control over the machine (GC), seems pretty compelling to me. Even if we do succeed in getting enough new projects to use a safe language to make a difference, though, C will still be immortal; once a language has that much staying power it'll be around forever.

jes5199 13y ago
the "who's memory is this anyway" type checking thing in Rust is one of the most interesting advancements of the state of the art of low-level programming that I'm aware of in my lifetime. ... I sort of think we should just port it to C.
- pcwalton 13y ago
  > ... I sort of think we should just port it to C. It's been done, at least in academia: http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/ We owe a huge debt to Cyclone :)
pron 13y ago
Let me first say the I applaud Rust and the effort you're making in developing a new, safe systems-programming language. But I do have one concern. I like this quote by an Intel engineer, which appears on the back of Java Concurrency in Practice: "For the past 30 years, computer performance has been driven by Moore's Law; from now on, it will be driven by Amdahl's Law." I think that this is the biggest challenge facing software development in this age. Now, I know concurrency is core to Rust, and I know that Rust adopts message passing as the principal concurrency construct. Message passing is terrific, extremely useful, and as close as we've got to a model of programming multi-core that's simple and easy to grasp. But at the end of the day, we do need a way to develop efficient mutable, concurrent data structures. Languages that rely on message passing, like Erlang, usually pass this problem down to a database, but the problem still has to be solved. You say that languages resorting to GC "sacrifice performance and control over the machine". But GC already provides better throughput than manual memory allocation in practically all circumstances, and suffers mostly from latency issues (pauses), but even those are being worked on with some good progress (like the work done by Azul on their JVM). The only major true sacrifice GC requires is extra RAM, which is becoming ever cheaper. GC is currently the best way to develop efficient concurrent (shared) data structures. There are ways of writing those without a general-purpose GC (RCU and hazard pointers), but those wither require kernel cooperation, and/or suffer from worse worst-case performance, and/or quickly transform into GC when generalized. I know the plan is for Rust to have a GC as part of the libraries, but this problem (of developing efficient concurrent data structures) must be addressed. It's possible that hardware has become too complicated for us not to give up some control over to some runtime. Maybe we're at a stage where low-level full-control programming is incompatible with fully utilizing the hardware for best performance. It is possible that low-level systems programming languages will excel in resource constrained environments and have several other advantages, but sheer performance/scalability won't be one of them (at least on server-class hardware).