9 ms·

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that i

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the foot with C are seemingly beyond counting. Are threads and async easier and/or safer now than 10-20 years ago, and with more direct language or standard library support? Is memory management in the standard library safer today? Are there concurrency primitives (beyond low-level interacting with epoll or kqueues or even fork or whatever)? I mean, it's obviously possible to write reliable, safe, secure, software in C (Linux, Git, SQLite, all come to mind), but how much easier has it gotten? Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

cygx 10y ago
Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.
- mitchty 10y ago
  Also if anyone is talking about systems programming, it would be beneficial if you specify what that means. I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons. Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditional setup. I know everyone is gung-ho about rust, but for the traditional systems programming crowd, its very new. Given how much it changes I would NOT want to bet on using it for at least 5 years. You don't switch just because something is better on memory safety. That is a nice to have thing. But changing 40ish years of things isn't something that you do without planning. Also, in my opinion Rust doesn't go far enough. I'd rather we move to things like Idris where I can prove much more than just memory safety. Rust is basically Ada/Oberon/Modula for the modern age. Nice, but ultimately not the first time this has happened.
  - solidsnack9000 10y ago
    Rust is more focused on C compatibility and simple (dumb) operational semantics than Idris and other dependently typed languages. Rust will never require GC, for example; maybe Idris doesn't now but is that a focus for them?
    - mitchty 10y ago
      Idris can compile to c, it requires no runtime. You're probably thinking of Haskell with its RTS. Idris is closer to ocaml in that regard. I cough may have already tried using idris in a kernel module. (for fun, not for serious)
      - im3w1l 10y ago
        And how did it go?
        mitchty 10y ago
        It worked surprisingly enough, well enough to make me consider trying out some gpio stuff to play around with. From there I'll let you know, I'm still learning Idris and dependent types so I'm a fairly boring test case. This was more of a: lets try it and see what goes kaboom test.
      - solidsnack9000 10y ago
        I'm not thinking of Haskell. Idris compiles to C but there is an open question there, with regards to how memory will be handled now and in the future. Swift does not need a runtime either, since it uses automatic reference counting for everything; but it has not gone as far as Rust, which defaults to stack allocation everywhere. This is not to say I doubt the ultimate approach of Idris: with dependent types you can do everything Rust is doing, and more. It's just a matter of project focus and ergonomics.
  - pjmlp 10y ago
    Which is why I am more willing to bet on Swift and .NET Native getting more widely used than Rust. Not to misrepresent the work the Rust guys are doing, it is great what they are doing and I have lots of fun dabbling on it. But new system programming programming languages tend to be adopted when an OS vendor tells devs, either use it or go code elsewhere. On OSes that have significant market share, devs tend to learn the new language instead of waving it away.
- SwellJoe 10y ago
  Sure, "systems programming" has a variety of meanings. But, there are a lot of areas where C was the obvious choice in the past but Go might be a suitable replacement today. Areas where concurrency and safety is maybe more important than raw performance: Databases (and there are many now written in Go, including alternative types of databases like time series, key/value, etc.), servers, etc. I tend to consider those systems level, even if they are not kernel level or running on bare metal. Obviously, if one defines "systems programming" more strictly than that, and only mean code that directly interacts with hardware or has hard realtime requirements (which also probably means it must interact directly with hardware), then Go does not make sense in that category. But, C has given up a lot of territory over the past several decades. When I first started programming, C was the language you used for writing almost any real application...if you weren't using assembly. That has changed a lot in the intervening years, and almost no one would think to use C for GUI apps today, for example.
  - solidsnack9000 10y ago
    Databases have been written in Java, too; but the combination of performance unpredictability (not something Go has addressed, since it is also garbage-collected) and a bad C compatibility story has proven to limit the reach of these projects.
    - throwbsidbdk 10y ago
      True. Even very successful database projects in Java have some issues with GC pauses. Go seems to be, IMO, taking the things Java is best at and trying to make something better. Basically, how would you build Java today if you could do it again?
      - pjmlp 10y ago
        > Basically, how would you build Java today if you could do it again? Take Modula-3 (1986), change the keywords to lowercase and re-brand it as "Cool Language X". Still better Go than C.
    - dlanouette 10y ago
- pjmlp 10y ago
  Given that Go is quite similar to Oberon, I don't fully agree. http://www.projectoberon.com/ http://www.projectoberon.com/ http://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://wiki.osdev.org/Go_Bare_Bones http://wiki.osdev.org/Go_Bare_Bones It just needs someone to port that Oberon code to Go, maybe people will then stop discussing how suitable Go is for systems programming.
- nickpsecurity 10y ago
  As pjmlp said, Go was a partial clone of Oberon-2 per Pike. Modified to suite modern requirements and whatever other designers put in. Oberon's were used in numerous operating systems. Latest was A2 Bluebottle which seemed faster than my Linux desktop despite being a GC language and running in full virtualization on Linux. The original language in that family, Modula-2, was even hosted on a PDP-11 like C. Therefore Go is closer to that space than people want to admit. A change of its runtime or compiler would let it do operating systems. Even Java (JX) and Haskell (House) do operating systems. I'm sure one could that is derived from and similar to a language designed for implementing OS's. :)
santaclaus 10y ago
> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? I imagine it is easier to hire C programmers than Rust programmers, at the moment, especially in fields like embedded development.
- mixedCase 10y ago
  Also Rust doesn't support compiling to certain architectures like the Xtensa ISA used in the popular ESP8266 and ESP32 wi-fi chips.
  - pawadu 10y ago
    Also, Rusts standard library is simply too big for many embedded systems. Last time I checked the compiler didn't support bare-metal and resource constrained builds without using crazy hacks. Although the situation may have improved since then.
    - rvense 10y ago
      I think it now amounts to adding a line to the file that tells it to not use the standard library. I've seen smaller projects that did it, and it was nothing like crazy hacks.
      - pawadu 10y ago
        Fair enough, but it didn't used to be like that: https://scialex.github.io/reenix.pdf https://scialex.github.io/reenix.pdf
        steveklabnik 10y ago
        Which part of this paper is the part you're worried about?
        pawadu 10y ago
dbcurtis 10y ago
> It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? Well, I've done C off-and-on, sometimes heavily, since the days of VT-100s and DEC-Writers. Modern C has always been a thing since the 1970's. Its just that the definition of "modern" keeps changing :) Yes, things are easier. It is possible to use the compiler features to write code that can be compile-time checked better than in the old days. A good IDE can use that to advantage to flag a lot of errors before you even compile. Yes, memory management can be easier. That said, most of the C I do now is for embedded microcontrollers with no OS underneath -- so memory safety and threads are DIY, and fork() is not a thing. As someone once said to me about 30 years ago, "C doesn't get in your way." Also, with C, I can, if I wish, get extremely fine-grained control over memory layout. So currently I tend to use C on bare metal, and Python 3.5 whenever I can get away with it, with wee, tiny, C extensions to Python where necessary. C still has a place, but since the advent of Python my motto is: "Life is too short for C++".
- a3n 10y ago
  > "Life is too short for C++" I've said for many years "Life is too long to write C++ for a living." And I haven't written C++ for many years.
solidsnack9000 10y ago
> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? While Rust might be feasible, Go can't really provide libraries like SQLite: Go's C compatibility story is disappointing and awkward.
- deleted 10y ago
  [deleted]
- dvirsky 10y ago
  Having written a project that loads Go plugins to a C app (namely redis), it's not great but in recent Go versions it's not too bad as well.
SQLite 10y ago
Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter. Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years. Some current reasons to continue to prefer C over Rust: (1) Rust is new and shiny and evolving. For a long-term project like SQLite, we want old and boring and static. (2) As far as I know, there is still just a single reference implementation of rustc. I'd like to see two or more independent implementations. (3) Rust's ever-tightening interdependence with Cargo and Git is disappointing. (4) While improving, Rust still needs better tooling for things like coverage analysis. (5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable? I realize this is just an unfortunate choice of terminology and not a fundamental flaw in the language, but I believe details like this need to be worked out before Rust is considered "mature".
- noir_lord 10y ago
  Pragmatism over "Oooh Shiny", one of the reasons I have huge respect for the sqlite project ;). Rust looks pretty decent but I'm still in the wait and see stage as well.
  - jandrese 10y ago
    I was trying to teach myself some Rust and found the state of the documentation to be very frustrating. The core language is decently documented with the manual, but the standard library documentation was out of date in many places, most annoyingly in the first few hits on Google. I found 5 different ways to read a file on Google, and only one of them still worked. Plus I saw the release notes on the newest version that the syntax that worked is now obsolete in favor of a new operator.
    - AsyncAwait 10y ago
      What are you missing from the up-to-date API reference[1]? [1] - https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/
CmdrSprinkles 10y ago
> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? From a professional standpoint, you might as well be asking if I have infinite money and time. Nothing happens in a vacuum But ignoring that, I would say, for me, it boils down to: 1. How important is performance? Is this a case where all that really matter is that it works? That I have a decent algorithm? Or am I going to be doing "real" optimization, even if only for a single platform? Even at just the "is my algorithm good?" stage I would lean toward C/C++ for systems work. 2. And this is the important one: Do I need this code to exist and be usable in one year? Five? Ten? Stuff like Rust might be fine for the one year frame, but for even as few as five I am going to want something established that I know will have support. And that means C/C++ for systems development (python, ruby, and js for scripting, and so forth).

cygx 10y ago

Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.

mitchty 10y ago
Also if anyone is talking about systems programming, it would be beneficial if you specify what that means. I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons. Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditional setup. I know everyone is gung-ho about rust, but for the traditional systems programming crowd, its very new. Given how much it changes I would NOT want to bet on using it for at least 5 years. You don't switch just because something is better on memory safety. That is a nice to have thing. But changing 40ish years of things isn't something that you do without planning. Also, in my opinion Rust doesn't go far enough. I'd rather we move to things like Idris where I can prove much more than just memory safety. Rust is basically Ada/Oberon/Modula for the modern age. Nice, but ultimately not the first time this has happened.
- solidsnack9000 10y ago
  Rust is more focused on C compatibility and simple (dumb) operational semantics than Idris and other dependently typed languages. Rust will never require GC, for example; maybe Idris doesn't now but is that a focus for them?
  - mitchty 10y ago
    Idris can compile to c, it requires no runtime. You're probably thinking of Haskell with its RTS. Idris is closer to ocaml in that regard. I cough may have already tried using idris in a kernel module. (for fun, not for serious)
    - im3w1l 10y ago
      And how did it go?
      - mitchty 10y ago
        It worked surprisingly enough, well enough to make me consider trying out some gpio stuff to play around with. From there I'll let you know, I'm still learning Idris and dependent types so I'm a fairly boring test case. This was more of a: lets try it and see what goes kaboom test.
    - solidsnack9000 10y ago
      I'm not thinking of Haskell. Idris compiles to C but there is an open question there, with regards to how memory will be handled now and in the future. Swift does not need a runtime either, since it uses automatic reference counting for everything; but it has not gone as far as Rust, which defaults to stack allocation everywhere. This is not to say I doubt the ultimate approach of Idris: with dependent types you can do everything Rust is doing, and more. It's just a matter of project focus and ergonomics.
- pjmlp 10y ago
  Which is why I am more willing to bet on Swift and .NET Native getting more widely used than Rust. Not to misrepresent the work the Rust guys are doing, it is great what they are doing and I have lots of fun dabbling on it. But new system programming programming languages tend to be adopted when an OS vendor tells devs, either use it or go code elsewhere. On OSes that have significant market share, devs tend to learn the new language instead of waving it away.
SwellJoe 10y ago
Sure, "systems programming" has a variety of meanings. But, there are a lot of areas where C was the obvious choice in the past but Go might be a suitable replacement today. Areas where concurrency and safety is maybe more important than raw performance: Databases (and there are many now written in Go, including alternative types of databases like time series, key/value, etc.), servers, etc. I tend to consider those systems level, even if they are not kernel level or running on bare metal. Obviously, if one defines "systems programming" more strictly than that, and only mean code that directly interacts with hardware or has hard realtime requirements (which also probably means it must interact directly with hardware), then Go does not make sense in that category. But, C has given up a lot of territory over the past several decades. When I first started programming, C was the language you used for writing almost any real application...if you weren't using assembly. That has changed a lot in the intervening years, and almost no one would think to use C for GUI apps today, for example.
- solidsnack9000 10y ago
  Databases have been written in Java, too; but the combination of performance unpredictability (not something Go has addressed, since it is also garbage-collected) and a bad C compatibility story has proven to limit the reach of these projects.
  - throwbsidbdk 10y ago
    True. Even very successful database projects in Java have some issues with GC pauses. Go seems to be, IMO, taking the things Java is best at and trying to make something better. Basically, how would you build Java today if you could do it again?
    - pjmlp 10y ago
      > Basically, how would you build Java today if you could do it again? Take Modula-3 (1986), change the keywords to lowercase and re-brand it as "Cool Language X". Still better Go than C.
  - dlanouette 10y ago
pjmlp 10y ago
Given that Go is quite similar to Oberon, I don't fully agree. http://www.projectoberon.com/ http://www.projectoberon.com/ http://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://wiki.osdev.org/Go_Bare_Bones http://wiki.osdev.org/Go_Bare_Bones It just needs someone to port that Oberon code to Go, maybe people will then stop discussing how suitable Go is for systems programming.
nickpsecurity 10y ago
As pjmlp said, Go was a partial clone of Oberon-2 per Pike. Modified to suite modern requirements and whatever other designers put in. Oberon's were used in numerous operating systems. Latest was A2 Bluebottle which seemed faster than my Linux desktop despite being a GC language and running in full virtualization on Linux. The original language in that family, Modula-2, was even hosted on a PDP-11 like C. Therefore Go is closer to that space than people want to admit. A change of its runtime or compiler would let it do operating systems. Even Java (JX) and Haskell (House) do operating systems. I'm sure one could that is derived from and similar to a language designed for implementing OS's. :)

santaclaus 10y ago

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? I imagine it is easier to hire C programmers than Rust programmers, at the moment, especially in fields like embedded development.

mixedCase 10y ago
Also Rust doesn't support compiling to certain architectures like the Xtensa ISA used in the popular ESP8266 and ESP32 wi-fi chips.
- pawadu 10y ago
  Also, Rusts standard library is simply too big for many embedded systems. Last time I checked the compiler didn't support bare-metal and resource constrained builds without using crazy hacks. Although the situation may have improved since then.
  - rvense 10y ago
    I think it now amounts to adding a line to the file that tells it to not use the standard library. I've seen smaller projects that did it, and it was nothing like crazy hacks.
    - pawadu 10y ago
      Fair enough, but it didn't used to be like that: https://scialex.github.io/reenix.pdf https://scialex.github.io/reenix.pdf
      - steveklabnik 10y ago
        Which part of this paper is the part you're worried about?
        pawadu 10y ago

dbcurtis 10y ago

> It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? Well, I've done C off-and-on, sometimes heavily, since the days of VT-100s and DEC-Writers. Modern C has always been a thing since the 1970's. Its just that the definition of "modern" keeps changing :) Yes, things are easier. It is possible to use the compiler features to write code that can be compile-time checked better than in the old days. A good IDE can use that to advantage to flag a lot of errors before you even compile. Yes, memory management can be easier. That said, most of the C I do now is for embedded microcontrollers with no OS underneath -- so memory safety and threads are DIY, and fork() is not a thing. As someone once said to me about 30 years ago, "C doesn't get in your way." Also, with C, I can, if I wish, get extremely fine-grained control over memory layout. So currently I tend to use C on bare metal, and Python 3.5 whenever I can get away with it, with wee, tiny, C extensions to Python where necessary. C still has a place, but since the advent of Python my motto is: "Life is too short for C++".

a3n 10y ago
> "Life is too short for C++" I've said for many years "Life is too long to write C++ for a living." And I haven't written C++ for many years.

solidsnack9000 10y ago

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? While Rust might be feasible, Go can't really provide libraries like SQLite: Go's C compatibility story is disappointing and awkward.

deleted 10y ago
[deleted]
dvirsky 10y ago
Having written a project that loads Go plugins to a C app (namely redis), it's not great but in recent Go versions it's not too bad as well.

SQLite 10y ago

Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter. Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years. Some current reasons to continue to prefer C over Rust: (1) Rust is new and shiny and evolving. For a long-term project like SQLite, we want old and boring and static. (2) As far as I know, there is still just a single reference implementation of rustc. I'd like to see two or more independent implementations. (3) Rust's ever-tightening interdependence with Cargo and Git is disappointing. (4) While improving, Rust still needs better tooling for things like coverage analysis. (5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable? I realize this is just an unfortunate choice of terminology and not a fundamental flaw in the language, but I believe details like this need to be worked out before Rust is considered "mature".

noir_lord 10y ago
Pragmatism over "Oooh Shiny", one of the reasons I have huge respect for the sqlite project ;). Rust looks pretty decent but I'm still in the wait and see stage as well.
- jandrese 10y ago
  I was trying to teach myself some Rust and found the state of the documentation to be very frustrating. The core language is decently documented with the manual, but the standard library documentation was out of date in many places, most annoyingly in the first few hits on Google. I found 5 different ways to read a file on Google, and only one of them still worked. Plus I saw the release notes on the newest version that the syntax that worked is now obsolete in favor of a new operator.
  - AsyncAwait 10y ago
    What are you missing from the up-to-date API reference[1]? [1] - https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/

CmdrSprinkles 10y ago

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? From a professional standpoint, you might as well be asking if I have infinite money and time. Nothing happens in a vacuum But ignoring that, I would say, for me, it boils down to: 1. How important is performance? Is this a case where all that really matter is that it works? That I have a decent algorithm? Or am I going to be doing "real" optimization, even if only for a single platform? Even at just the "is my algorithm good?" stage I would lean toward C/C++ for systems work. 2. And this is the important one: Do I need this code to exist and be usable in one year? Five? Ten? Stuff like Rust might be fine for the one year frame, but for even as few as five I am going to want something established that I know will have support. And that means C/C++ for systems development (python, ruby, and js for scripting, and so forth).