4 ms·

> But those aren't the reasons why most C code is in C. Mostly, C is important simply because lots of code was written in it before safer languages gained momen

by rlpb 13y ago

> But those aren't the reasons why most C code is in C. Mostly, C is important simply because lots of code was written in it before safer languages gained momentum... I disagree. Certainly in the FLOSS community, I don't think this is true. C is a lowest common denominator. No higher level language has "won". So if you want the functionality in a library you write to be available to the majority, you will need to make it available (ie. provide bindings for) a number of high level languages. The easiest way to do this is to provide a C-level API. This works well because the higher level languages are all implemented in C. This isn't because C is more popular, but because it is a low level language. The easiest way to provide a C-level API is to write the code in C. So: library writers often write implementations in C. There are three alternatives: 1) Independently implement each individual useful piece of functionality in every high level language. This does happen, but more general implementations tend to move quicker, since they have more users (because they support multiple high level languages) and thus more contributors. The number of contributors might dwindle because of the requirement to code in C, but I don't think this has happened to a significant enough extent yet. 2) Implement libraries in a higher level language and then provide bindings to every other popular higher level language. This can be done, but I haven't seen much of it. Higher level languages seem to make it easier to provide bindings to a C-level API rather than APIs written in a different higher level languages. This may be something to do with impedence mismatches in higher level language concepts. 3) A higher level language "wins", and everyone moves to such an ecosystem. This can only happen if other higher level languages lose. I don't think there is any sign of this happening.

gaius 13y ago
This works well because the higher level languages are all implemented in C Not actually true; there are many high level self-hosted languages, OCaml, Haskell, Forth, Lisp, etc etc. But all these languages generally prioritize having a good C FFI. It is interesting that e.g. Thrift, Protocol Buffers et al don't seem to have made much of an inroad here.
- userbinator 13y ago
  Ocaml's VM is written in C.
- Dewie 13y ago
  Isn't Haskell's runtime written in C? Or maybe it used to be but they changed it.
  - wting 13y ago
    The runtime is in C-- but has the option of using LLVM for code generation.
- rlpb 13y ago
  > It is interesting that e.g. Thrift, Protocol Buffers et al don't seem to have made much of an inroad here. D-Bus is probably the biggest contender at the moment.
- theseoafs 13y ago
  > It is interesting that e.g. Thrift, Protocol Buffers et al don't seem to have made much of an inroad here. I'm actually working on a tool called Haris to deal with this very problem. I'm looking to do structured binary data serialization in a way that's efficient, lightweight, and portable (in that it conforms to the C standard). Keep an eye out, I'll probably be posting it on Hacker News within the next few weeks.
- nostrademons 13y ago
  Thrift, protobufs don't really work for in-process communication because the cost of serialization can get pretty high - you can easily blow most of your CPU time just serializing protobufs across language boundaries (been there, done that). I think Cap'n Proto may be an interesting approach - the memory layout is the same in all languages, and Kenton is reportedly working on 0-copy IPC - but it remains to be seen how it will turn out.
userbinator 13y ago
> This isn't because C is more popular, but because it is a low level language. I consider C to be high level enough to be reasonably portable and expressive, but at the same time low level enough that it can do a lot of things higher level languages can't.

by rlpb 13y ago

gaius 13y ago

This works well because the higher level languages are all implemented in C Not actually true; there are many high level self-hosted languages, OCaml, Haskell, Forth, Lisp, etc etc. But all these languages generally prioritize having a good C FFI. It is interesting that e.g. Thrift, Protocol Buffers et al don't seem to have made much of an inroad here.

userbinator 13y ago
Ocaml's VM is written in C.
Dewie 13y ago
Isn't Haskell's runtime written in C? Or maybe it used to be but they changed it.
- wting 13y ago
  The runtime is in C-- but has the option of using LLVM for code generation.
rlpb 13y ago
> It is interesting that e.g. Thrift, Protocol Buffers et al don't seem to have made much of an inroad here. D-Bus is probably the biggest contender at the moment.
theseoafs 13y ago
> It is interesting that e.g. Thrift, Protocol Buffers et al don't seem to have made much of an inroad here. I'm actually working on a tool called Haris to deal with this very problem. I'm looking to do structured binary data serialization in a way that's efficient, lightweight, and portable (in that it conforms to the C standard). Keep an eye out, I'll probably be posting it on Hacker News within the next few weeks.
nostrademons 13y ago
Thrift, protobufs don't really work for in-process communication because the cost of serialization can get pretty high - you can easily blow most of your CPU time just serializing protobufs across language boundaries (been there, done that). I think Cap'n Proto may be an interesting approach - the memory layout is the same in all languages, and Kenton is reportedly working on 0-copy IPC - but it remains to be seen how it will turn out.

userbinator 13y ago

> This isn't because C is more popular, but because it is a low level language. I consider C to be high level enough to be reasonably portable and expressive, but at the same time low level enough that it can do a lot of things higher level languages can't.