9 ms·

The successor to C is Go. Go inherits from Oberon through Robert Griesemer, and from C through Ken Thompson (father of Unix) and Rob Pike (Bell Labs). I don't

The successor to C is Go. Go inherits from Oberon through Robert Griesemer, and from C through Ken Thompson (father of Unix) and Rob Pike (Bell Labs). I don't bother with C anymore, except in small parts of code where every cycle counts. Just about anything you write in C can be mechanically translated to Go. C++ shows us what NOT to do. I've used C++ for most of my professional programming career and it's simply an impediment. Huge waste of time and energy.

chungy 4y ago
Go is the successor to C++, maybe Java also. Rust is the successor to C.
- wheelerof4te 4y ago
  Literally, the opposite is true. If anything builds upon C++, it would be Rust.
  - deltasevennine 4y ago
    In terms of zero cost abstractions, yes. In terms of OOP. No.
    - tmtvl 4y ago
      Does that mean that you don't consider code like... std::args().skip(1).next().unwrap(); ...to be OOP? Because that looks remarkably like some Java code I've written.
      - deltasevennine 4y ago
        That's the same as a deeply nested data structure. A product type. It's not exclusively an OOP concept but it could be to someone who hasn't really delineated the concept of what OOP is. What I mean by OOP is the smallest unit of programming being an Object with mutating data. These objects are basically combinations of mutable data and methods tied together into entities. Imagine a graph of a bunch of mini-programs with mutating state, moving around, getting injected into one another and talking to one another. This is OOP. This is opposed to another style of programming where data flows through pipelines from input to output rather then a bunch of entities messaging each other and changing each others state. Both Rust and Go are moving away from this OOP paradigm of programming by putting less emphasis on OOP based syntax.
      - steveklabnik 4y ago
        The real problem is that OOP has no universally agreed-upon definition. Two of the most popular are what I've nicknamed the "Smalltalk definition" and the "Java definition". Alan Kay, on OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. Java, which I attribute to Java simply because it's very popular and clear about how they think about this: > https://docs.oracle.com/javase/tutorial/java/concepts/ https://docs.oracle.com/javase/tutorial/java/concepts/ defines five core concepts: > * An object is a software bundle of related state and behavior. > * A class is a blueprint or prototype from which objects are created. > * Inheritance provides a powerful and natural mechanism for organizing and structuring your software. > * An interface is a contract between a class and the outside world. > * A package is a namespace for organizing classes and interfaces in a logical manner. This Rust code is missing key aspects of both definitions. The surface syntax may look the same, but the details are different: vs Smalltalk, this is the opposite of late bound, or "messaging": it's all early bound, aka statically dispatched. vs Java, there's no objects here: while there is a method syntax, Rust separates state and behavior, into structs and functions. Methods are functions that support the method call syntax in addition to the regular function syntax. There's no classes here, nor inheritance. There is the use of an interface-like thing, and namespace/package like things. TL;DR: there's more to OOP than method syntax.
    - wheelerof4te 4y ago
      I think people got burnt with OOP one too many times, so they stripped it out in both Go and Rust. Rust still has structs with methods kind of OOP, but you can also have that in C using structs with function pointers. So, not really OOP. Let it die already.
      - tialaramex 4y ago
        Object Oriented Programming is a style, like Generic Programming. A language can offer features which support this style well, or not, and you can insist on programming this way regardless of whether the features support it well.
        deltasevennine 4y ago
        But he's saying the style is bad. Therefore new languages don't support it, well. What do you have to say to that rather then reiterating what everyone knows that OOP is a style of programming.
        tialaramex 4y ago
        I don't think OOP style is bad but it isn't the choice I'd make in many cases. Accordingly I don't think languages should go out of their way to support this style. In particular Multiple Inheritance is the sort of thing OO languages have (C++ and Python for example) which I am confident is a mistake. If your OO model requires multiple inheritance the model is wrong, go re-design it.
    - kaashif 4y ago
      Rust got rid of inheritance, does that mean it's not OOP? There are effectively still classes, methods, members, interfaces, with all the syntactic sugar that goes along with it. https://doc.rust-lang.org/book/ch17-00-oop.html https://doc.rust-lang.org/book/ch17-00-oop.html It feels like this whole discussion about successors and whatnot is just pointless semantics. Rust fits into a lot of C and C++ use cases and is a good tool to have in your toolbox. C still has its place too.
      - deltasevennine 4y ago
        You can twist any language to be OOP if you want. However rust is not primarily focused towards that type of abstraction. Java and C++ are focused towards it. I highly disagree. It is not "pointless semantics". To think everything in the world is some tool in a toolbox and nothing is truly ever bad and everything has a use is naive. Some things are good some things are bad and some things are OOP while other things are not. Rust is not focusing on the OOP philosophy. Both GO and Rust are moving away from that style of abstraction in terms of philosophical goals. If you want to twist the language into OOP that's still possible and still your prerogative. But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. I'm not saying OOP is bad. I'm saying that this is the current status quo. My opinion on the OOP style was not mentioned at all.
        scratcheee 4y ago
        All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me. It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further. The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal. It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.
- aliqot 4y ago
  Go is the successor to C, according to G and creators Carbon is the successor to C++, according to G and creators
  - sqeaky 4y ago
    Why do their opinions impact me? I different goals than them.
  - KerrAvon 4y ago
    Not really. Ritchie wasn't involved in Go, and the C that we all use is not the same C Thompson wrote. edit: typo
  - eitland 4y ago
    However smart those people are compared to me this still makes no sense until a significant chunk of the Linux kernel is written in Go and Go is relevant option for writing latency sensitive code (real time audio etc). Go might be a good language even if I prefer otherwise, but the next C it is not, at least not yet.
    - deleted 4y ago
      [deleted]
    - aliqot 4y ago
      > However smart those people are compared to me this still makes no sense until a significant chunk of the Linux kernel is written in Go I'm not much of a runner, you want to catch those goalposts before they get away?
      - sqeaky 4y ago
- kaashif 4y ago
  Rust is far more similar to C++ than C - RAII, generics, etc are language features that aren't in C, never will be in C, and don't belong in C. Rust fits into a lot of C and C++ use cases, saying it's the successor of one or the other doesn't seem all that coherent.
- kramerger 4y ago
  C is an extremely simple language. Rust is one of the most complex languages I have worked with (most of that complexity could have been avoided with a better language design). So no, I don't consider them related in any ways.
  - scratcheee 4y ago
    >most of that complexity could have been avoided with a better language design Are you saying that the ownership/borrowing model for memory safety was a poor choice, or that it's possible to make a language on that model that has vastly less complexity than Rust? Because your phrasing implies the second, but I don't think I've ever heard anyone make that claim before (presumably because there's no such language lying around anywhere, so it seems hard to defend). If the first, then I'd point out that wouldn't be a language design flaw, but rather a flawed goal (ie a goal that proved too complex to achieve) - their goal was a memory safe language that didn't rely on a GC, and the resultant design complexity is basically the best example of a way to solve for that goal so far. I'm sure there will eventually be simpler options, but I don't think you can blame designers for not having access to undiscovered techniques. That's what most anti-Rust arguements boil down to. If you just mean you don't like the syntax, then yeah, I agree, it's a bit alien for me too, but I hardly concider that anything beyond personal taste and the difficulty of learning something new.
    - kramerger 4y ago
      I meant the general syntax design, not specifically the memory model. For example there are multiple syntaxes for adding annotations or directives to the code. Some things are written very differently compared to other languages for no apparent reasons (e.g. derive). Some keywords have different meaning in different contexts (e.g self and type). And so on... Basically, there are some rough edges that shouldn't really be there
  - badsectoracula 4y ago
    > C is an extremely simple language. C is simple compared to others, however it is far from "extremely simple". The language i'd call extremely simple (while still being usable) is Wirth's Oberon-07[0]. Note the "-07" part, there have been a bunch of "Oberons", many which add a ton of additional stuff, not all Oberons are the same or even can be called simple. Oberon-07 however was designed to be simple while also being usable to create a full GUI OS on a custom architecture[1]. [0] http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf [1] http://www.projectoberon.com/ http://www.projectoberon.com/
YetAnotherNick 4y ago
No, it isn't. GC languages are fundamentally different than non GC for lot of applications.
- deltasevennine 4y ago
  Exactly. High performance applications with zero cost abstractions are required to truly be a successor. Go or Java will never replace C++ for high performance applications like Game engines. Rust might replace it though.
  - pier25 4y ago
    Anything realtime will be either C or C++. Audio dev for example. Bitwig (the DAW) has a Java GUI but the core engine is C++ iirc.
  - deleted 4y ago
    [deleted]
- bugfix-66 4y ago
  The successor to C must be designed for a world where it's typical for an application to use dozens of CPU cores. This is the main reason we need a successor to C. Garbage collection becomes almost a necessity when you have enormous concurrency and parallelism. I wonder whether you have experience writing such programs with pthread and malloc/free?
  - Ar-Curunir 4y ago
    > Garbage collection becomes almost a necessity when you have enormous concurrency and parallelism. No, you can just use Rust, which provides thread safety without garbage collection.
    - sqeaky 4y ago
      I am not going to call the problem solved, but there are other options too. C++ has libraries threadsafe shared pointers, interthread message passing, transactional memory, futures/promises, work stealing queues, and access to all the OS primitives to build anything else.
ajross 4y ago
No. Go shares a lot of thematic/aesthetic/design principles with C for sure. It prioritizes language clarity, simplicity and universality over features. But the layer being abstracted by the language is totally different. Go is a managed runtime which assumes the use of a threadsafe heap on a multicore host, it provides a stack switching engine for concurrency management and a scheduler on top of that, and assumes the use of robust I/O primitives with asynchronous capabilities. C gives you an easy way to express access basic CPU operations on top of a flat memory model, and maps well to the lowest level of OS system calls. And that's about it. It has some simple library stuff on top that gives you bits and pieces of what you get with big managed languages, but in general everyone recognizes that this isn't its strength and that you shouldn't use it for those problems. But the flip side is that if you have problems that don't map to managed environments well, C remains about as good an environment as you're going to find. If you're writing kernels and drivers and firmware, you aren't going to be able to use Go.
norswap 4y ago
Go is a moderately better C. In terms of expressivity, it is ages behind C++. It also has a garbage collector, which while fine for most use cases is not acceptable for some use cases that C/C++ (and now Rust) are being used for.

chungy 4y ago

Go is the successor to C++, maybe Java also. Rust is the successor to C.

wheelerof4te 4y ago
Literally, the opposite is true. If anything builds upon C++, it would be Rust.
- deltasevennine 4y ago
  In terms of zero cost abstractions, yes. In terms of OOP. No.
  - tmtvl 4y ago
    Does that mean that you don't consider code like... std::args().skip(1).next().unwrap(); ...to be OOP? Because that looks remarkably like some Java code I've written.
    - deltasevennine 4y ago
      That's the same as a deeply nested data structure. A product type. It's not exclusively an OOP concept but it could be to someone who hasn't really delineated the concept of what OOP is. What I mean by OOP is the smallest unit of programming being an Object with mutating data. These objects are basically combinations of mutable data and methods tied together into entities. Imagine a graph of a bunch of mini-programs with mutating state, moving around, getting injected into one another and talking to one another. This is OOP. This is opposed to another style of programming where data flows through pipelines from input to output rather then a bunch of entities messaging each other and changing each others state. Both Rust and Go are moving away from this OOP paradigm of programming by putting less emphasis on OOP based syntax.
    - steveklabnik 4y ago
      The real problem is that OOP has no universally agreed-upon definition. Two of the most popular are what I've nicknamed the "Smalltalk definition" and the "Java definition". Alan Kay, on OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. Java, which I attribute to Java simply because it's very popular and clear about how they think about this: > https://docs.oracle.com/javase/tutorial/java/concepts/ https://docs.oracle.com/javase/tutorial/java/concepts/ defines five core concepts: > * An object is a software bundle of related state and behavior. > * A class is a blueprint or prototype from which objects are created. > * Inheritance provides a powerful and natural mechanism for organizing and structuring your software. > * An interface is a contract between a class and the outside world. > * A package is a namespace for organizing classes and interfaces in a logical manner. This Rust code is missing key aspects of both definitions. The surface syntax may look the same, but the details are different: vs Smalltalk, this is the opposite of late bound, or "messaging": it's all early bound, aka statically dispatched. vs Java, there's no objects here: while there is a method syntax, Rust separates state and behavior, into structs and functions. Methods are functions that support the method call syntax in addition to the regular function syntax. There's no classes here, nor inheritance. There is the use of an interface-like thing, and namespace/package like things. TL;DR: there's more to OOP than method syntax.
  - wheelerof4te 4y ago
    I think people got burnt with OOP one too many times, so they stripped it out in both Go and Rust. Rust still has structs with methods kind of OOP, but you can also have that in C using structs with function pointers. So, not really OOP. Let it die already.
    - tialaramex 4y ago
      Object Oriented Programming is a style, like Generic Programming. A language can offer features which support this style well, or not, and you can insist on programming this way regardless of whether the features support it well.
      - deltasevennine 4y ago
        But he's saying the style is bad. Therefore new languages don't support it, well. What do you have to say to that rather then reiterating what everyone knows that OOP is a style of programming.
        tialaramex 4y ago
        I don't think OOP style is bad but it isn't the choice I'd make in many cases. Accordingly I don't think languages should go out of their way to support this style. In particular Multiple Inheritance is the sort of thing OO languages have (C++ and Python for example) which I am confident is a mistake. If your OO model requires multiple inheritance the model is wrong, go re-design it.
  - kaashif 4y ago
    Rust got rid of inheritance, does that mean it's not OOP? There are effectively still classes, methods, members, interfaces, with all the syntactic sugar that goes along with it. https://doc.rust-lang.org/book/ch17-00-oop.html https://doc.rust-lang.org/book/ch17-00-oop.html It feels like this whole discussion about successors and whatnot is just pointless semantics. Rust fits into a lot of C and C++ use cases and is a good tool to have in your toolbox. C still has its place too.
    - deltasevennine 4y ago
      You can twist any language to be OOP if you want. However rust is not primarily focused towards that type of abstraction. Java and C++ are focused towards it. I highly disagree. It is not "pointless semantics". To think everything in the world is some tool in a toolbox and nothing is truly ever bad and everything has a use is naive. Some things are good some things are bad and some things are OOP while other things are not. Rust is not focusing on the OOP philosophy. Both GO and Rust are moving away from that style of abstraction in terms of philosophical goals. If you want to twist the language into OOP that's still possible and still your prerogative. But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. I'm not saying OOP is bad. I'm saying that this is the current status quo. My opinion on the OOP style was not mentioned at all.
      - scratcheee 4y ago
        All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me. It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further. The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal. It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.
aliqot 4y ago
Go is the successor to C, according to G and creators Carbon is the successor to C++, according to G and creators
- sqeaky 4y ago
  Why do their opinions impact me? I different goals than them.
- KerrAvon 4y ago
  Not really. Ritchie wasn't involved in Go, and the C that we all use is not the same C Thompson wrote. edit: typo
- eitland 4y ago
  However smart those people are compared to me this still makes no sense until a significant chunk of the Linux kernel is written in Go and Go is relevant option for writing latency sensitive code (real time audio etc). Go might be a good language even if I prefer otherwise, but the next C it is not, at least not yet.
  - deleted 4y ago
    [deleted]
  - aliqot 4y ago
    > However smart those people are compared to me this still makes no sense until a significant chunk of the Linux kernel is written in Go I'm not much of a runner, you want to catch those goalposts before they get away?
    - sqeaky 4y ago
kaashif 4y ago
Rust is far more similar to C++ than C - RAII, generics, etc are language features that aren't in C, never will be in C, and don't belong in C. Rust fits into a lot of C and C++ use cases, saying it's the successor of one or the other doesn't seem all that coherent.
kramerger 4y ago
C is an extremely simple language. Rust is one of the most complex languages I have worked with (most of that complexity could have been avoided with a better language design). So no, I don't consider them related in any ways.
- scratcheee 4y ago
  >most of that complexity could have been avoided with a better language design Are you saying that the ownership/borrowing model for memory safety was a poor choice, or that it's possible to make a language on that model that has vastly less complexity than Rust? Because your phrasing implies the second, but I don't think I've ever heard anyone make that claim before (presumably because there's no such language lying around anywhere, so it seems hard to defend). If the first, then I'd point out that wouldn't be a language design flaw, but rather a flawed goal (ie a goal that proved too complex to achieve) - their goal was a memory safe language that didn't rely on a GC, and the resultant design complexity is basically the best example of a way to solve for that goal so far. I'm sure there will eventually be simpler options, but I don't think you can blame designers for not having access to undiscovered techniques. That's what most anti-Rust arguements boil down to. If you just mean you don't like the syntax, then yeah, I agree, it's a bit alien for me too, but I hardly concider that anything beyond personal taste and the difficulty of learning something new.
  - kramerger 4y ago
    I meant the general syntax design, not specifically the memory model. For example there are multiple syntaxes for adding annotations or directives to the code. Some things are written very differently compared to other languages for no apparent reasons (e.g. derive). Some keywords have different meaning in different contexts (e.g self and type). And so on... Basically, there are some rough edges that shouldn't really be there
- badsectoracula 4y ago
  > C is an extremely simple language. C is simple compared to others, however it is far from "extremely simple". The language i'd call extremely simple (while still being usable) is Wirth's Oberon-07[0]. Note the "-07" part, there have been a bunch of "Oberons", many which add a ton of additional stuff, not all Oberons are the same or even can be called simple. Oberon-07 however was designed to be simple while also being usable to create a full GUI OS on a custom architecture[1]. [0] http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf [1] http://www.projectoberon.com/ http://www.projectoberon.com/

YetAnotherNick 4y ago

No, it isn't. GC languages are fundamentally different than non GC for lot of applications.

deltasevennine 4y ago
Exactly. High performance applications with zero cost abstractions are required to truly be a successor. Go or Java will never replace C++ for high performance applications like Game engines. Rust might replace it though.
- pier25 4y ago
  Anything realtime will be either C or C++. Audio dev for example. Bitwig (the DAW) has a Java GUI but the core engine is C++ iirc.
- deleted 4y ago
  [deleted]
bugfix-66 4y ago
The successor to C must be designed for a world where it's typical for an application to use dozens of CPU cores. This is the main reason we need a successor to C. Garbage collection becomes almost a necessity when you have enormous concurrency and parallelism. I wonder whether you have experience writing such programs with pthread and malloc/free?
- Ar-Curunir 4y ago
  > Garbage collection becomes almost a necessity when you have enormous concurrency and parallelism. No, you can just use Rust, which provides thread safety without garbage collection.
  - sqeaky 4y ago
    I am not going to call the problem solved, but there are other options too. C++ has libraries threadsafe shared pointers, interthread message passing, transactional memory, futures/promises, work stealing queues, and access to all the OS primitives to build anything else.

ajross 4y ago

No. Go shares a lot of thematic/aesthetic/design principles with C for sure. It prioritizes language clarity, simplicity and universality over features. But the layer being abstracted by the language is totally different. Go is a managed runtime which assumes the use of a threadsafe heap on a multicore host, it provides a stack switching engine for concurrency management and a scheduler on top of that, and assumes the use of robust I/O primitives with asynchronous capabilities. C gives you an easy way to express access basic CPU operations on top of a flat memory model, and maps well to the lowest level of OS system calls. And that's about it. It has some simple library stuff on top that gives you bits and pieces of what you get with big managed languages, but in general everyone recognizes that this isn't its strength and that you shouldn't use it for those problems. But the flip side is that if you have problems that don't map to managed environments well, C remains about as good an environment as you're going to find. If you're writing kernels and drivers and firmware, you aren't going to be able to use Go.

norswap 4y ago

Go is a moderately better C. In terms of expressivity, it is ages behind C++. It also has a garbage collector, which while fine for most use cases is not acceptable for some use cases that C/C++ (and now Rust) are being used for.