5 ms·

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

by 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.
- steveklabnik 10y ago
  > Given how much it changes I would NOT want to bet on using it for at least 5 years. Rust may be changing, but it's almost entirely _additions_. We've been stable for roughly 18 months now.
  - mitchty 10y ago
    Sorry should have been more clear, my meaning was more around things like cargo and tooling rather than the language proper. Don't take any of my criticism too harshly either, I do like and use Rust for side projects. But it is about 3 years away from where I'd consider using it for anything. I'm a bit more conservative than most here seem to be. Funny part is I'm the maverick in using new stuff compared to the people I work with. Keep on trying to improve things either way!
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. :)

by cygx 10y ago

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.
steveklabnik 10y ago
> Given how much it changes I would NOT want to bet on using it for at least 5 years. Rust may be changing, but it's almost entirely _additions_. We've been stable for roughly 18 months now.
- mitchty 10y ago
  Sorry should have been more clear, my meaning was more around things like cargo and tooling rather than the language proper. Don't take any of my criticism too harshly either, I do like and use Rust for side projects. But it is about 3 years away from where I'd consider using it for anything. I'm a bit more conservative than most here seem to be. Funny part is I'm the maverick in using new stuff compared to the people I work with. Keep on trying to improve things either way!

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. :)