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.
Bitwig (the DAW) has a Java GUI but the core engine is C++ iirc.
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?
No, you can just use Rust, which provides thread safety without garbage collection.
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.
Go, on the other hand, does have scaling issues. So do most GC'd languages in fact, as the GCs want to periodically park all threads to walk their stacks. Even the latest & greatest GCs, like Shenandoah, still gotta park all them threads periodically for milliseconds at a time.
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.
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.
Rust is the successor to C.
If anything builds upon C++, it would be 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.
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.
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.
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
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.
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.
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.
Interfaces are part of type theory. Generics so to say.
The unique thing about OOP is objects with mutating state that communicate with one another. This is really the only part of OOP that is uniquely OOP. All other things that are "OOP" like interfaces or object.method() notation are not intrinsic to oop.
Rust moves away from this paradigm I describe.
In what way does C++ have this but Rust doesn't?
You should be asking the question in what way does OOP mutate state and what other programming paradigms don't? What described above is unique to the oop style.
In general when you write rust. Unless you love oop, in general the syntax isn't set up to promote you creating a graph of objects that mutate one another. Java promotes this style the most.
For rust the style the syntax promotes is movement of data through pipelines. The data can get manipulated as it moves through the pipeline.
For functional programming it's similar. You have pipelines, but nothing is being manipulated. Each segment of the pipe in this case takes an input and produces a new output without moving or changing anything.
OOP has been around long enough that all the good ideas have been borrowed/copied/reinterpretted/stolen many times over. Any ideas that managed to remain unique to OOP all this time must have sucked.
Setters are not used in any other programming paradigm. Not in FP, not in C style programming... Any style of programming that strictly is not OOP does not use setters.
Better brush up on OOPSLA, ACM and IEEE literature.
Interfaces exist in functional languages as well. You need to search for the thing that is uniquely oop. Interfaces is not it. Clearly this is an inconsistency.
If IEEE defines interfaces as oop then it is also saying functional programming is oop. This doesn't mesh with our intuition of the meaning of these two terms.
There is a differentiator that is uniquely oop and uniquely functional and that is mutation via setters vs. immutability. Functional programs must be immutable, while oop allows for mutation via setters.
Some people like to roll with the notion that oop and functional are orthogonal concepts, this is an inconsistent notion. You have to realize that mutation via setters definitively makes the two concepts parallel and opposite. Functional cannot mutate.
If the industry ever truly mathematically formalized the term oop rather then relying on crude improvised guidelines via IEEE then mutation via setters is the formal definition of oop.
Everyone nowadays gets confused because lack of proper formalism. The think if they used a method like a getter or inheritance or a class, then they did oop. When this is the case, suddenly everything looks like oop. Suddenly oop is prevalent and the dominant paradigm and used everywhere.
Some of the initial implementation of interfaces go back to CLU ADTs, Smalltalk traits, Objective-C Protocols, Java interfaces, C++ pure virtual classes, BETA patterns, Eiffel, CLOS protocols....
You don't even know who wrote the IEEE definition and who validated it. Second this isn't academic truth. This is just some arbitrary chosen standard chosen by industry. Not academic at all.
In mathematics, the ultimate logical form of academia there is a term for "interfaces". It's called categories, and there's a entire theoretical framework behind it called "Category Theory". This theory of "interfaces" goes beyond just OOP and category theory can be used to foundation-ally describe all of mathematics and function as a sort of replacement of set theory.
Don't worship authority for authorities sake. If the IEEE declared 1+1=3 would you believe it? Instead use your own brain. Do my arguments have merit? Does the IEEE definition seem inconsistent? Does my definition make logical sense? If you can think of these things on your own merits instead of blindly following the IEEE then you'll see that the definition of OOP is just something academia hasn't really thought about deeply from a theoretical and mathematical standpoint. OOP is more like a term that comes from applied engineering with very little theoretical foundation.
If you want some sort of authority I googled some authoritative talk about category theory explained to programmers: https://www.youtube.com/watch?v=JMP6gI5mLHc
I'm sure maybe you heard of haskell and category theory? Haskell is a purely functional language and it has huge connections with category theory. Basically Haskell IS the language of interfaces. It's entire type system is centered around categories or AKA "interfaces". It is the defacto language of interfaces much more-so then OOP languages like Java.
If you said haskell was OOP, people who love that language would vomit. Haskell is not OOP, but it has interfaces, so the obvious conclusion here is "interfaces" ARE not an OOP exclusive concept. It's therefore bad for a formal definitio of OOP.
So now the question is WHAT is it about OOP that makes it uniquely OOP. Or is it just a hodgepodge of random stuff and it will be forever a word that is muddy, inconsistent and poorly defined?
By the way, type classes are somehow related to OOP, maybe you should listen to a guy called Simon Peyton Jones on Haskell influences.
To save you some searching effort, https://www.slideshare.net/nushio/peyton-jones2011type-class...
I would advise to watch the talk that goes with the slides.
OOP is not formally agreed upon in academia there is no consensus. So your reliance on academia here is flawed. Use your own brain rather then blindly trusting others. You know about the replication crisis right? Science is found to be wrong over 50% of the time especially in fields like psychology. Don't be blind.
Please elucidate the crowd on the academic value of your research to computing progress.
Apologies for not understanding this - if the delineation between OOP and not OOP is so clear, it should be easy to come up with an objective criterion for being OOP that C++ satisfies and Rust doesn't satisfy.
I'm not sure what that would be. Inheritance?
If that can't be done, then I'd say it's a matter of opinion.
A venn diagram.
The left is all other programming paradigms. The right is oop. Most of the oop stuff is in the intersection of these circles. What's to the right is encapsulated mutation. Getters and setters and variants of these two concepts. Mostly setters though.
All of oop is simply instantiated objects manipulating and communicating with each other with getters and setters. This is unique to oop. You can't even imitate this with a functional language.
But it shouldn't be functional vs. oop. You can avoid writing any getters and setters in your program and while you wouldn't be doing oop, you wouldn't be doing functional either.
mutate_function(a) is isomorphic to a.mutate_method(). The latter is oop the former is not. There is a design tradeoff here that's actually well known and named. I forgot what it was called though. But also note how I used mutate here in the names. It's because this property of mutation is the main differentiator that causes oop to be different.
If everything was immutable but you still used methods everywhere it wouldn't be uniquely oop. It would be functional as well. And if you think about it is the very property of mutation that allows objects to communicate and mutate one another which fits with our intuition of what oop is. That's why methods that mutate should formally define oop and what it actually is.
I have object a and I have object b. A is similar to b. How do I define a in terms of b? That is inheritance. Functional languages can support this type of syntactic sugar. It is not exclusive to OOP.
std::args().skip(1).next().unwrap();
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.
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/ 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.
Carbon is the successor to C++, according to G and creators
Go might be a good language even if I prefer otherwise, but the next C it is not, at least not yet.
I'm not much of a runner, you want to catch those goalposts before they get away?
edit: typo
I different goals than them.
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.
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.
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
Well, I suppose the standard library is actually, well, standard, instead of a de facto standard.
Do you have material I can read about this? Perhaps some of this can be incorporated into future editions of Rust to improve ergonomics.
> C is an extremely simple language.
It could be, however considering a language complexity in isolation is misleading. C shifts the memory management correctness to the user, which adds significant operational complexity.
Every once in a while somebody writes that 6502 assembly is extremely simple. Well, yeah, but try to do a division.
> most of that complexity could have been avoided with a better language design
Can you elaborate the specifics? I do program in Rust, and most of the complexity is due to two factors - memory management (which causes a significant proliferation of types, for starters) and low-level control (which requires extra complexity; stupid example: stack vs. heap allocation). None of them can be avoided, without shifting the level of the language (which is certainly fair; if one doesn't need lower level control, there are other languages which can be more developer-efficient).
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.
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